Some thoughts spurred -- I am ashamed to admit -- by our local spammer JH.
Probably most of us are familiar with Paul Graham's hypothetical "Blub"
language, as described in the section "The Blub Paradox" in the middle of
http://paulgraham.com/avg.html
It was a hypothetical example to show how some programmers, only used to
languages less powerful than Lisp, might not appreciate the power of Lisp,
simply because they don't understand those features of Lisp that their own
favorite language lacks.
The core of the argument is here:
Blub falls right in the middle of the abstractness continuum. It is
not the most powerful language, but it is more powerful than Cobol or
machine language.
And in fact, our hypothetical Blub programmer wouldn't use either of
them. Of course he wouldn't program in machine language. That's what
compilers are for. And as for Cobol, he doesn't know how anyone can
get anything done with it. It doesn't even have x (Blub feature of
your choice).
As long as our hypothetical Blub programmer is looking down the power
continuum, he knows he's looking down. Languages less powerful than
Blub are obviously less powerful, because they're missing some
feature he's used to. But when our hypothetical Blub programmer looks
in the other direction, up the power continuum, he doesn't realize
he's looking up. What he sees are merely weird languages. He probably
considers them about equivalent in power to Blub, but with all this
other hairy stuff thrown in as well. Blub is good enough for him,
because he thinks in Blub.
When we switch to the point of view of a programmer using any of the
languages higher up the power continuum, however, we find that he in
turn looks down upon Blub. How can you get anything done in Blub? It
doesn't even have y.
By induction, the only programmers in a position to see all the
differences in power between the various languages are those who
understand the most powerful one.
Along the same lines, John McCarthy apparently once said something like:
Lisp seems to be a lucky discovery of a local maximum in the space of
programming languages.
Also paraphrased as:
Lisp is a kind of local maximum in programming language quality: not
necessarily the best thing possible, but hard to change in any simple
way without making it worse.
OK, so now the question. Common Lisp was formalized quite some time ago;
ANSI CL a bit later, but without many radical changes. Are there tools now
known in the abstract space of programming language design that "ought" to be
part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
surely have been strongly suggested to get added to the language?
I'd like to distinguish this from libraries or specific applications, which
are easy enough to layer on top of existing ANSI CL. Of course everybody can
name sockets, or web programming (XML parsers, HTTP servers). I'm thinking
of generic ideas in the description of computation, which apply across a wide
range of applications. Things like "iteration" or "recursion" or "CLOS".
There are some things clearly on the edge. All the existing trig functions
(SIN, COS, TAN) are highly useful to some small set of programmers, and
generally ignored by the rest. They could have easily been an add-on
library. (On the other hand, the basic numeric tower in Lisp, the automatic
conversion of numbers between data types, is far more fundamental to the
language.)
Regular expression matching, which is missing from the ANSI CL standard, is
probably of this "edge" class and would have been included in a CL2. Maybe
multiprocessing too.
So I'm wondering about language expressions that are so fundamental to
describing computation, that they "ought" to be part of the vocabulary of any
advanced programmer.
The previously mentioned spammer has suggested that pattern-matching function
definition is one such thing. As best I can tell, this seems to be sort of
related to CLOS generic methods, with different code called for different
argument lists, although the power of the expressions to choose the different
code that is called is greater with pattern-matching than with CLOS.
Static typing is another interesting corner case. Lots of pros and cons.
Qi seems to claim a Lisp-like language with "optional" static typing. Would
that be something that "should" be in a CL2?
And the pattern-matching programming idea got me thinking of unification. At
one time, people touted Prolog as the future of programming languages. Very,
very different from Lisp, and hugely useful when it applies. I think Prolog
failed as a general purpose programming language, but should that technology
be part of the bag of tricks available to every Lisp programmer? Unification
and inference is probably a generalization of the pattern-matching idea.
Just curious if anyone here has thoughts on these possible additions to a
core (new) Lisp, or perhaps other similar topics that ought to be included.
ITERATE? SERIES? Partial evaluation? Call/CC?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
In bed the other night my girlfriend asked "if you could know exactly when and
where you would die, would you want to?" I said "no". She said, "ok, then
forget it". -- Steven Wright
On Jul 2, 5:38 am, Don Geddis <····@geddis.org> wrote:
> Some thoughts spurred -- I am ashamed to admit -- by our local spammer JH.
It's better to ignore the trolls completely, you'll learn nothing from
them except bad smell of feeling dirty. Not to mention waste of time.
>
> Probably most of us are familiar with Paul Graham's hypothetical "Blub"
> language, as described in the section "The Blub Paradox" in the middle of
> http://paulgraham.com/avg.html
> It was a hypothetical example to show how some programmers, only used to
> languages less powerful than Lisp, might not appreciate the power of Lisp,
> simply because they don't understand those features of Lisp that their own
> favorite language lacks.
>
> The core of the argument is here:
>
> Blub falls right in the middle of the abstractness continuum. It is
> not the most powerful language, but it is more powerful than Cobol or
> machine language.
>
> And in fact, our hypothetical Blub programmer wouldn't use either of
> them. Of course he wouldn't program in machine language. That's what
> compilers are for. And as for Cobol, he doesn't know how anyone can
> get anything done with it. It doesn't even have x (Blub feature of
> your choice).
>
> As long as our hypothetical Blub programmer is looking down the power
> continuum, he knows he's looking down. Languages less powerful than
> Blub are obviously less powerful, because they're missing some
> feature he's used to. But when our hypothetical Blub programmer looks
> in the other direction, up the power continuum, he doesn't realize
> he's looking up. What he sees are merely weird languages. He probably
> considers them about equivalent in power to Blub, but with all this
> other hairy stuff thrown in as well. Blub is good enough for him,
> because he thinks in Blub.
>
> When we switch to the point of view of a programmer using any of the
> languages higher up the power continuum, however, we find that he in
> turn looks down upon Blub. How can you get anything done in Blub? It
> doesn't even have y.
>
> By induction, the only programmers in a position to see all the
> differences in power between the various languages are those who
> understand the most powerful one.
>
> Along the same lines, John McCarthy apparently once said something like:
> Lisp seems to be a lucky discovery of a local maximum in the space of
> programming languages.
> Also paraphrased as:
> Lisp is a kind of local maximum in programming language quality: not
> necessarily the best thing possible, but hard to change in any simple
> way without making it worse.
>
> OK, so now the question. Common Lisp was formalized quite some time ago;
> ANSI CL a bit later, but without many radical changes. Are there tools now
> known in the abstract space of programming language design that "ought" to be
> part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
> surely have been strongly suggested to get added to the language?
google a little bit and you'll find that in current state that's
impossible.
>
> I'd like to distinguish this from libraries or specific applications, which
> are easy enough to layer on top of existing ANSI CL. Of course everybody can
> name sockets, or web programming (XML parsers, HTTP servers). I'm thinking
> of generic ideas in the description of computation, which apply across a wide
> range of applications. Things like "iteration" or "recursion" or "CLOS".
>
> There are some things clearly on the edge. All the existing trig functions
> (SIN, COS, TAN) are highly useful to some small set of programmers, and
> generally ignored by the rest. They could have easily been an add-on
> library. (On the other hand, the basic numeric tower in Lisp, the automatic
> conversion of numbers between data types, is far more fundamental to the
> language.)
>
> Regular expression matching, which is missing from the ANSI CL standard, is
> probably of this "edge" class and would have been included in a CL2. Maybe
> multiprocessing too.
>
> So I'm wondering about language expressions that are so fundamental to
> describing computation, that they "ought" to be part of the vocabulary of any
> advanced programmer.
>
> The previously mentioned spammer has suggested that pattern-matching function
> definition is one such thing. As best I can tell, this seems to be sort of
> related to CLOS generic methods, with different code called for different
> argument lists, although the power of the expressions to choose the different
> code that is called is greater with pattern-matching than with CLOS.
>
> Static typing is another interesting corner case. Lots of pros and cons.
> Qi seems to claim a Lisp-like language with "optional" static typing. Would
> that be something that "should" be in a CL2?
It already there remember declare , the, fixnum etc
>
> And the pattern-matching programming idea got me thinking of unification. At
> one time, people touted Prolog as the future of programming languages. Very,
> very different from Lisp, and hugely useful when it applies. I think Prolog
> failed as a general purpose programming language, but should that technology
> be part of the bag of tricks available to every Lisp programmer? Unification
> and inference is probably a generalization of the pattern-matching idea.
>
> Just curious if anyone here has thoughts on these possible additions to a
> core (new) Lisp, or perhaps other similar topics that ought to be included.
> ITERATE? SERIES? Partial evaluation? Call/CC?
There's many libraries that are relatively easy to find and
install,iterate, series, cells, qi....For a lot of the other mentioned
there is a library already ready to use or code exist or as in call/cc
feature is questionable, some like it some believe it doesn't worth.
So you already have a most powerfull toolbox from any other
lanaguages, you only need to build with it.
The only thing that I really believe that lisp is missing is erlang/
termite like concurrency, but time will tell.
For now we only need more apps written in it.
>
> -- Don
> ___________________________________________________________________________ ____
> Don Geddis http://don.geddis.org/ ····@geddis.org
> In bed the other night my girlfriend asked "if you could know exactly when and
> where you would die, would you want to?" I said "no". She said, "ok, then
> forget it". -- Steven Wright
On Jul 2, 2:24 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jul 2, 5:38 am, Don Geddis <····@geddis.org> wrote:
>
> > Some thoughts spurred -- I am ashamed to admit -- by our local spammer JH.
>
> It's better to ignore the trolls completely, you'll learn nothing from
> them except bad smell of feeling dirty. Not to mention waste of time.
I'm not really interested in the main post because my suggestions
would require far too much clarification, but this is an interesting
quote. Yes, trolls are annoying. Yes, most of the time they have no
idea what they're talking about. No, you shouldn't just ignore them.
At least, not in the way suggested here. Ignore them _after_ you
disprove what they're saying. Don't use the fact that they're a troll
prevent you from exploring the issue. (I also like to keep an
extremely open mind when I'm considering other viewpoints. I've
learned that from years of unknowingly being wrong. In my defense,
nobody was ever able to provide proof that I was wrong--I always ended
up doing that myself.)
Anyway, that's just my $0.02.
On Jul 2, 7:00 pm, ··········@gmail.com" <·········@gmail.com> wrote:
> On Jul 2, 2:24 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > On Jul 2, 5:38 am, Don Geddis <····@geddis.org> wrote:
>
> > > Some thoughts spurred -- I am ashamed to admit -- by our local spammer JH.
>
> > It's better to ignore the trolls completely, you'll learn nothing from
> > them except bad smell of feeling dirty. Not to mention waste of time.
>
> I'm not really interested in the main post because my suggestions
> would require far too much clarification, but this is an interesting
> quote. Yes, trolls are annoying. Yes, most of the time they have no
> idea what they're talking about. No, you shouldn't just ignore them.
> At least, not in the way suggested here. Ignore them _after_ you
> disprove what they're saying. Don't use the fact that they're a troll
> prevent you from exploring the issue. (I also like to keep an
> extremely open mind when I'm considering other viewpoints. I've
> learned that from years of unknowingly being wrong. In my defense,
> nobody was ever able to provide proof that I was wrong--I always ended
> up doing that myself.)
>
> Anyway, that's just my $0.02.
The trolls or rather in this case a spammer are utter waste of time.
You can't teach someone stubborn enough who don't want to learn a
little bit of programming lisp what the hell we're talking in this
newsgroup.Beside a lot of people who want to read about lisp topics
end up reading rehashing of the same bs from trollers and spammers .So
I will continue to ignore trolls and spammers not matter what they
say, you have a right to shape your opinion as you please.
Slobodan Blazeski
On Jul 2, 3:24 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> There's many libraries that are relatively easy to find and
> install,iterate, series, cells, qi....For a lot of the other mentioned
> there is a library already ready to use or code exist or as in call/cc
> feature is questionable, some like it some believe it doesn't worth.
> So you already have a most powerfull toolbox from any other
> lanaguages, you only need to build with it.
> The only thing that I really believe that lisp is missing is erlang/
> termite like concurrency, but time will tell.
> For now we only need more apps written in it.
I work at a university, and just out of curiosity I sat in on a talk
given by young Apple employees to CS students considering applying
there for internships or jobs.
In response to a question about how to present one's self in an
interview at Apple, one of the speakers replied (paraphrase) "Whatever
you do, don't say Mac OS X is perfect. If you can't find anything
wrong with it, how could you possibly have any chance of making it
better?"
I think that would be a healthy attitude to take towards Lisp, or,
frankly, anything else you like. If you think you have found any
piece of utopia on this Earth, you are probably either deceiving
yourself or need to raise your standards.
Now, to your credit, you do mention the concurrency thing. But do you
really think there is nothing else that could make Lisp better?
And with the reliance on the idea that "you can always add that as a
library" you come close to the Godwin's Law of Referencing Turing
Completeness [1].
To avoid hypocrisy, here are some criticisms I made about Lisp:
http://programming.reddit.com/info/1z8b8/comments/c1zbmr
These are more criticisms of Common Lisp culture and community, and I
think most of the weaknesses of Common Lisp reside there as opposed to
something in or not in the text of the standard itself.
-jimbo
[1] http://programming.reddit.com/info/21vs0/comments/c022160
On Jul 2, 2:33 pm, ········@gmail.com wrote:
[...]
> Now, to your credit, you do mention the concurrency thing. But do you
> really think there is nothing else that could make Lisp better?
For me (and, I gather from your reddit post, you), there are many
things that could make Lisp better, but relatively few of them are in
the realm of supporting something like "concurrency". It's all
straightforward stuff like more libraries and a better set of options
for GUIs.
Of course, "straightforward" and "trivial" are completely different
things, which is why Lisp still has these problems.
Cheers,
Pillsy
In article <························@c77g2000hse.googlegroups.com>,
········@gmail.com wrote:
> On Jul 2, 3:24 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
> > There's many libraries that are relatively easy to find and
> > install,iterate, series, cells, qi....For a lot of the other mentioned
> > there is a library already ready to use or code exist or as in call/cc
> > feature is questionable, some like it some believe it doesn't worth.
> > So you already have a most powerfull toolbox from any other
> > lanaguages, you only need to build with it.
> > The only thing that I really believe that lisp is missing is erlang/
> > termite like concurrency, but time will tell.
> > For now we only need more apps written in it.
>
> I work at a university, and just out of curiosity I sat in on a talk
> given by young Apple employees to CS students considering applying
> there for internships or jobs.
>
> In response to a question about how to present one's self in an
> interview at Apple, one of the speakers replied (paraphrase) "Whatever
> you do, don't say Mac OS X is perfect. If you can't find anything
> wrong with it, how could you possibly have any chance of making it
> better?"
>
> I think that would be a healthy attitude to take towards Lisp, or,
> frankly, anything else you like. If you think you have found any
> piece of utopia on this Earth, you are probably either deceiving
> yourself or need to raise your standards.
>
> Now, to your credit, you do mention the concurrency thing. But do you
> really think there is nothing else that could make Lisp better?
>
> And with the reliance on the idea that "you can always add that as a
> library" you come close to the Godwin's Law of Referencing Turing
> Completeness [1].
>
> To avoid hypocrisy, here are some criticisms I made about Lisp:
>
> http://programming.reddit.com/info/1z8b8/comments/c1zbmr
>
> These are more criticisms of Common Lisp culture and community, and I
> think most of the weaknesses of Common Lisp reside there as opposed to
> something in or not in the text of the standard itself.
I find your remarks very unfriendly. I find your posting
shows that you might yourself be socially challenged.
I'm a long time here at
comp.lang.lisp and I have seen a lot of very friendly
people (plus the usual dose of idiots). Even though the
Lisp community is very diverse, there are lots of helpful
people here. Ask a question and often you get very good answers.
If somebody trolls, wants to cheat with his tests
in the school or the university, asks questions where
answers can easily be googled or faqed, then one might get
an unwanted reply. Sometimes there are more specific
mailing lists or newgroups one should use to find answers.
People will get pointers.
comp.lang.lisp has improved on the signal-to-noise ratio.
I'd like to get better not worse.
Sometimes Lisp attracts people with very strange ideas.
They may look at Lisp as one of the few tools that
could be able to express their ideas in computational
terms. At one point programming gene-like algorithms
with mutations could have looked strange. But then
came Koza and published a book about it using Lisp
for his research. This was a start of a new field
in computer science. Or Chaitin's work on
algorithmic information theory. Or Hofstadter's books.
All with strange Lisp stuff.
But fun and interesting.
Sorry, but your remarks are unfriendly and I will
killfile you.
> -jimbo
>
> [1] http://programming.reddit.com/info/21vs0/comments/c022160
--
http://lispm.dyndns.org
On Jul 2, 4:32 pm, Rainer Joswig <······@lisp.de> wrote:
> Sorry, but your remarks are unfriendly and I will
> killfile you.
Well, that's too bad because I wasn't singly you out personally and
have found many of your comments useful and interesting and it's a
shame you won't know I feel that way that because you won't be reading
this.
For anyone still reading, in other reddit comments I mention that the
reason for c.l.l.'s quick reaction of labeling a comment a troll is
due to the large number of real trolls that come through this group.
I think because of that there is sometimes an over reaction of
declaring someone a troll when they have a legitimate criticism of
Lisp or an honest question that unfortunately resembles a question or
comment that was a troll in the past.
Beyond that, there seems to be a paranoia about adding anything in any
way to "Lisp". Notice the quotation marks, because I don't care if
the existing Common Lisp standard ever officially changes, but I think
"Lisp" could benefit from more defacto-standardization of picking some
core functionality and convincing the various Lisp implementors to
bundle it through social pressure and pitching in to help.
Elsewhere in the same comments thread as my offending remark, someone
asks why Lisp has no literal syntax for hash tables. I pointed out
that Lisp syntax has literals for anything tree like, and that Lisp
prefers consistency of syntax (enabling powerful macros, etc.) instead
of special case syntaxes like Perl, Python, Ruby, etc.
Well, that did make me curious why Common Lisp does not have a reader
syntax for hash tables. In the process, I discovered hash tables are
one of the few things that lack a reader syntax (numbers, strings,
lists, vectors, structs all covered; did I miss any?). Investigating
more, I found a long, involved c.l.l. thread from 1999 discussing this
very issue. The conversation revolved around "what about the edge
cases?" You might not be able to re-establish notions of identity
when you read your hash table back in, thus breaking semantics.
Well, so what? It's an edge case. Document the limitations somewhere
and move on. (Which several people advocated.)
But there is no one who can just say "let's just make a decision and
move on" for Lisp. No Matz, Guido, Larry, or Stroustrup. The spec is
great. But the fear of establishing any kind of consensus for
anything not in the spec is a shortcoming of the Lisp community, in my
opinion.
My criticism goes to Common Lisp culture and community as a whole, not
to any one individual. It is good to have individuals in the
community that say "wait a sec, what about..." before blindly pushing
forward with a new idea. But when those sentiments overwhelm the
community as a whole and change, thus progress, becomes impossible, I
consider that a broken culture.
So please don't think I'm picking out individuals here as the problem
with Lisp. But I do think the sum of Lisp culture is holding Lisp
back from its full potential at this junction.
-jimbo
········@gmail.com wrote:
> On Jul 2, 4:32 pm, Rainer Joswig <······@lisp.de> wrote:
>
>>Sorry, but your remarks are unfriendly and I will
>>killfile you.
>
>
> Well, that's too bad because I wasn't singly you out personally and
> have found many of your comments useful and interesting and it's a
> shame you won't know I feel that way that because you won't be reading
> this.
>
> For anyone still reading, in other reddit comments I mention that the
> reason for c.l.l.'s quick reaction of labeling a comment a troll is
> due to ...
...our being smarter than frickin losers like you? Name one serious
poster labelled a troll who is still posting. Oh. None? Fine, STFU and
go find a newsgroup that won't laugh your sorry *ss into oblivion.
For anyone still reading, that is.
hth,kenny
On Jul 2, 9:21 pm, Ken Tilton <···········@optonline.net> wrote:
> ...our being smarter than frickin losers like you? Name one serious
> poster labelled a troll who is still posting. Oh. None? Fine, STFU and
> go find a newsgroup that won't laugh your sorry *ss into oblivion.
Isn't that kind of the point? Someone has a question, they get
labeled a troll, they stop posting because it's not worth the hassle
and find some other way to learn Lisp, or just go on happily
programming in Ruby on Rails or whatever.
Note: I'm not denying that there is A LOT of trolling on c.l.l. I am
claiming that occasionally really questions and comments get caught up
in the troll net.
OK, random hit on searching "not a troll" in c.l.l.
http://groups.google.com/group/comp.lang.lisp/msg/c21597a2cc4f7a7b
Random third party after poster A labels poster B a troll:
"I disagree very strongly. This person has done nothing but ask
reasonable
questions in a reasonable manner. That is not a troll. It is not his
fault
that he walks a path this group has seen many times before."
Not hard at all to find other examples like this.
-jimbo
········@gmail.com wrote:
> On Jul 2, 9:21 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>...our being smarter than frickin losers like you? Name one serious
>>poster labelled a troll who is still posting. Oh. None? Fine, STFU and
>>go find a newsgroup that won't laugh your sorry *ss into oblivion.
>
>
> Isn't that kind of the point?
Yeah, it was a completely ironic and deliberately self-referential post
meant to amuse and edify. How did I know it would be lost on a dolt like
you?
hth,kt
On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
> Yeah, it was a completely ironic and deliberately self-referential post
> meant to amuse and edify. How did I know it would be lost on a dolt like
> you?
OK, I'll try harder in the future to keep up.
-jimbo
········@gmail.com wrote:
> On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>
>>Yeah, it was a completely ironic and deliberately self-referential post
>>meant to amuse and edify. How did I know it would be lost on a dolt like
>>you?
>
>
> OK, I'll try harder in the future to keep up.
I was thinking "catch up". You come into one of the better NGs on UseNet
where honest noobs get about the best help you can imagine and lecture
us on our behavior? After also doing so in a public forum?
And you think /we/ are socially challenged?!!!!!!!!!!!!!
I'd further LMAO at your premise that I am personally responsible for
Lisp's small mindshare, but I am also looking forward to thus getting
credit for Lisp's booming popularity and other languages copying Lisp
all the time. Kenny made us do it!
Well, they hate it when I feed the trolls, and I better leave something
for the dogs....
kxo
On Jul 3, 2:26 pm, Ken Tilton <···········@optonline.net> wrote:
> I'd further LMAO at your premise that I am personally responsible for
> Lisp's small mindshare, but I am also looking forward to thus getting
> credit for Lisp's booming popularity and other languages copying Lisp
> all the time. Kenny made us do it!
Looking forward to it. I'll be sure to give you all the credit.
-jimbo
········@gmail.com wrote:
> On Jul 3, 2:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>I'd further LMAO at your premise that I am personally responsible for
>>Lisp's small mindshare, but I am also looking forward to thus getting
>>credit for Lisp's booming popularity and other languages copying Lisp
>>all the time. Kenny made us do it!
>
>
> Looking forward to it. I'll be sure to give you all the credit.
You should see the acceptance speech. Modest, self-deprecating...
kt
On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
> ········@gmail.com wrote:
> > On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>Yeah, it was a completely ironic and deliberately self-referential post
> >>meant to amuse and edify. How did I know it would be lost on a dolt like
> >>you?
>
> > OK, I'll try harder in the future to keep up.
>
> I was thinking "catch up". You come into one of the better NGs on UseNet
=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
nil
-=>(best-ng-on-the-usenet-p comp.lang.lisp)
t
> where honest noobs get about the best help you can imagine and lecture
> us on our behavior? After also doing so in a public forum?
>
> And you think /we/ are socially challenged?!!!!!!!!!!!!!
>
> I'd further LMAO at your premise that I am personally responsible for
> Lisp's small mindshare, but I am also looking forward to thus getting
> credit for Lisp's booming popularity and other languages copying Lisp
> all the time. Kenny made us do it!
>
> Well, they hate it when I feed the trolls, and I better leave something
> for the dogs....
>
> kxo
Slobodan Blazeski wrote:
> On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>········@gmail.com wrote:
>>
>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>Yeah, it was a completely ironic and deliberately self-referential post
>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
>>>>you?
>>
>>>OK, I'll try harder in the future to keep up.
>>
>>I was thinking "catch up". You come into one of the better NGs on UseNet
>
>
> =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> nil
> -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> t
>
What part of set theory do you not understand?
hth,kt
On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>········@gmail.com wrote:
>
> >>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>Yeah, it was a completely ironic and deliberately self-referential post
> >>>>meant to amuse and edify. How did I know it would be lost on a dolt like
> >>>>you?
>
> >>>OK, I'll try harder in the future to keep up.
>
> >>I was thinking "catch up". You come into one of the better NGs on UseNet
>
> > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> > nil
> > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> > t
>
> What part of set theory do you not understand?
>
> hth,kt
Once upon a time in a village far far away there was a barbershop
whose barber had a strict policy of shaving everybody in the village
who didn't shave themselves and noone else. Should the barber shave
himself ?
Slobodan Blazeski
Slobodan Blazeski wrote:
> On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Slobodan Blazeski wrote:
>>
>>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>········@gmail.com wrote:
>>
>>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>Yeah, it was a completely ironic and deliberately self-referential post
>>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
>>>>>>you?
>>
>>>>>OK, I'll try harder in the future to keep up.
>>
>>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>>
>>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>>>nil
>>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
>>>t
>>
>>What part of set theory do you not understand?
>>
>>hth,kt
>
>
> Once upon a time in a village far far away there was a barbershop
> whose barber had a strict policy of shaving everybody in the village
> who didn't shave themselves and noone else. Should the barber shave
> himself ?
>
I see. You would rather talk about computability than set theory. Not
that this example is at all interesting.
hth,kt
On Jul 4, 1:44 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>Slobodan Blazeski wrote:
>
> >>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>········@gmail.com wrote:
>
> >>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>Yeah, it was a completely ironic and deliberately self-referential post
> >>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
> >>>>>>you?
>
> >>>>>OK, I'll try harder in the future to keep up.
>
> >>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>
> >>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> >>>nil
> >>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
> >>>t
>
> >>What part of set theory do you not understand?
>
> >>hth,kt
>
> > Once upon a time in a village far far away there was a barbershop
> > whose barber had a strict policy of shaving everybody in the village
> > who didn't shave themselves and noone else. Should the barber shave
> > himself ?
>
> I see. You would rather talk about computability than set theory. Not
> that this example is at all interesting.
>
> hth,kt- Hide quoted text -
>
> - Show quoted text -
Gave up already ?
Slobodan Blazeski
Slobodan Blazeski wrote:
> On Jul 4, 1:44 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Slobodan Blazeski wrote:
>>
>>>On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>Slobodan Blazeski wrote:
>>
>>>>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>········@gmail.com wrote:
>>
>>>>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>>>Yeah, it was a completely ironic and deliberately self-referential post
>>>>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
>>>>>>>>you?
>>
>>>>>>>OK, I'll try harder in the future to keep up.
>>
>>>>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>>
>>>>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>>>>>nil
>>>>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
>>>>>t
>>
>>>>What part of set theory do you not understand?
>>
>>>>hth,kt
>>
>>>Once upon a time in a village far far away there was a barbershop
>>>whose barber had a strict policy of shaving everybody in the village
>>>who didn't shave themselves and noone else. Should the barber shave
>>>himself ?
>>
>>I see. You would rather talk about computability than set theory. Not
>>that this example is at all interesting.
>>
>>hth,kt- Hide quoted text -
>>
>>- Show quoted text -
>
>
> Gave up already ?
Decided already. You stuck? Hell, it was your (boring) riddle.
kt
On Jul 4, 1:58 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Jul 4, 1:44 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>Slobodan Blazeski wrote:
>
> >>>On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>Slobodan Blazeski wrote:
>
> >>>>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>········@gmail.com wrote:
>
> >>>>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>>>Yeah, it was a completely ironic and deliberately self-referential post
> >>>>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
> >>>>>>>>you?
>
> >>>>>>>OK, I'll try harder in the future to keep up.
>
> >>>>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>
> >>>>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> >>>>>nil
> >>>>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
> >>>>>t
>
> >>>>What part of set theory do you not understand?
>
> >>>>hth,kt
>
> >>>Once upon a time in a village far far away there was a barbershop
> >>>whose barber had a strict policy of shaving everybody in the village
> >>>who didn't shave themselves and noone else. Should the barber shave
> >>>himself ?
>
> >>I see. You would rather talk about computability than set theory. Not
> >>that this example is at all interesting.
>
> >>hth,kt- Hide quoted text -
>
> >>- Show quoted text -
>
> > Gave up already ?
>
> Decided already. You stuck? Hell, it was your (boring) riddle.
>
> kt- Hide quoted text -
>
> - Show quoted text -
Actually I was talking about a set theory, as the puzzle I presented,
called a Barber paradox and attributed to Bertrand Russell and
analogous to Russell's Paradox, which is devised to show that set
theory as it was used by Georg Cantor and Gottlob Frege contained
contradictions.
If the barber does not shave himself, he must abide by the rule and
shave himself.
If he does shave himself, according to the rule he shouldn't shave
himself.
Slobodan Blazeski
>>> =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>>> nil
>>> -=>(best-ng-on-the-usenet-p comp.lang.lisp)
>>> t
>> What part of set theory do you not understand?
Slobodan Blazeski wrote:
> Once upon a time in a village far far away there was a barbershop
> whose barber had a strict policy of shaving everybody in the village
> who didn't shave themselves and noone else. Should the barber shave
> himself ?
Once upon a time, in a village far, far away, there was a butcher-shop
whose butcher was the best butcher in the kingdom. One day, the king
decided to hold a feast.
"I must have ten butchers," said the king. "The ten best butchers
in my kingdom."
So the king sent his court jester to find the ten best butchers
in the kingdom. When the jester reached the butcher's village, all
the villagers said "Our butcher is the best butcher in the kingdom."
"Oh no," said the jester. "I don't want the best butcher in the
kingdom, I only want one of the ten best butchers."
So, leaving the village with its butcher, the jester continued
his search, and the king later held a sumptuous feast.
Meanwhile, the neighboring emperor heard about the king's feast,
and also about the village's great butcher. The emperor hired
the butcher, held an even more sumptuous feast, and proclaimed
throughout the land the skill and talent of this wonderful butcher.
Embarrassed and infuriated beyond measure, the king transferred
his jester to the royal stables, where the jester spent the rest
of his days shoveling donkey-droppings.
The End.
--
Dan
www.prairienet.org/~dsb/
On Jul 4, 4:10 pm, Dan Bensen <··········@cyberspace.net> wrote:
> >>> =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> >>> nil
> >>> -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> >>> t
> >> What part of set theory do you not understand?
>
> Slobodan Blazeski wrote:
>
> > Once upon a time in a village far far away there was a barbershop
> > whose barber had a strict policy of shaving everybody in the village
> > who didn't shave themselves and noone else. Should the barber shave
> > himself ?
>
> Once upon a time, in a village far, far away, there was a butcher-shop
> whose butcher was the best butcher in the kingdom. One day, the king
> decided to hold a feast.
> "I must have ten butchers," said the king. "The ten best butchers
> in my kingdom."
> So the king sent his court jester to find the ten best butchers
> in the kingdom. When the jester reached the butcher's village, all
> the villagers said "Our butcher is the best butcher in the kingdom."
> "Oh no," said the jester. "I don't want the best butcher in the
> kingdom, I only want one of the ten best butchers."
> So, leaving the village with its butcher, the jester continued
> his search, and the king later held a sumptuous feast.
> Meanwhile, the neighboring emperor heard about the king's feast,
> and also about the village's great butcher. The emperor hired
> the butcher, held an even more sumptuous feast, and proclaimed
> throughout the land the skill and talent of this wonderful butcher.
That's called career. Someone with talent found someone who will hold
him in higher esteem.
> Embarrassed and infuriated beyond measure, the king transferred
> his jester to the royal stables, where the jester spent the rest
> of his days shoveling donkey-droppings.
>
> The End.
>
> --
> Danwww.prairienet.org/~dsb/
Your story is unacceptable. Your looking for the best you could get
your hands on. If you buy a house would you choose whichever of the 10
that you find best or the one that is No 1 according to your
criteria? If there are 10 girls you like would you pick at random or
just choose the hottest one ? And beside that who the hell is the
10th most powerfull languages in the world so we could just use it ,
it won't make any difference right?
Slobodan Blazeski <·················@gmail.com> writes:
> If there are 10 girls you like would you pick at random or just
> choose the hottest one ?
I'd go for the first one who was willing to look at me twice without
losing her lunch. :)
...Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
Peder O. Klingenberg wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
>
>
>>If there are 10 girls you like would you pick at random or just
>>choose the hottest one ?
I go for the one with the widest variety of facial expression. The eyes
must also move independently of the skull.
>
>
> I'd go for the first one who was willing to look at me twice without
> losing her lunch. :)
Yes, let the female select, they are much better at matching.
kt
Ken Tilton <·········@gmail.com> wrote:
+---------------
| Yes, let the female select, they are much better at matching.
+---------------
Ah, yezz... After many years of dressing as the geek I am,
I finally developed a method of shopping for clothes that
allowed me to at least *appear* less socially challenged,
namely, take a [non-relative] female friend whose taste I
trust shopping with me: She gets to pick out stuff; I only
get to veto. This works surprisingly well.
As you say, they are much better at matching...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Slobodan Blazeski wrote:
> On Jul 4, 1:58 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Slobodan Blazeski wrote:
>>
>>>On Jul 4, 1:44 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>Slobodan Blazeski wrote:
>>
>>>>>On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>Slobodan Blazeski wrote:
>>
>>>>>>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>>>········@gmail.com wrote:
>>
>>>>>>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>>>>>Yeah, it was a completely ironic and deliberately self-referential post
>>>>>>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
>>>>>>>>>>you?
>>
>>>>>>>>>OK, I'll try harder in the future to keep up.
>>
>>>>>>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>>
>>>>>>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>>>>>>>nil
>>>>>>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
>>>>>>>t
>>
>>>>>>What part of set theory do you not understand?
>>
>>>>>>hth,kt
>>
>>>>>Once upon a time in a village far far away there was a barbershop
>>>>>whose barber had a strict policy of shaving everybody in the village
>>>>>who didn't shave themselves and noone else. Should the barber shave
>>>>>himself ?
>>
>>>>I see. You would rather talk about computability than set theory. Not
>>>>that this example is at all interesting.
>>
>>>>hth,kt- Hide quoted text -
>>
>>>>- Show quoted text -
>>
>>>Gave up already ?
>>
>>Decided already. You stuck? Hell, it was your (boring) riddle.
>>
>>kt- Hide quoted text -
>>
>>- Show quoted text -
>
>
> Actually I was talking about a set theory,...
When are you people goin to learn to listen to me? That is almost
entirely about computability, and only trivially about set theory. F*ck,
it is a simple find-if.
Tell you what, translate the riddle into Lisp and see what you get,
maybe then you can understand His Kennyness.
> as the puzzle I presented,
> called a Barber paradox
Typical academics, naming a triviality. Reminds me of PAIP.
>... and attributed to Bertrand Russell and
> analogous to Russell's Paradox, which is devised to show that set
> theory as it was used by Georg Cantor and Gottlob Frege contained
> contradictions.
No, it is not a contradiction. The problem statement was perfectly
comprehensible. There is a problem, but it is not one of contradiction
which involves saying X is Y and X is not Y.
>
> If the barber does not shave himself, he must abide by the rule and
> shave himself.
> If he does shave himself, according to the rule he shouldn't shave
> himself.
Omigod, you thought Myself could not figure that out? Of course those
observations are fine, now stop whining and answer the damn question:
should the barber shave himself? What happens? Look at your Lisp code.
hth,kt
Ken Tilton <···········@optonline.net> wrote:
[...]
>
> Typical academics, naming a triviality. Reminds me of PAIP.
>
Could you elaborate? I'm reading PAIP now.
Bob Felts wrote:
> Ken Tilton <···········@optonline.net> wrote:
>
> [...]
>
>
>>Typical academics, naming a triviality. Reminds me of PAIP.
>>
>
>
> Could you elaborate? I'm reading PAIP now.
In Chapter N he offers a buggy problem solver. In Chapter (1+ N) he
declares it to be the well-known Somesuch Problem and offers a solution
to it, namely a bugfix for Chapter N, for some value of N < 3.
kt
On Jul 4, 4:26 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Jul 4, 1:58 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>Slobodan Blazeski wrote:
>
> >>>On Jul 4, 1:44 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>Slobodan Blazeski wrote:
>
> >>>>>On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>Slobodan Blazeski wrote:
>
> >>>>>>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>>>········@gmail.com wrote:
>
> >>>>>>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>>>>>Yeah, it was a completely ironic and deliberately self-referential post
> >>>>>>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
> >>>>>>>>>>you?
>
> >>>>>>>>>OK, I'll try harder in the future to keep up.
>
> >>>>>>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>
> >>>>>>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> >>>>>>>nil
> >>>>>>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
> >>>>>>>t
>
> >>>>>>What part of set theory do you not understand?
>
> >>>>>>hth,kt
>
> >>>>>Once upon a time in a village far far away there was a barbershop
> >>>>>whose barber had a strict policy of shaving everybody in the village
> >>>>>who didn't shave themselves and noone else. Should the barber shave
> >>>>>himself ?
>
> >>>>I see. You would rather talk about computability than set theory. Not
> >>>>that this example is at all interesting.
>
> >>>>hth,kt- Hide quoted text -
>
> >>>>- Show quoted text -
>
> >>>Gave up already ?
>
> >>Decided already. You stuck? Hell, it was your (boring) riddle.
>
> >>kt- Hide quoted text -
>
> >>- Show quoted text -
>
> > Actually I was talking about a set theory,...
>
> When are you people goin to learn to listen to me? That is almost
> entirely about computability, and only trivially about set theory. F*ck,
> it is a simple find-if.
>
> Tell you what, translate the riddle into Lisp and see what you get,
> maybe then you can understand His Kennyness.
>
> > as the puzzle I presented,
> > called a Barber paradox
>
> Typical academics, naming a triviality. Reminds me of PAIP.
>
> >... and attributed to Bertrand Russell and
> > analogous to Russell's Paradox, which is devised to show that set
> > theory as it was used by Georg Cantor and Gottlob Frege contained
> > contradictions.
>
> No, it is not a contradiction. The problem statement was perfectly
> comprehensible. There is a problem, but it is not one of contradiction
> which involves saying X is Y and X is not Y.
>
>
>
> > If the barber does not shave himself, he must abide by the rule and
> > shave himself.
> > If he does shave himself, according to the rule he shouldn't shave
> > himself.
>
> Omigod, you thought Myself could not figure that out? Of course those
> observations are fine, now stop whining and answer the damn question:
> should the barber shave himself? What happens? Look at your Lisp code.
>
> hth,kt
My lisp code gets in recursive stack overflow if all below premises
are included:
1. Village, Villagers & barber must exist.
2. Barber shaves everybody in the village who don't shave themselves &
noone else
3. 1 & 2 must be true in any point of time, no time tricks allowed.
So your code for solving the puzzle with all 3 rules included would be
highly appreciated.
My answer is that barber makes some exception now & then to his policy
and because beards are out of fashion at his village & beside it's a
bad propaganda he shaves himself. So I still believe that problem is
uncomputable without changing/misinterpretetting the puzzle.
Slobodan
Slobodan
Slobodan Blazeski wrote:
> On Jul 4, 4:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Slobodan Blazeski wrote:
>>
>>>On Jul 4, 1:58 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>Slobodan Blazeski wrote:
>>
>>>>>On Jul 4, 1:44 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>Slobodan Blazeski wrote:
>>
>>>>>>>On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>>>Slobodan Blazeski wrote:
>>
>>>>>>>>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>>>>>········@gmail.com wrote:
>>
>>>>>>>>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>>
>>>>>>>>>>>>Yeah, it was a completely ironic and deliberately self-referential post
>>>>>>>>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
>>>>>>>>>>>>you?
>>
>>>>>>>>>>>OK, I'll try harder in the future to keep up.
>>
>>>>>>>>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>>
>>>>>>>>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>>>>>>>>>nil
>>>>>>>>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
>>>>>>>>>t
>>
>>>>>>>>What part of set theory do you not understand?
>>
>>>>>>>>hth,kt
>>
>>>>>>>Once upon a time in a village far far away there was a barbershop
>>>>>>>whose barber had a strict policy of shaving everybody in the village
>>>>>>>who didn't shave themselves and noone else. Should the barber shave
>>>>>>>himself ?
>>
>>>>>>I see. You would rather talk about computability than set theory. Not
>>>>>>that this example is at all interesting.
>>
>>>>>>hth,kt- Hide quoted text -
>>
>>>>>>- Show quoted text -
>>
>>>>>Gave up already ?
>>
>>>>Decided already. You stuck? Hell, it was your (boring) riddle.
>>
>>>>kt- Hide quoted text -
>>
>>>>- Show quoted text -
>>
>>>Actually I was talking about a set theory,...
>>
>>When are you people goin to learn to listen to me? That is almost
>>entirely about computability, and only trivially about set theory. F*ck,
>>it is a simple find-if.
>>
>>Tell you what, translate the riddle into Lisp and see what you get,
>>maybe then you can understand His Kennyness.
>>
>>
>>>as the puzzle I presented,
>>>called a Barber paradox
>>
>>Typical academics, naming a triviality. Reminds me of PAIP.
>>
>>
>>>... and attributed to Bertrand Russell and
>>>analogous to Russell's Paradox, which is devised to show that set
>>>theory as it was used by Georg Cantor and Gottlob Frege contained
>>>contradictions.
>>
>>No, it is not a contradiction. The problem statement was perfectly
>>comprehensible. There is a problem, but it is not one of contradiction
>>which involves saying X is Y and X is not Y.
>>
>>
>>
>>
>>>If the barber does not shave himself, he must abide by the rule and
>>>shave himself.
>>>If he does shave himself, according to the rule he shouldn't shave
>>>himself.
>>
>>Omigod, you thought Myself could not figure that out? Of course those
>>observations are fine, now stop whining and answer the damn question:
>>should the barber shave himself? What happens? Look at your Lisp code.
>>
>>hth,kt
>
>
> My lisp code gets in recursive stack overflow if all below premises
> are included:
> 1. Village, Villagers & barber must exist.
> 2. Barber shaves everybody in the village who don't shave themselves &
> noone else
> 3. 1 & 2 must be true in any point of time, no time tricks allowed.
>
> So your code for solving the puzzle with all 3 rules included would be
> highly appreciated.
> My answer is that barber makes some exception now & then to his policy
Oh, cool, I did not know we could change the riddle to solve it. Hang
on... what riddle are we then solving, the original or the new one?
> and because beards are out of fashion at his village & beside it's a
> bad propaganda he shaves himself. So I still believe that problem is
> uncomputable without changing/misinterpretetting the puzzle.
<sigh> So close, yet so far. You failed to connect this deep insight
with my original response to the riddle: it ain't about set theory. As
with statements such as "I always lie.", an attempt to determine the
truth leads to an infinite recursion. There is nothing more interesting
here than the idea that natural language can set up an infinite
recursion via self-reference, or in the barber case by having a
predicate deciding membership in a set also determine the population of
a set.
kt
On Jul 5, 1:57 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Jul 4, 4:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>Slobodan Blazeski wrote:
>
> >>>On Jul 4, 1:58 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>Slobodan Blazeski wrote:
>
> >>>>>On Jul 4, 1:44 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>Slobodan Blazeski wrote:
>
> >>>>>>>On Jul 4, 12:22 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>>>Slobodan Blazeski wrote:
>
> >>>>>>>>>On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>>>>>········@gmail.com wrote:
>
> >>>>>>>>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>>>>>>>>>>>Yeah, it was a completely ironic and deliberately self-referential post
> >>>>>>>>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
> >>>>>>>>>>>>you?
>
> >>>>>>>>>>>OK, I'll try harder in the future to keep up.
>
> >>>>>>>>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>
> >>>>>>>>>=>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> >>>>>>>>>nil
> >>>>>>>>>-=>(best-ng-on-the-usenet-p comp.lang.lisp)
> >>>>>>>>>t
>
> >>>>>>>>What part of set theory do you not understand?
>
> >>>>>>>>hth,kt
>
> >>>>>>>Once upon a time in a village far far away there was a barbershop
> >>>>>>>whose barber had a strict policy of shaving everybody in the village
> >>>>>>>who didn't shave themselves and noone else. Should the barber shave
> >>>>>>>himself ?
>
> >>>>>>I see. You would rather talk about computability than set theory. Not
> >>>>>>that this example is at all interesting.
>
> >>>>>>hth,kt- Hide quoted text -
>
> >>>>>>- Show quoted text -
>
> >>>>>Gave up already ?
>
> >>>>Decided already. You stuck? Hell, it was your (boring) riddle.
>
> >>>>kt- Hide quoted text -
>
> >>>>- Show quoted text -
>
> >>>Actually I was talking about a set theory,...
>
> >>When are you people goin to learn to listen to me? That is almost
> >>entirely about computability, and only trivially about set theory. F*ck,
> >>it is a simple find-if.
>
> >>Tell you what, translate the riddle into Lisp and see what you get,
> >>maybe then you can understand His Kennyness.
>
> >>>as the puzzle I presented,
> >>>called a Barber paradox
>
> >>Typical academics, naming a triviality. Reminds me of PAIP.
>
> >>>... and attributed to Bertrand Russell and
> >>>analogous to Russell's Paradox, which is devised to show that set
> >>>theory as it was used by Georg Cantor and Gottlob Frege contained
> >>>contradictions.
>
> >>No, it is not a contradiction. The problem statement was perfectly
> >>comprehensible. There is a problem, but it is not one of contradiction
> >>which involves saying X is Y and X is not Y.
>
> >>>If the barber does not shave himself, he must abide by the rule and
> >>>shave himself.
> >>>If he does shave himself, according to the rule he shouldn't shave
> >>>himself.
>
> >>Omigod, you thought Myself could not figure that out? Of course those
> >>observations are fine, now stop whining and answer the damn question:
> >>should the barber shave himself? What happens? Look at your Lisp code.
>
> >>hth,kt
>
> > My lisp code gets in recursive stack overflow if all below premises
> > are included:
> > 1. Village, Villagers & barber must exist.
> > 2. Barber shaves everybody in the village who don't shave themselves &
> > noone else
> > 3. 1 & 2 must be true in any point of time, no time tricks allowed.
>
> > So your code for solving the puzzle with all 3 rules included would be
> > highly appreciated.
> > My answer is that barber makes some exception now & then to his policy
>
> Oh, cool, I did not know we could change the riddle to solve it. Hang
> on... what riddle are we then solving, the original or the new one?
>
> > and because beards are out of fashion at his village & beside it's a
> > bad propaganda he shaves himself. So I still believe that problem is
> > uncomputable without changing/misinterpretetting the puzzle.
>
> <sigh> So close, yet so far. You failed to connect this deep insight
> with my original response to the riddle: it ain't about set theory. As
> with statements such as "I always lie.", an attempt to determine the
> truth leads to an infinite recursion. There is nothing more interesting
> here than the idea that natural language can set up an infinite
> recursion via self-reference, or in the barber case by having a
> predicate deciding membership in a set also determine the population of
> a set.
>
> kt
Ok, that's solved but recursion is only primitive one . How about
natural language defining non primitive recursion ? Like Ackermanns,
oops sorry,I meanfunction defined by below code:
(defun ackermann (m n)
(cond ((zerop m) (1+ n))
((and (> m 0) (zerop n))
(ackermann (1- m) 1))
((and (> m 0) (> n 0))
(ackermann (1- m) (ackermann m (1- n))))))
Slobodan
Ken Tilton <···········@optonline.net> writes:
> <sigh> So close, yet so far. You failed to connect this deep insight
> with my original response to the riddle: it ain't about set theory.
I agree here.
> As with statements such as "I always lie.", an attempt to determine
> the truth leads to an infinite recursion.
I disagree here. But first, some background: As an ex-hardware guy, I
am always amazed at programmers and logicians alike who take these
paradoxes as being an issue. Like you, I recognize them for what they
are and dismiss them, but others must agonize over the horrible flaw
in logic that makes the whole field of logic suspect. However, in the
hardware world, and especially in the world of digital electronics, we
have a specific term for these paradoxical situations, and we have
compartmentalized them very nicely and made good use of them: they are
called oscillators. In simplest digital logic terms, an oscillator is
an inverter (a NOT gate, if you will - if the input is a 1 the output
is a 0 and vice versa) whose output feeds back into its input. What
happens, during its operation, is that the natural delays (and usually
some elements are added to force longer delays) in the electronics
will cause the output to oscillate between 0 and 1, usually at regular
intervals. What is such a device good for? Well, when you talk about
your 2.3Ghz laptop, you are describing the frequency at which the
basic system's oscillator, or clock, changes from 0 to 1 and back to
0. So almost everyone (not only hardware geeks) refer to such
oscillators once in a while.
Finally, the statement of the previous poster that there is no time
element is naive; in pure logic there is theoretically no delay
between the input and output of a logic element, but in real life
there is always a delay. In hardware I have seen inverters that will
oscillate between 0 and 1 at some rate which depends on the natural
delay within its gate (this is the most common case, because in
digital logic pains are taken to ensure that there are only two
states; in technical terms the transistors are biased to ensure
saturation in both directions), but I have also seen inverters which
have a very strong analog component to them; when these are hooked up
as oscillators (or, more frequently, when a flaw in the circuitry
causes them to be joined in that way accidentally, they don't
oscillate, but instead they will settle into a stable state somewhere
in the no-mans-land of voltage that is between a 0 and a 1. Obviously,
these aren't as useful.
Now, back to my issue; it is true that recursion and iteration are
essentially the same, but recursion implies depth, and iteration
implies passage of time, so this is really an infinitely oscillating
iteration.
--
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
Duane Rettig wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>><sigh> So close, yet so far. You failed to connect this deep insight
>>with my original response to the riddle: it ain't about set theory.
>
>
> I agree here.
>
>
>>As with statements such as "I always lie.", an attempt to determine
>>the truth leads to an infinite recursion.
>
>
> I disagree here. But first, some background: As an ex-hardware guy, I
> am always amazed at programmers and logicians alike who take these
> paradoxes as being an issue. Like you, I recognize them for what they
> are and dismiss them, but others must agonize over the horrible flaw
> in logic that makes the whole field of logic suspect. However, in the
> hardware world, and especially in the world of digital electronics, we
> have a specific term for these paradoxical situations, and we have
> compartmentalized them very nicely and made good use of them: they are
> called oscillators. In simplest digital logic terms, an oscillator is
> an inverter (a NOT gate, if you will - if the input is a 1 the output
> is a 0 and vice versa) whose output feeds back into its input. What
> happens, during its operation, is that the natural delays (and usually
> some elements are added to force longer delays) in the electronics
> will cause the output to oscillate between 0 and 1, usually at regular
> intervals. What is such a device good for? Well, when you talk about
> your 2.3Ghz laptop, you are describing the frequency at which the
> basic system's oscillator, or clock, changes from 0 to 1 and back to
> 0. So almost everyone (not only hardware geeks) refer to such
> oscillators once in a while.
>
> Finally, the statement of the previous poster that there is no time
> element is naive; in pure logic there is theoretically no delay
> between the input and output of a logic element, but in real life
> there is always a delay. In hardware I have seen inverters that will
> oscillate between 0 and 1 at some rate which depends on the natural
> delay within its gate (this is the most common case, because in
> digital logic pains are taken to ensure that there are only two
> states; in technical terms the transistors are biased to ensure
> saturation in both directions), but I have also seen inverters which
> have a very strong analog component to them; when these are hooked up
> as oscillators (or, more frequently, when a flaw in the circuitry
> causes them to be joined in that way accidentally, they don't
> oscillate, but instead they will settle into a stable state somewhere
> in the no-mans-land of voltage that is between a 0 and a 1. Obviously,
> these aren't as useful.
>
> Now, back to my issue; it is true that recursion and iteration are
> essentially the same, but recursion implies depth, and iteration
> implies passage of time, so this is really an infinitely oscillating
> iteration.
>
Well, to determine the truth of "I always lie" I must examine all my
assertions to determine if each is true. No problem, I am a man of few
words. One of my assertions is that I have a pack of hounds for troll
hunts. Fine, I lied. Another is that I always lie. Ok, let's see if that
one is true...
kt
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Ken Tilton <···········@optonline.net> writes:
> Well, to determine the truth of "I always lie" I must examine all my
> assertions to determine if each is true. No problem, I am a man of few
> words. One of my assertions is that I have a pack of hounds for troll
> hunts. Fine, I lied. Another is that I always lie. Ok, let's see if
> that one is true...
and so on, and so on, and so on, in an infinite iteration (or until
you care to just turn it off). This is a perfect example of a simple
inverter-based oscillator. Now, can you do this a billion times per
second, like your computer does?
--
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
Duane Rettig wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Well, to determine the truth of "I always lie" I must examine all my
>>assertions to determine if each is true. No problem, I am a man of few
>>words. One of my assertions is that I have a pack of hounds for troll
>>hunts. Fine, I lied. Another is that I always lie. Ok, let's see if
>>that one is true...
>
>
> and so on, and so on, and so on, in an infinite iteration
With each investigation still underway as the next (same) commences, I
find myself liking the word "recursion". Not that I do not admire the
attempt to gloss that over with "and so on and so on".
(or until
> you care to just turn it off). This is a perfect example of a simple
> inverter-based oscillator.
Exactly how comfortable you making an analogy between a physical system
operating ineluctably in parallel with an algorithm being executed
sequentially?
> Now, can you do this a billion times per
> second, like your computer does?
>
My neurons may be slow, but I do have ten or a hundred billion and with
sufficient caffeine...
hth,kt
Mark H. wrote:
> Hey folks, going to stop arguing about barbers and talk about
> interesting things like concurrent GC's any time soon?
Fortunately we have the Headscarves Precedent, so be a good chap would
you? and let us know when the logic vs computability parallel vs serial
recursive vs iterative debate falls below that bar.
We call this "Headscarves Immunity" on c.l.l.
Now what on Earth is wrong with the Yankee offense?!
hth,k
On Jul 5, 3:36 pm, Ken Tilton <···········@optonline.net> wrote:
> Mark H. wrote:
> > Hey folks, going to stop arguing about barbers and talk about
> > interesting things like concurrent GC's any time soon?
>
> Fortunately we have the Headscarves Precedent, so be a good chap would
> you? and let us know when the logic vs computability parallel vs serial
> recursive vs iterative debate falls below that bar.
Ha! ;-P
mfh
Ken Tilton <···········@optonline.net> writes:
> Duane Rettig wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>>Well, to determine the truth of "I always lie" I must examine all my
>>>assertions to determine if each is true. No problem, I am a man of few
>>>words. One of my assertions is that I have a pack of hounds for troll
>>>hunts. Fine, I lied. Another is that I always lie. Ok, let's see if
>>>that one is true...
>> and so on, and so on, and so on, in an infinite iteration
>
> With each investigation still underway as the next (same) commences, I
> find myself liking the word "recursion". Not that I do not admire the
> attempt to gloss that over with "and so on and so on".
OK, I've looked at definitions, and it seems it fits. And don't the
schemers keep telling us that recursion _is_ iteration?...
> (or until
>> you care to just turn it off). This is a perfect example of a simple
>> inverter-based oscillator.
>
> Exactly how comfortable you making an analogy between a physical
> system operating ineluctably in parallel with an algorithm being
> executed sequentially?
Today: very comfortable. Tomorrow I go back to work...
>> Now, can you do this a billion times per
>> second, like your computer does?
>>
>
> My neurons may be slow, but I do have ten or a hundred billion and
> with sufficient caffeine...
Next time your in California, I'll take you to Starbuck's and we can
test that theory...
--
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
Duane Rettig wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Duane Rettig wrote:
>>
>>>Ken Tilton <···········@optonline.net> writes:
>>>
>>>
>>>>Well, to determine the truth of "I always lie" I must examine all my
>>>>assertions to determine if each is true. No problem, I am a man of few
>>>>words. One of my assertions is that I have a pack of hounds for troll
>>>>hunts. Fine, I lied. Another is that I always lie. Ok, let's see if
>>>>that one is true...
>>>
>>>and so on, and so on, and so on, in an infinite iteration
>>
>>With each investigation still underway as the next (same) commences, I
>>find myself liking the word "recursion". Not that I do not admire the
>>attempt to gloss that over with "and so on and so on".
>
>
> OK, I've looked at definitions, and it seems it fits.
Dr. Minski can tell you about the usefulness of definitions in
understanding natural language.
hth,kt
On Jul 5, 6:59 pm, Duane Rettig <····@franz.com> wrote:
> Finally, the statement of the previous poster that there is no time
> element is naive; in pure logic there is theoretically no delay
> between the input and output of a logic element, but in real life
> there is always a delay.
And besides, the more interesting logics have a notion of time or
something equivalent.
Slobodan Blazeski <·················@gmail.com> writes:
> My answer is that barber makes some exception now & then to his policy
> and because beards are out of fashion at his village & beside it's a
> bad propaganda he shaves himself. So I still believe that problem is
You are rambling. Must you do it on c.l.l?
Tamas
Slobodan Blazeski <·················@gmail.com> writes:
>> > If the barber does not shave himself, he must abide by the rule and
>> > shave himself.
>> > If he does shave himself, according to the rule he shouldn't shave
>> > himself.
>>
>> Omigod, you thought Myself could not figure that out? Of course those
>> observations are fine, now stop whining and answer the damn question:
>> should the barber shave himself? What happens? Look at your Lisp code.
>>
>> hth,kt
>
> My lisp code gets in recursive stack overflow if all below premises
> are included:
> 1. Village, Villagers & barber must exist.
> 2. Barber shaves everybody in the village who don't shave themselves &
> noone else
> 3. 1 & 2 must be true in any point of time, no time tricks allowed.
>
> So your code for solving the puzzle with all 3 rules included would be
> highly appreciated.
> My answer is that barber makes some exception now & then to his policy
> and because beards are out of fashion at his village & beside it's a
> bad propaganda he shaves himself. So I still believe that problem is
> uncomputable without changing/misinterpretetting the puzzle.
"Shaving oneself" has not been defined.
What's the operative difference between somebody shaving oneself and
somebody going to the barber to get shaved? Let's ask the IRS: taxes!
For the IRS, "shaving oneself" is defined as shaving without payment
(and therefore untaxed). The solution is easy: the barber doesn't
shave himself: he pays himself for the shaving, and pay taxes on that.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Wed, 04 Jul 2007 06:22:44 -0400, Ken Tilton <···········@optonline.net> tried
to confuse everyone with this message:
>Slobodan Blazeski wrote:
>> On Jul 3, 8:26 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>········@gmail.com wrote:
>>>
>>>>On Jul 3, 10:59 am, Ken Tilton <···········@optonline.net> wrote:
>>>
>>>>>Yeah, it was a completely ironic and deliberately self-referential post
>>>>>meant to amuse and edify. How did I know it would be lost on a dolt like
>>>>>you?
>>>
>>>>OK, I'll try harder in the future to keep up.
>>>
>>>I was thinking "catch up". You come into one of the better NGs on UseNet
>>
>>
>> =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>> nil
>> -=>(best-ng-on-the-usenet-p comp.lang.lisp)
>> t
>>
>
>What part of set theory do you not understand?
>
I don't understand if it's consistent or not...
--
|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) |______________|
Slobodan Blazeski wrote:
> =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> nil
> -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> t
>
Er. The number one song is still a member of the set of top ten songs,
which was probably kenny's point.
On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
> Slobodan Blazeski wrote:
> > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> > nil
> > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> > t
>
> Er. The number one song is still a member of the set of top ten songs,
> which was probably kenny's point.
I'm Strongly suspicious about flawed set theory. Beside the mentioned
Barber paradox I will quote the famous 21st century mathematician
Neely saying: ...Two is not a winner and three nobody remembers ...
On 4 Jul, 14:39, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
>
> > Slobodan Blazeski wrote:
> > > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> > > nil
> > > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> > > t
>
> > Er. The number one song is still a member of the set of top ten songs,
> > which was probably kenny's point.
>
> I'm Strongly suspicious about flawed set theory. Beside the mentioned
> Barber paradox I will quote the famous 21st century mathematician
> Neely saying: ...Two is not a winner and three nobody remembers ...
Set theory isn't flawed.
No one shaves the barber, [s]he can not exist.
On Jul 4, 4:02 pm, Chris Russell <·····················@gmail.com>
wrote:
> On 4 Jul, 14:39, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
>
> > > Slobodan Blazeski wrote:
> > > > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> > > > nil
> > > > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> > > > t
>
> > > Er. The number one song is still a member of the set of top ten songs,
> > > which was probably kenny's point.
>
> > I'm Strongly suspicious about flawed set theory. Beside the mentioned
> > Barber paradox I will quote the famous 21st century mathematician
> > Neely saying: ...Two is not a winner and three nobody remembers ...
>
> Set theory isn't flawed.
> No one shaves the barber, [s]he can not exist.
Nice try but unacceptable, villager, village & barber must exist. And
don't the time trick neither.
On Thu, 05 Jul 2007 03:53:27 -0700, Slobodan Blazeski
<·················@gmail.com> tried to confuse everyone with this message:
>On Jul 4, 4:02 pm, Chris Russell <·····················@gmail.com>
>wrote:
>> On 4 Jul, 14:39, Slobodan Blazeski <·················@gmail.com>
>> wrote:
>>
>> > On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
>>
>> > > Slobodan Blazeski wrote:
>> > > > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>> > > > nil
>> > > > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
>> > > > t
>>
>> > > Er. The number one song is still a member of the set of top ten songs,
>> > > which was probably kenny's point.
>>
>> > I'm Strongly suspicious about flawed set theory. Beside the mentioned
>> > Barber paradox I will quote the famous 21st century mathematician
>> > Neely saying: ...Two is not a winner and three nobody remembers ...
>>
>> Set theory isn't flawed.
>> No one shaves the barber, [s]he can not exist.
>
>Nice try but unacceptable, villager, village & barber must exist. And
>don't the time trick neither.
>
I know the answer: the barber is a woman. Or was that another puzzle?
--
|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) |______________|
On Jul 5, 5:44 pm, ····@mail.ru (Timofei Shatrov) wrote:
> On Thu, 05 Jul 2007 03:53:27 -0700, Slobodan Blazeski
> <·················@gmail.com> tried to confuse everyone with this message:
>
>
>
>
>
> >On Jul 4, 4:02 pm, Chris Russell <·····················@gmail.com>
> >wrote:
> >> On 4 Jul, 14:39, Slobodan Blazeski <·················@gmail.com>
> >> wrote:
>
> >> > On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
>
> >> > > Slobodan Blazeski wrote:
> >> > > > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> >> > > > nil
> >> > > > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> >> > > > t
>
> >> > > Er. The number one song is still a member of the set of top ten songs,
> >> > > which was probably kenny's point.
>
> >> > I'm Strongly suspicious about flawed set theory. Beside the mentioned
> >> > Barber paradox I will quote the famous 21st century mathematician
> >> > Neely saying: ...Two is not a winner and three nobody remembers ...
>
> >> Set theory isn't flawed.
> >> No one shaves the barber, [s]he can not exist.
>
> >Nice try but unacceptable, villager, village & barber must exist. And
> >don't the time trick neither.
>
> I know the answer: the barber is a woman. Or was that another puzzle?
>
No that is the surgeon puzzle , invented by the feminists.
Slobodan Blazeski schrieb:
> On Jul 4, 4:02 pm, Chris Russell <·····················@gmail.com>
> wrote:
>> On 4 Jul, 14:39, Slobodan Blazeski <·················@gmail.com>
>> wrote:
>>
>>> On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
>>>> Slobodan Blazeski wrote:
>>>>> =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>>>>> nil
>>>>> -=>(best-ng-on-the-usenet-p comp.lang.lisp)
>>>>> t
>>>> Er. The number one song is still a member of the set of top ten songs,
>>>> which was probably kenny's point.
>>> I'm Strongly suspicious about flawed set theory. Beside the mentioned
>>> Barber paradox I will quote the famous 21st century mathematician
>>> Neely saying: ...Two is not a winner and three nobody remembers ...
>> Set theory isn't flawed.
>> No one shaves the barber, [s]he can not exist.
>
> Nice try but unacceptable, villager, village & barber must exist. And
> don't the time trick neither.
The barber about which you talked does not exist.
The one you talked about was "shaving everybody in the village
who didn't shave themselves and noone else".
But the barber in villages that exist don't follow this rule.
If they shave themselves or if they don't, they will break the rule
and thus are not described by your text.
Andr� Thieme <······························@justmail.de> writes:
> Slobodan Blazeski schrieb:
>> On Jul 4, 4:02 pm, Chris Russell <·····················@gmail.com>
>> wrote:
>>> On 4 Jul, 14:39, Slobodan Blazeski <·················@gmail.com>
>>> wrote:
>>>
>>>> On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
>>>>> Slobodan Blazeski wrote:
>>>>>> =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>>>>>> nil
>>>>>> -=>(best-ng-on-the-usenet-p comp.lang.lisp)
>>>>>> t
>>>>> Er. The number one song is still a member of the set of top ten songs,
>>>>> which was probably kenny's point.
>>>> I'm Strongly suspicious about flawed set theory. Beside the mentioned
>>>> Barber paradox I will quote the famous 21st century mathematician
>>>> Neely saying: ...Two is not a winner and three nobody remembers ...
>>> Set theory isn't flawed.
>>> No one shaves the barber, [s]he can not exist.
>> Nice try but unacceptable, villager, village & barber must exist. And
>> don't the time trick neither.
>
> The barber about which you talked does not exist.
> The one you talked about was "shaving everybody in the village
> who didn't shave themselves and noone else".
> But the barber in villages that exist don't follow this rule.
> If they shave themselves or if they don't, they will break the rule
> and thus are not described by your text.
Nah; you've got to think outside the box. The barber has a split
personality.
--
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
Slobodan Blazeski <·················@gmail.com> writes:
> On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
>> Slobodan Blazeski wrote:
>> > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
>> > nil
>> > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
>> > t
>>
>> Er. The number one song is still a member of the set of top ten songs,
>> which was probably kenny's point.
>
> I'm Strongly suspicious about flawed set theory. Beside the mentioned
> Barber paradox I will quote the famous 21st century mathematician
> Neely saying: ...Two is not a winner and three nobody remembers ...
If you find that a conceptual framework is "flawed" because it is
possible to formulate a paradox, a nonsensical (or non-provable)
statement, then Kurt Gödel must have made your life full of suspicion.
Tamas
On Jul 4, 4:11 pm, Tamas Papp <······@gmail.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > On Jul 4, 3:06 pm, David Golden <············@oceanfree.net> wrote:
> >> Slobodan Blazeski wrote:
> >> > =>(one-of-the-better-NGs-on-UseNet-p comp.lang.lisp)
> >> > nil
> >> > -=>(best-ng-on-the-usenet-p comp.lang.lisp)
> >> > t
>
> >> Er. The number one song is still a member of the set of top ten songs,
> >> which was probably kenny's point.
>
> > I'm Strongly suspicious about flawed set theory. Beside the mentioned
> > Barber paradox I will quote the famous 21st century mathematician
> > Neely saying: ...Two is not a winner and three nobody remembers ...
>
> If you find that a conceptual framework is "flawed" because it is
> possible to formulate a paradox, a nonsensical (or non-provable)
> statement, then Kurt Gödel must have made your life full of suspicion.
>
> Tamas
Yeah I even tried his language but get quickly discouraged because is
strongly typed. Actually I don't give a damn if set theory is flawed
or not the bottom line is screw 2nd and who cares who is the 10th best
driver at f1 people
On Jul 2, 11:30 pm, ········@gmail.com wrote:
> On Jul 2, 4:32 pm, Rainer Joswig <······@lisp.de> wrote:
>
> > Sorry, but your remarks are unfriendly and I will
> > killfile you.
>
> Well, that's too bad because I wasn't singly you out personally and
> have found many of your comments useful and interesting and it's a
> shame you won't know I feel that way that because you won't be reading
> this.
>
> For anyone still reading, in other reddit comments I mention that the
> reason for c.l.l.'s quick reaction of labeling a comment a troll is
> due to the large number of real trolls that come through this group.
> I think because of that there is sometimes an over reaction of
> declaring someone a troll when they have a legitimate criticism of
> Lisp or an honest question that unfortunately resembles a question or
> comment that was a troll in the past.
>
> Beyond that, there seems to be a paranoia about adding anything in any
> way to "Lisp". Notice the quotation marks, because I don't care if
> the existing Common Lisp standard ever officially changes, but I think
> "Lisp" could benefit from more defacto-standardization of picking some
> core functionality and convincing the various Lisp implementors to
> bundle it through social pressure and pitching in to help.
>
> Elsewhere in the same comments thread as my offending remark, someone
> asks why Lisp has no literal syntax for hash tables. I pointed out
> that Lisp syntax has literals for anything tree like, and that Lisp
> prefers consistency of syntax (enabling powerful macros, etc.) instead
> of special case syntaxes like Perl, Python, Ruby, etc.
>
> Well, that did make me curious why Common Lisp does not have a reader
> syntax for hash tables. In the process, I discovered hash tables are
> one of the few things that lack a reader syntax (numbers, strings,
> lists, vectors, structs all covered; did I miss any?). Investigating
> more, I found a long, involved c.l.l. thread from 1999 discussing this
> very issue. The conversation revolved around "what about the edge
> cases?" You might not be able to re-establish notions of identity
> when you read your hash table back in, thus breaking semantics.
>
> Well, so what? It's an edge case. Document the limitations somewhere
> and move on. (Which several people advocated.)
>
> But there is no one who can just say "let's just make a decision and
> move on" for Lisp. No Matz, Guido, Larry, or Stroustrup. The spec is
> great. But the fear of establishing any kind of consensus for
> anything not in the spec is a shortcoming of the Lisp community, in my
> opinion.
>
> My criticism goes to Common Lisp culture and community as a whole, not
> to any one individual. It is good to have individuals in the
> community that say "wait a sec, what about..." before blindly pushing
> forward with a new idea. But when those sentiments overwhelm the
> community as a whole and change, thus progress, becomes impossible, I
> consider that a broken culture.
>
> So please don't think I'm picking out individuals here as the problem
> with Lisp. But I do think the sum of Lisp culture is holding Lisp
> back from its full potential at this junction.
>
> -jimbo
So you would prefer a dictator ?
Slobodan Blazeski
On Jul 3, 10:48 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> So you would prefer a dictator ?
For a programming language, a dictator certainly has its uses. Of
course, it all depends on the quality, taste, and judgement of the
dictator in question.
I think a dictator would solve some of the cultural problems of Common
Lisp. Maybe there is a better solution to be had from a mechanism for
forming consensus, but I do not see any recent successes in this
regard.
-jimbo
On Jul 2, 8:33 pm, ········@gmail.com wrote:
> On Jul 2, 3:24 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > There's many libraries that are relatively easy to find and
> > install,iterate, series, cells, qi....For a lot of the other mentioned
> > there is a library already ready to use or code exist or as in call/cc
> > feature is questionable, some like it some believe it doesn't worth.
> > So you already have a most powerfull toolbox from any other
> > lanaguages, you only need to build with it.
> > The only thing that I really believe that lisp is missing is erlang/
> > termite like concurrency, but time will tell.
> > For now we only need more apps written in it.
>
> I work at a university, and just out of curiosity I sat in on a talk
> given by young Apple employees to CS students considering applying
> there for internships or jobs.
>
> In response to a question about how to present one's self in an
> interview at Apple, one of the speakers replied (paraphrase) "Whatever
> you do, don't say Mac OS X is perfect.
Yes it shares a simigliar problem with lisp, lacks consumer software
since all the DESKTOP software is written for Windows only.
> If you can't find anything
> wrong with it, how could you possibly have any chance of making it
> better?"
>
> I think that would be a healthy attitude to take towards Lisp, or,
> frankly, anything else you like.
Agreed.
> If you think you have found any
> piece of utopia on this Earth, you are probably either deceiving
> yourself or need to raise your standards.
>
I didn't say common lisp is perfect, but is the best thing (language +
implementation + libraries + community + literature) I've found after
going through: c, c++, basic, pascal/delphi, c#, TSQL and some
python , java, php , ocaml & erlang.
> Now, to your credit, you do mention the concurrency thing. But do you
> really think there is nothing else that could make Lisp better?
>
AllegroCache in lisp that I could afford ( 2000$ at most)
> And with the reliance on the idea that "you can always add that as a
> library" you come close to the Godwin's Law of Referencing Turing
> Completeness [1].
>
I prefer embedded database as library.
> To avoid hypocrisy, here are some criticisms I made about Lisp:
>
> http://programming.reddit.com/info/1z8b8/comments/c1zbmr
1 I think the main place to find out about Lisp is comp.lang.lisp, and
a lot of the long time posters there are seriously socially
challenged.
Names or an apology about above. Else I'll take this as an insult
for a lot of people I have in high esteem.
--People newly interested in Lisp can often be called a troll when
they ask for comparisons between Lisp and other languages, for
example.
Asking a same question every week from a same person who doesn't even
show that at least understands at least a little lisp to continue
conversation with him is trolling in my not so humble opinion but
YMMW
2. Too many Lisps to choose from. This is both good and bad. The good
is that Common Lisp is available on a lot of platforms with a lot of
different performance profiles and different built in libraries. The
bad news is that it is difficult for people new to Lisp to pick one to
start using and that a Common Lisp library may or may not support the
Lisp you picked.
Lispers are spoiled of choice, that's very bad thing . The good thing
is that any lisp, whose development didn't stoppeed in 1986, will do
for a newbie. Afterwards they'll be able to choose what suits them
best.
3. Batteries not included. This is not a problem with commercial Lisp,
their batteries are included and generally pretty good. But the free
Lisps do not include the breadth of functionality in, say, Python,
Perl or Ruby. That leaves it to the new Lisper to evaluate and choose
libraries on his own with no prior experience with the language to
draw on.
Ever heard of starter pack , or lisp in a box.
4. Setting up the development environment. Again, this is only a
problem for free Lisps, the commercial Lisps have good, integrated
editors and IDEs ready to go. The free Lisps mostly rely on SLIME and
emacs. This is not so bad if you know and like Emacs (my situation),
but even then there are a few steps to get started, like downloading
SLIME and your free Lisp separately, installing both, and configuring
them to work together.
You use :
a: Free commercial lisp like Allegro express, LW personal
b: Lisp in a box comes with everything you need.
5.
Not wanting to try new things. Ruby, Python and Perl are at least
syntactically similar to C and Java and most programmers probably
already know at least one of these. Lisp is different, but different
for good reasons (read what Paul Graham has to say about parentheses
and Lisp macros). I think Lisp should improve on 1 - 4, but I believe
Lisp should not try to appeal to programmers who don't want to learn
something new. That will make Lisp worse, not better, in my opinion.
Agreed.
>
> These are more criticisms of Common Lisp culture and community, and I
> think most of the weaknesses of Common Lisp reside there as opposed to
> something in or not in the text of the standard itself.
>
> -jimbo
>
> [1]http://programming.reddit.com/info/21vs0/comments/c022160
On Jul 3, 10:38 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> 1 I think the main place to find out about Lisp is comp.lang.lisp, and
> a lot of the long time posters there are seriously socially
> challenged.
>
> Names or an apology about above. Else I'll take this as an insult
> for a lot of people I have in high esteem.
I apologize for the words "socially challenged". That was uncivil, ad-
hominem, not useful, and detracts from the point I was trying to
make. I am sorry.
I stand by the claim that legitimate questions, comments and
criticisms have been labeled trolls on comp.lang.lisp. I cited an
example in a reply to Ken elsewhere. I believe I can find others.
Searching for "not a troll" in this group reveals a lot of meta
discussion about who is a troll and who is not.
-jimbo
········@gmail.com wrote:
> On Jul 3, 10:38 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>>1 I think the main place to find out about Lisp is comp.lang.lisp, and
>>a lot of the long time posters there are seriously socially
>>challenged.
>>
>>Names or an apology about above. Else I'll take this as an insult
>>for a lot of people I have in high esteem.
>
>
> I apologize for the words "socially challenged". That was uncivil, ad-
> hominem, not useful, and detracts from the point I was trying to
> make. I am sorry.
>
> I stand by ...
Jeez, you do not even know how to admit you were wrong. You try getting
credit for it and in the next sentence repeat the original stupidity. We
have a pool and a pond, the pond would be good for you.
kxo
On Jul 4, 12:01 am, Ken Tilton <···········@optonline.net> wrote:
> Jeez, you do not even know how to admit you were wrong. You try getting
> credit for it and in the next sentence repeat the original stupidity. We
> have a pool and a pond, the pond would be good for you.
Well, I cited an example of someone that appears to have been a non-
troll called a troll on this newsgroup. So, I would say that part is
an empirical dispute. Even if I'm wrong, I don't think it was an
inherently offensive proposition.
I unreservedly apologize for the name calling part. No excuses, I was
wrong. I'll try to do better.
-jimbo
On Jul 3, 5:28 pm, ········@gmail.com wrote:
> On Jul 3, 10:38 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > 1 I think the main place to find out about Lisp is comp.lang.lisp, and
> > a lot of the long time posters there are seriously socially
> > challenged.
>
> > Names or an apology about above. Else I'll take this as an insult
> > for a lot of people I have in high esteem.
>
> I apologize for the words "socially challenged". That was uncivil, ad-
> hominem, not useful, and detracts from the point I was trying to
> make. I am sorry.
>
> I stand by the claim that legitimate questions, comments and
> criticisms have been labeled trolls on comp.lang.lisp. I cited an
> example in a reply to Ken elsewhere. I believe I can find others.
> Searching for "not a troll" in this group reveals a lot of meta
> discussion about who is a troll and who is not.
>
> -jimbo
Apology is an acknowledgment expressing regret or asking pardon for a
fault or offense. Above looks to me more like mocking than apology. If
your claim was that:
> I stand by the claim that legitimate questions, comments and
> criticisms have been labeled trolls on comp.lang.lisp.
I agree, there's bad people and good people with bad day but your
original claim is:
...a lot of the long time posters there are seriously socially
challenged.
something I find I complete rubbish .
So cool your head a little bit and think what you wrote. And before
you wrote another re to Ken think a little but what he done for lisp
(cells, cello, celtk, cellgtk..) and compare it with your
contributions. We don't have elders here but some respect is question
of good manners.
I wish you happy lisping
Slobodan Blazeski
On Jul 4, 5:54 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> So cool your head a little bit and think what you wrote. And before
> you wrote another re to Ken think a little but what he done for lisp
> (cells, cello, celtk, cellgtk..) and compare it with your
> contributions. We don't have elders here but some respect is question
> of good manners.
Just to be clear, Ken is far too clever to just call someone a troll
and leave it at that. He generally gives them homework or something
constructive to do. So, even while giving someone a hard time, he's
being both instructive and entertaining.
It's "You're a troll. Go away." or the equivalent that I find not
very constructive, except for known repeat offenders.
I like the idea, by the way, of
OK, bad idea to use a beta browser when posting to news groups. What
I meant to say was:
On Jul 5, 10:21 am, ········@gmail.com wrote:
> Just to be clear, Ken is far too clever to just call someone a troll
> and leave it at that. He generally gives them homework or something
> constructive to do. So, even while giving someone a hard time, he's
> being both instructive and entertaining.
>
> It's "You're a troll. Go away." or the equivalent that I find not
> very constructive, except for known repeat offenders.
>
> I like the idea, by the way, of
...Lisp homework assignment as troll/non-troll captcha. That's a
constructive approach to the problem of troll identification.
-jimbo
<········@gmail.com> wrote:
> OK, bad idea to use a beta browser when posting to news groups. What
> I meant to say was:
>
> On Jul 5, 10:21 am, ········@gmail.com wrote:
> > Just to be clear, Ken is far too clever to just call someone a troll
> > and leave it at that. He generally gives them homework or something
> > constructive to do. So, even while giving someone a hard time, he's
> > being both instructive and entertaining.
> >
> > It's "You're a troll. Go away." or the equivalent that I find not
> > very constructive, except for known repeat offenders.
> >
> > I like the idea, by the way, of
>
> ...Lisp homework assignment as troll/non-troll captcha. That's a
> constructive approach to the problem of troll identification.
>
One can do Lisp homework assignments and still be a troll. The
"powerset" thread is a perfect example for someone with moderate
google-fu. Just search for "lisp powerset" and some of the solutions
provided by others magically appear.
On Jul 6, 1:18 pm, ····@stablecross.com (Bob Felts) wrote:
> One can do Lisp homework assignments and still be a troll. The
> "powerset" thread is a perfect example for someone with moderate
> google-fu. Just search for "lisp powerset" and some of the solutions
> provided by others magically appear.
There is at least some chance the person copying and pasting such code
might read some of it by accident, thereby bringing that person a
little closer to enlightenment and thereby making the world a little
better place.
So it's still better than nothing.
-jimbo
On Jul 3, 8:28 am, ········@gmail.com wrote:
> I stand by the claim that legitimate questions, comments and
> criticisms have been labeled trolls on comp.lang.lisp.
Comments and criticisms are generally trolls, so it behooves us to
swiftly identify them as such.
comp.lang.lisp is no worse in this regard than other comp.lang.*
newsgroups such as comp.lang.c and comp.lang.c++.
If anything, there is a kind of child-like naivete that resides here,
manifested in a tendency for the regulars to fall for obvious trolls.
It has occured many times that a painfully obvious troll has been
treated seriously here (but, as a collective, the group seems to be
slowly learning).
On Jul 9, 4:19 am, Kaz Kylheku <········@gmail.com> wrote:
> Comments and criticisms are generally trolls, so it behooves us to
> swiftly identify them as such.
Do you see the problem in this? If there is no place for criticism of
Lisp, Lisp can not possibly improve. And I don't know of any
alternative venue where criticism of Lisp is encouraged.
The problem with prioritizing swiftly identifying trolls is that it is
also likely to have a high number of false positives of non-trolls or
unintentional trolls being labeled trolls and dismissed. That is a
strategy to create a high barrier of entry to Lisp, and perhaps this
is intentional.
> comp.lang.lisp is no worse in this regard than other comp.lang.*
> newsgroups such as comp.lang.c and comp.lang.c++.
I did a little googling on comp.lang.python and comp.lang.ruby.
c.l.python shows 958 hits for troll out of 94737 messages. c.l.ruby
444 hits for troll out of 38531 messages.
c.l.lisp 1,410 results for troll out of 25574 messages.
Maybe c.l.c/c++ are not the standard c.l.lisp should be measuring
itself against?
-jimbo
>
> If anything, there is a kind of child-like naivete that resides here,
> manifested in a tendency for the regulars to fall for obvious trolls.
>
> It has occured many times that a painfully obvious troll has been
> treated seriously here (but, as a collective, the group seems to be
> slowly learning).
On Jul 9, 3:17 pm, Ken Tilton <···········@optonline.net> wrote:
> I see a light.
That light is the reflected glory of Lisp's new-found surging
popularity that you are basking in.
-jimbo
On Jul 9, 9:34 pm, Madhu <·······@net.meer> wrote:
> Your sarcasm aside, if all you are interested is in seeing criticism of
> lisp, there is plenty of out there in the world
> I imagine therre is no dearth of critics since the mid 90s and ai winter.
> Just Look outside this forum.
So this forum is for survivors of the 90s and ai winter to lick their
wounds and commiserate indefinitely?
Where do you suggest I go to find people who want Lisp to be even
better than it is now and used by more people?
-jimbo
ps It's not all sarcasm, by the way. Kenny has helped a lot of people
learn Lisp and write code to accomplish their goals on this forum. He
deserves some non-trivial portion of whatever successes Lisp is seeing
now.
On Jul 3, 10:38 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> Yes it shares a simigliar problem with lisp, lacks consumer software
> since all the DESKTOP software is written for Windows only.
I think there are cultural similarities, as well. Throughout the 90s,
the Mac really was better than Windows. However, Windows was getting
significantly better, and the Mac was not.
I think the overall sense of the general public was that the Mac might
be a little bit better, but not better enough to overcome the cultural
issues of more applications for Windows, more friends who knew Windows
and could give them advice, more places to buy a Windows PC, bigger
variety of supported hardware, etc.
This left the supporters of the Macintosh in the position of defending
things that seemed more and more esoteric, even though they were real
benefits. For example, the Mac had excellent meta-data support built
into the file system. This made it easy to track what applications
could open which files, which application created a file, which icon
to show, application resources bundled with the application, and all
kinds of other useful things. Windows relied on people typing the
correct file extension, and if the user made a mistake, everything
fell apart.
In Mac OS X, Apple decided to favor file extensions over the meta data
in the resource fork for associating files with applications. Many
long time supporters of the Mac were upset at Apple for deliberately
choosing the technically inferior solution.
However, the reasons for Apple's decision were cultural, not
technical. Windows users expected to associate a file with an
application through a file extension. They did not know anything
about resource forks. So when a Mac user gave a file to a Windows
user, the Windows could not easily open it without the expected file
extension. By making the Mac more like Windows, Apple made the choice
of buying a Mac easier.
Now, I'm not saying Lisp should become more like other languages just
to fit in. But I do think that there is a perception that even if
Lisp is better in certain ways than other languages, those other
languages are improving and Lisp is not. The perception might even be
wrong. But even the perception itself is a liability for Lisp
acceptance.
In short, sometimes the cultural outweighs the technical.
> > If you think you have found any
> > piece of utopia on this Earth, you are probably either deceiving
> > yourself or need to raise your standards.
>
> I didn't say common lisp is perfect, but is the best thing (language +
> implementation + libraries + community + literature) I've found after
> going through: c, c++, basic, pascal/delphi, c#, TSQL and some
> python , java, php , ocaml & erlang.
I would agree here, too. Lisp is not perfect, just the best so far
(of the languages I know).
> > Now, to your credit, you do mention the concurrency thing. But do you
> > really think there is nothing else that could make Lisp better?
>
> AllegroCache in lisp that I could afford ( 2000$ at most)
Agreed, and note that I would consider this (pricing) a cultural issue
as well. There was a recent, extended thread on making a commercial
Lisp open source. Price and open source offerings definitely affect
perceptions of Common Lisp.
> Lispers are spoiled of choice, that's very bad thing . The good thing
> is that any lisp, whose development didn't stoppeed in 1986, will do
> for a newbie. Afterwards they'll be able to choose what suits them
> best.
Choice is a barrier to entry for a newbie. By definition as a newbie,
they do not have the information they need to make a good choice. So
the newbie can spend time evaluating the major Lisp distributions, or
just pick Python or Ruby and start hacking. There are multiple
distributions of these, but not as many and there is a default
distribution that new programmers will be steered towards.
Also, please note I clearly said this is a good and a bad thing. The
availability of Common Lisps with different tradeoffs is a good thing
for someone knowledgable about Lisp.
> Ever heard of starter pack , or lisp in a box.
Yes! My preferred solution would be for Starter Pack and Lisp in a
Box packaged together with either SBCL or CLisp is a double clickable
package. The only barrier then is knowing Emacs, but I think Phil
Armitage will have that covered, based on conversation elsewhere in
this thread :).
This one thing would do more than anything else I can think of for
erasing barriers to entry for new Lisp programmers.
> You use :
> a: Free commercial lisp like Allegro express, LW personal
> b: Lisp in a box comes with everything you need.
I tried the Lisp in a Box with Allegro express. I was using it for a
homework project and immediately blew through the Allegro memory limit
because the assignment required processing a lot of data. So I found
AquaMacs (for Mac OS X), which had SLIME pre-installed, and got it
working with SBCL. (This is now my favorite development environment,
by the way, better than any IDE I've ever used.) Not that big of a
deal, but adds just a little bit more of a barrier to entry.
I suppose this could be subsumed under item 2., though.
-jimbo
On Jul 3, 9:10 am, ········@gmail.com wrote:
> In Mac OS X, Apple decided to favor file extensions over the meta data
> in the resource fork for associating files with applications.
Strictly speaking, in Unix we have suffixes, not extensions.
Many
> long time supporters of the Mac were upset at Apple for deliberately
> choosing the technically inferior solution.
Yeah, why encode the file type in the name, a universal field which
actually has a ghost of a chance of surviving transfer from one
operating system to another?
Such an unimportant, trifling property clearly belongs in a dedicated
field that is unique to some proprietary filesystem.
> about resource forks. So when a Mac user gave a file to a Windows
> user, the Windows could not easily open it without the expected file
> extension.
That's because he /couldn't/ actually give that file to the Windows
user. He could only give the file, minus any Mac-specific bits that
don't transfer to another operating system.
By adding that file name suffix, you recreate a portable version of
what was lost in the transfer.
> By making the Mac more like Windows, Apple made the choice
> of buying a Mac easier.
>
> Now, I'm not saying Lisp should become more like other languages just
> to fit in.
This is a problem for people whose fortune is somehow vested in the
widespread acceptance of Lisp. No such thing is true of Lisp
programmers.
As a Lisp programmer, I don't care whether Lisp has low popularity.
In fact, it's not uncommon for software houses to find some advantage
in developing entirely proprietary languages and using them in their
products.
This stands in stark contrast to how we actually expect to make money
in the business: selling many copies of the same thing to a user base,
hoping to get that user base to even standardize on our thing and not
someone else's.
So analogies between how end-users select software, and how
programmers select languages and other tools, are inherently flawed.
On Jul 9, 10:41 am, Kaz Kylheku <········@gmail.com> wrote:
> On Jul 3, 9:10 am, ········@gmail.com wrote:
>
> > In Mac OS X, Apple decided to favor file extensions over the meta data
> > in the resource fork for associating files with applications.
>
> Strictly speaking, in Unix we have suffixes, not extensions.
>
> Many
>
> > long time supporters of the Mac were upset at Apple for deliberately
> > choosing the technically inferior solution.
>
> Yeah, why encode the file type in the name, a universal field which
> actually has a ghost of a chance of surviving transfer from one
> operating system to another?
>
> Such an unimportant, trifling property clearly belongs in a dedicated
> field that is unique to some proprietary filesystem.
>
> > about resource forks. So when a Mac user gave a file to a Windows
> > user, the Windows could not easily open it without the expected file
> > extension.
>
> That's because he /couldn't/ actually give that file to the Windows
> user. He could only give the file, minus any Mac-specific bits that
> don't transfer to another operating system.
>
> By adding that file name suffix, you recreate a portable version of
> what was lost in the transfer.
>
> > By making the Mac more like Windows, Apple made the choice
> > of buying a Mac easier.
>
> > Now, I'm not saying Lisp should become more like other languages just
> > to fit in.
>
> This is a problem for people whose fortune is somehow vested in the
> widespread acceptance of Lisp. No such thing is true of Lisp
> programmers.
>
> As a Lisp programmer, I don't care whether Lisp has low popularity.
But It doesn't hurt being popular , lisp being in top 10 would be
great for me . More users, more libraries, more war stories, more
shops using it for something else than research and earning money with
lisp. One man is an island.
>
> In fact, it's not uncommon for software houses to find some advantage
> in developing entirely proprietary languages and using them in their
> products.
C/AL for Microsoft Navision comes to mind.
>
> This stands in stark contrast to how we actually expect to make money
> in the business: selling many copies of the same thing to a user base,
> hoping to get that user base to even standardize on our thing and not
> someone else's.
>
> So analogies between how end-users select software,
> and how programmers select languages and other tools, are inherently flawed.
Agreed
On Jul 9, 4:41 am, Kaz Kylheku <········@gmail.com> wrote:
> This is a problem for people whose fortune is somehow vested in the
> widespread acceptance of Lisp. No such thing is true of Lisp
> programmers.
It's probably more true than you think. Now, if you are already
retired and living off the proceeds of an earlier fortune you made one
way or another, sure.
But if you make money to feed yourself and maybe a family by writing
code, the popularity of the language(s) you know can be very important
indeed.
>
> As a Lisp programmer, I don't care whether Lisp has low popularity.
>
> In fact, it's not uncommon for software houses to find some advantage
> in developing entirely proprietary languages and using them in their
> products.
You need to weigh this against all the advantages of using a popular
language. If two languages are equally good on technical merits, are
there any actual advantages to picking the one that is less popular?
Sure, there are advantages to using the most powerful (in the Paul
Graham sense) language available even if it is not very popular, but
does becoming more popular really make the language worse?
> This stands in stark contrast to how we actually expect to make money
> in the business: selling many copies of the same thing to a user base,
> hoping to get that user base to even standardize on our thing and not
> someone else's.
>
> So analogies between how end-users select software, and how
> programmers select languages and other tools, are inherently flawed.
*shrug* Just a metaphor, no not exactly the same thing. You should
probably think a little more about whether Lisp sometimes is different
but not really significantly better than other languages, and could
benefit by being more like other languages. What about Lisp
pathnames? Is there really a benefit there now that every file system
in the world is Unix or Windows, and they're really not that different
from an API perspective?
If you don't like that example, I'm sure you can come up with a better
one.
-jimbo
On Jul 9, 1:38 pm, ········@gmail.com wrote:
> But if you make money to feed yourself and maybe a family by writing
> code, the popularity of the language(s) you know can be very important
> indeed.
If your only value proposition as a potential employee is the
programming language(s) you know, you're in trouble already. Any idiot
can know Java, or Python, or Ruby, or, for that matter, Lisp. Idiots
have trouble solving real problems, however. And, for problems that
idiots can solve, you are in competition with a whole world absolutely
brimming with idiots. Good luck.
On Jul 9, 2:09 pm, ···············@hotmail.com"
<············@gmail.com> wrote:
> If your only value proposition as a potential employee is the
> programming language(s) you know, you're in trouble already. Any idiot
> can know Java, or Python, or Ruby, or, for that matter, Lisp. Idiots
> have trouble solving real problems, however. And, for problems that
> idiots can solve, you are in competition with a whole world absolutely
> brimming with idiots. Good luck.
If you think that the popularity of a language has no correlation with
the ability to use that language to solve real problems, I don't know
what to tell you.
More, better debugged libraries and frameworks, larger developer pool,
better odds of finding someone who has found your particular problem
and maybe contributed a fix for it, more tools, etc.
-jimbo
On Jul 9, 3:25 pm, ········@gmail.com wrote:
> On Jul 9, 2:09 pm, ···············@hotmail.com"
>
> <············@gmail.com> wrote:
> > If your only value proposition as a potential employee is the
> > programming language(s) you know, you're in trouble already. Any idiot
> > can know Java, or Python, or Ruby, or, for that matter, Lisp. Idiots
> > have trouble solving real problems, however. And, for problems that
> > idiots can solve, you are in competition with a whole world absolutely
> > brimming with idiots. Good luck.
>
> If you think that the popularity of a language has no correlation with
> the ability to use that language to solve real problems, I don't know
> what to tell you.
At one time or another, Cobol and Visual Basic have both been much,
much more popular than Lisp. They were designed so that "anyone" could
write contemporary business applications. Their popularity certainly
doesn't seem to correlate with being able to solve what I would call
real problems.
> More, better debugged libraries and frameworks, larger developer pool,
> better odds of finding someone who has found your particular problem
> and maybe contributed a fix for it, more tools, etc.
I.e., better odds that someone is working on exactly the same thing
that you are, meaning lots of competition for people to do your task,
and lots of replacements for you because all you are doing is using
the most common tool to do the most common task.
The secret to success is to know stuff that *few* people know. That
has very little to do with programming languages.
On Jul 9, 4:52 pm, ···············@hotmail.com"
<············@gmail.com> wrote:
> At one time or another, Cobol and Visual Basic have both been much,
> much more popular than Lisp. They were designed so that "anyone" could
> write contemporary business applications. Their popularity certainly
> doesn't seem to correlate with being able to solve what I would call
> real problems.
Cobol and Visual Basic have definitely been used to solve a lot of
problems. Whether they were "real" problems is a question of
judgement, I guess.
I do not like Cobol or Visual Basic (well, I don't actually know
Cobol). But did becoming popular make them WORSE languages than they
already were?
(ps Dan Barlow has an interesting point about signal to noise ratio I
found interesting, but I'm wondering if you have anything more than
that.)
> I.e., better odds that someone is working on exactly the same thing
> that you are, meaning lots of competition for people to do your task,
> and lots of replacements for you because all you are doing is using
> the most common tool to do the most common task.
What if you are using a common tool to do an uncommon task?
> The secret to success is to know stuff that *few* people know. That
> has very little to do with programming languages.
If success has very little to do with programming languages, why
bother with Lisp instead of Java or C# or VB or something else?
-jimbo
On Mon, 09 Jul 2007 16:59:17 -0700, ········@gmail.com wrote:
>I do not like Cobol or Visual Basic (well, I don't actually know
>Cobol). But did becoming popular make them WORSE languages than they
>already were?
Actually, yes. Popularity encourages people who have no business
writing software of any kind to try their hand at it. Cobol proved to
be too complex for script kiddies, but VB was simple enough that
almost anyone could write something and could usually get it to work
despite themselves.
The quick "success" of most people who tried VB started to convince
managers that anyone could be a programmer and there was no need to
hire professional developers. Of course the "applications" (scripts
mainly) were mostly poorly designed, slow and extremely fragile ...
but that didn't matter because business critical apps could be
developed by the assistant sales manager during her lunch hour - much
cheaper and more efficient than hiring out professional development or
maintaining an in-house IT department.
It took (comparitively) a long time for VB's star to fade because of
the way business embraced it.
George
--
for email reply remove "/" from address
On Jul 9, 9:22 pm, George Neuner <·········@comcast.net> wrote:
> It took (comparitively) a long time for VB's star to fade because of
> the way business embraced it.
So if Lisp were to become more popular, would it make the average
program and the average programmer better or worse? I don't think
so. I think Lisp becoming more popular would raise the status quo for
everyone.
Now, if Lisp compromised what makes Lisp special there wouldn't be any
point. But if Lisp became more popular just by lowering some of the
barriers to entry and making more programmers and managers and
entrepeneurs aware of what it can do, that would be good for everyone.
I wouldn't go too far in saying that VB made things worse for
everyone, though. It probably enabled a lot of productivity by
allowing more people to write "programs" to do things they needed to
do.
I don't think there's any reason Lisp couldn't have played that role
if history had played out differently. People new to programming
could probably care less whether it's (draw shape) or shape.draw().
They're both just as arbitrary. But the VB form builder was there in
the right place at the right time at the right place with the right
marketing and so it won. Hypercard could have easily played that role,
too, but that takes me too far off topic.
-jimbo
On Mon, 09 Jul 2007 21:49:22 -0700, ········@gmail.com wrote:
>On Jul 9, 9:22 pm, George Neuner <·········@comcast.net> wrote:
>> It took (comparitively) a long time for VB's star to fade because of
>> the way business embraced it.
>
>So if Lisp were to become more popular, would it make the average
>program and the average programmer better or worse? I don't think
>so. I think Lisp becoming more popular would raise the status quo for
>everyone.
The "average" programmer would be no better. Advanced tools don't
make mediocre programmers better - just more dangerous.
Just so you know where I'm coming from: I've been programming for 25
years, nearly 15 of which have been spent writing high performance,
high availability software. I'm very keen on reliability ... many
systems I've worked on had to run continuously for weeks or months
without a restart and some of the companies using them stood to lose
thousands of dollars per minute if something malfunctioned. I have
CS-EE bachelor and CS master degrees with course work (but not
dissertation) for a second CS master on a different track [I was to
graduate during a recession when job prospects were poor so I stayed
another year. I chose to work rather than get a PhD].
My opinion may be extreme, but I believe that the majority of
"professional" software developers working today should do the world a
favor and find other employment. And I also believe that 95% of the
population should not be given the opportunity to write software. It
scares me to think that contestants on "Battle of the Jaywalk
All-Stars" could be hacking business programs on their lunch hour ...
I might have stock in the company they work for (if they're on
"Jaywalk" it scares me to think that they work anywhere).
I get concerned when amateurs use something like VB (which was more
powerful than people gave it credit for) to e.g., automate an
important business process. I get doubly concerned when they get
credit for doing so and start to think of themselves as "programmers"
instead of whatever their actual job title is. Most amateur software
(in whatever form or language) is fragile and environment sensitive,
meaning it doesn't work when their friends or co-workers try to use
it. After a few rounds of debugging and tweaking and a few other
inspired people have hacked it to work in their own environments, the
original author can't even understand it.
>Now, if Lisp compromised what makes Lisp special there wouldn't be any
>point. But if Lisp became more popular just by lowering some of the
>barriers to entry and making more programmers and managers and
>entrepeneurs aware of what it can do, that would be good for everyone.
Lot's of people say this but I don't get it ... Lisp is as easy to
learn as BASIC, newbies can be writing simple programs in 30 minutes.
More advanced features (some of which _are_ hard) can be learned
incrementally as needed - the same way all languages are learned.
The only thing most Lisps lack is a user friendly GUI. However, _any_
Lisp will do for a newbie and both LW and ACL have nice GUIs and come
in free versions for learning. Both are mentioned in the FAQ and both
are routinely recommended in this forum.
Would it help if someone made available a slick freeware GUI and
graphical debugger for SBCL or CMUCL? Sure. Why don't you go work on
that.
>I wouldn't go too far in saying that VB made things worse for
>everyone, though. It probably enabled a lot of productivity by
>allowing more people to write "programs" to do things they needed to
>do.
I have no doubt that some productivity gains were realized. That is
why business took an interest in VB in the first place.
Some of the automation tools have become quite sophisticated - the
problem now lies with the quality of the software being automated.
Many programs which work fine at the console are much less reliable
under automation - even benign automation like mouse and keystroke
delivery. The most common problem is the program puts some message on
the console and freezes until it is dismissed. But no one is there to
read it because the program has been automated - it could be running
invisibly on a hidden console so even someone using the computer at
the time wouldn't know what happened. Programs deliberately designed
for automation fair somewhat better, but many I have seen come with
warnings not to run them hidden or on unattended servers - just in
case. What is the point of automating something if I still have to be
present to watch it execute?
>I don't think there's any reason Lisp couldn't have played that role
>if history had played out differently. People new to programming
>could probably care less whether it's (draw shape) or shape.draw().
>They're both just as arbitrary. But the VB form builder was there in
>the right place at the right time at the right place with the right
>marketing and so it won. Hypercard could have easily played that role,
>too, but that takes me too far off topic.
>
> -jimbo
George
--
for email reply remove "/" from address
On Jul 11, 10:48 am, George Neuner <·········@comcast.net> wrote:
> On Mon, 09 Jul 2007 21:49:22 -0700, ········@gmail.com wrote:
> >On Jul 9, 9:22 pm, George Neuner <·········@comcast.net> wrote:
> >> It took (comparitively) a long time for VB's star to fade because of
> >> the way business embraced it.
>
> >So if Lisp were to become more popular, would it make the average
> >program and the average programmer better or worse? I don't think
> >so. I think Lisp becoming more popular would raise the status quo for
> >everyone.
>
> The "average" programmer would be no better. Advanced tools don't
> make mediocre programmers better - just more dangerous.
Tend to disagree from a certain point of view, using right tool makes
you create a better product even if your skills are the same. Who
would win a race between me and Shumacher if I'm driving a Bugatti
Veyron and he's sticked with a Fiat Punto? And don't forgeth the
Prechelt / Gatt study: development time for lisp ( 2 - 8.5 hours ) c/c+
+ ( 3 - 25 ) & java (4 - 63) coming with master : sucker discrepancy
of 4.25 : 1 for lisp, 8.33 : 1 for c/c++ and staggering 15.75 : 1
for java.
>
> Just so you know where I'm coming from: I've been programming for 25
> years, nearly 15 of which have been spent writing high performance,
> high availability software. I'm very keen on reliability ... many
> systems I've worked on had to run continuously for weeks or months
> without a restart and some of the companies using them stood to lose
> thousands of dollars per minute if something malfunctioned. I have
> CS-EE bachelor and CS master degrees with course work (but not
> dissertation) for a second CS master on a different track [I was to
> graduate during a recession when job prospects were poor so I stayed
> another year. I chose to work rather than get a PhD].
>
> My opinion may be extreme, but I believe that the majority of
> "professional" software developers working today should do the world a
> favor and find other employment. And I also believe that 95% of the
> population should not be given the opportunity to write software. It
> scares me to think that contestants on "Battle of the Jaywalk
> All-Stars" could be hacking business programs on their lunch hour ...
> I might have stock in the company they work for (if they're on
> "Jaywalk" it scares me to think that they work anywhere).
>
> I get concerned when amateurs use something like VB (which was more
> powerful than people gave it credit for) to e.g., automate an
> important business process. I get doubly concerned when they get
> credit for doing so and start to think of themselves as "programmers"
> instead of whatever their actual job title is. Most amateur software
> (in whatever form or language) is fragile and environment sensitive,
> meaning it doesn't work when their friends or co-workers try to use
> it. After a few rounds of debugging and tweaking and a few other
> inspired people have hacked it to work in their own environments, the
> original author can't even understand it.
The sad point is that a lot of (business) software is just plain
simple, like put those sheet over there and don't forgeth to make it
export to excel. Oh of course they use Windows so why should we make
it portable Linux & FreeBSD are only for servers and mac is for
artists and teachers. So nothing to use thinking just copy paste from
your previous code, write some glue code and think some way to compile
it. I've seen a lot of companies after spending fortunes for SAP &
navision still calculating salaries with Excel. Humans habits are just
fricking hard to change.
>
> >Now, if Lisp compromised what makes Lisp special there wouldn't be any
> >point. But if Lisp became more popular just by lowering some of the
> >barriers to entry and making more programmers and managers and
> >entrepeneurs aware of what it can do, that would be good for everyone.
>
> Lot's of people say this but I don't get it ... Lisp is as easy to
> learn as BASIC, newbies can be writing simple programs in 30 minutes.
> More advanced features (some of which _are_ hard) can be learned
> incrementally as needed - the same way all languages are learned.
>
> The only thing most Lisps lack is a user friendly GUI. However, _any_
> Lisp will do for a newbie and both LW and ACL have nice GUIs and come
> in free versions for learning. Both are mentioned in the FAQ and both
> are routinely recommended in this forum.
>
When you make your own projects you could use ,usually what to
implement it with but what if you work for a company that alerady has
a 500,000 lines of VB,Delphi rewriting is out of question . Now there
is a simigliar trend in writing some software for a fee, I've stumbled
to a customer that want their app to be visual that's why I must
write it with Visual Basic because that's the right thing as his
cousin the hacker (that's anybody who knows to use something beside
Office , like mirc) told him so. But those are easy to deal with right
the code in lisp they will never know it. The problems comes with
agencies who makes a specs, I get one with php4 only that will run on
both apache & IIS. Lisp was just out of question because the spec
agency didn't even know what the hell that is.That is why I'm saying
even a bad publicity is something.
> Would it help if someone made available a slick freeware GUI and
> graphical debugger for SBCL or CMUCL? Sure. Why don't you go work on
> that.
>
> >I wouldn't go too far in saying that VB made things worse for
> >everyone, though. It probably enabled a lot of productivity by
> >allowing more people to write "programs" to do things they needed to
> >do.
>
> I have no doubt that some productivity gains were realized. That is
> why business took an interest in VB in the first place.
>
> Some of the automation tools have become quite sophisticated - the
> problem now lies with the quality of the software being automated.
> Many programs which work fine at the console are much less reliable
> under automation - even benign automation like mouse and keystroke
> delivery. The most common problem is the program puts some message on
> the console and freezes until it is dismissed. But no one is there to
> read it because the program has been automated - it could be running
> invisibly on a hidden console so even someone using the computer at
> the time wouldn't know what happened. Programs deliberately designed
> for automation fair somewhat better, but many I have seen come with
> warnings not to run them hidden or on unattended servers - just in
> case. What is the point of automating something if I still have to be
> present to watch it execute?
>
> >I don't think there's any reason Lisp couldn't have played that role
> >if history had played out differently. People new to programming
> >could probably care less whether it's (draw shape) or shape.draw().
> >They're both just as arbitrary. But the VB form builder was there in
> >the right place at the right time at the right place with the right
> >marketing and so it won. Hypercard could have easily played that role,
> >too, but that takes me too far off topic.
>
> > -jimbo
>
> George
> --
> for email reply remove "/" from address
On Wed, 11 Jul 2007 04:41:04 -0700, Slobodan Blazeski
<·················@gmail.com> wrote:
>who would win a race between me and Shumacher if I'm driving a Bugatti
>Veyron and he's sticked with a Fiat Punto?
Depends on whether you can drive ;) I just read an article about how
often people are wrecking their fast cars.
http://finance.yahoo.com/insurance/article/103123/Honey-I-Wrecked-the-Porsche
>what if you work for a company that alerady has
>a 500,000 lines of VB,Delphi rewriting is out of question .
I'm not a language snob (much) and I have nothing against VB or Delphi
or any other language per se - what I am against is amateur programs
being used professionally. A half million line program is _not_ a
typical amateur program.
>Now there
>is a simigliar trend in writing some software for a fee, I've stumbled
>to a customer that want their app to be visual that's why I must
>write it with Visual Basic because that's the right thing as his
>cousin the hacker (that's anybody who knows to use something beside
>Office , like mirc) told him so. But those are easy to deal with right
>the code in lisp they will never know it. The problems comes with
>agencies who makes a specs, I get one with php4 only that will run on
>both apache & IIS. Lisp was just out of question because the spec
>agency didn't even know what the hell that is.That is why I'm saying
>even a bad publicity is something.
A consultant going in often finds weird constraints based on the
equipment and software the business already uses. Again, I have no
problem with that. If someone pays me enough, I'll happily write them
whatever they want in whatever language they specify (many years ago I
was paid to write a database translation filter in MUMPS and a free
form text page editor in GWBASIC).
George
--
for email reply remove "/" from address
On Jul 12, 3:54 am, George Neuner <·········@comcast.net> wrote:
> On Wed, 11 Jul 2007 04:41:04 -0700, Slobodan Blazeski
>
> <·················@gmail.com> wrote:
> >who would win a race between me and Shumacher if I'm driving a Bugatti
> >Veyron and he's sticked with a Fiat Punto?
>
> Depends on whether you can drive ;)
Of course I can drive I finished nfs carbon, most wanted, underground
1&2 , and hot pursuit. Seriously I have a license for driving a truck,
I love trucks especially US ones like http://www.kenworth.com/1000_hom.asp
or http://www.freightliner.com/, but I'm far far away from a racer.
I just read an article about how
> often people are wrecking their fast cars.
>
> http://finance.yahoo.com/insurance/article/103123/Honey-I-Wrecked-the...
Rich bustards.
>
> >what if you work for a company that alerady has
> >a 500,000 lines of VB,Delphi rewriting is out of question .
>
> I'm not a language snob (much) and I have nothing against VB or Delphi
> or any other language per se - what I am against is amateur programs
> being used professionally. A half million line program is _not_ a
> typical amateur program.
I prefer to choose my own language and avoid stupid constraints
especially when they have no logic behind them. If the money is really
good I could make an exception.
>
> >Now there
> >is a simigliar trend in writing some software for a fee, I've stumbled
> >to a customer that want their app to be visual that's why I must
> >write it with Visual Basic because that's the right thing as his
> >cousin the hacker (that's anybody who knows to use something beside
> >Office , like mirc) told him so. But those are easy to deal with right
> >the code in lisp they will never know it. The problems comes with
> >agencies who makes a specs, I get one with php4 only that will run on
> >both apache & IIS. Lisp was just out of question because the spec
> >agency didn't even know what the hell that is.That is why I'm saying
> >even a bad publicity is something.
>
> A consultant going in often finds weird constraints based on the
> equipment and software the business already uses. Again, I have no
> problem with that. If someone pays me enough, I'll happily write them
> whatever they want in whatever language they specify (many years ago I
> was paid to write a database translation filter in MUMPS and a free
> form text page editor in GWBASIC).
This was a completely new app and the idiots got what they asked
for.They gave the job to the lowest bidder and three months after the
original deadline they still don't have a working system. I don't
know who to blame php or idiots that promised to implement it in php,
and they were C# shop nobody never worked with linux before. So first
choose who can do what you want than speak about prices.
>
> George
> --
> for email reply remove "/" from address
On Thu, 12 Jul 2007 01:29:28 -0700, Slobodan Blazeski
<·················@gmail.com> wrote:
>On Jul 12, 3:54 am, George Neuner <·········@comcast.net> wrote:
>> On Wed, 11 Jul 2007 04:41:04 -0700, Slobodan Blazeski
>>
>> <·················@gmail.com> wrote:
>> >who would win a race between me and Shumacher if I'm driving a Bugatti
>> >Veyron and he's sticked with a Fiat Punto?
>>
>> Depends on whether you can drive ;)
>
>Of course I can drive I finished nfs carbon, most wanted, underground
>1&2 , and hot pursuit. Seriously I have a license for driving a truck,
>I love trucks especially US ones like http://www.kenworth.com/1000_hom.asp
>or http://www.freightliner.com/, but I'm far far away from a racer.
>
>>I just read an article about how often people are wrecking their fast cars.
>>
>> http://finance.yahoo.com/insurance/article/103123/Honey-I-Wrecked-the...
>
>Rich bustards.
ROFL - "Bustards" ... as in "busted the car".
When I was younger I used to street race with a Mazda and after
becoming, (cough) respectable, I still had occasion to pin the speedo
on my Bimmer. Double the double nickel (110 mph) makes for a nice
cruise on a sunny afternoon.
BUt I don't open up any more - my reflexes are slowing and its gotten
too risky with traffic and police - ok, mostly traffic. Plus 'X'
tires (~170mph) are just too expensive - if you can even find them,
most places only sell 'Z' (200+) now - which is even more expensive.
I still spring for 'V' (~140mph) to get decent performance handling
but in hot weather they would rapidly delaminate at full speed.
Take care,
George
--
for email reply remove "/" from address
On Jul 17, 6:30 pm, George Neuner <·········@comcast.net> wrote:
> On Thu, 12 Jul 2007 01:29:28 -0700, Slobodan Blazeski
>
>
>
> <·················@gmail.com> wrote:
> >On Jul 12, 3:54 am, George Neuner <·········@comcast.net> wrote:
> >> On Wed, 11 Jul 2007 04:41:04 -0700, Slobodan Blazeski
>
> >> <·················@gmail.com> wrote:
> >> >who would win a race between me and Shumacher if I'm driving a Bugatti
> >> >Veyron and he's sticked with a Fiat Punto?
>
> >> Depends on whether you can drive ;)
>
> >Of course I can drive I finished nfs carbon, most wanted, underground
> >1&2 , and hot pursuit. Seriously I have a license for driving a truck,
> >I love trucks especially US ones likehttp://www.kenworth.com/1000_hom.asp
> >orhttp://www.freightliner.com/, but I'm far far away from a racer.
>
> >>I just read an article about how often people are wrecking their fast cars.
>
> >>http://finance.yahoo.com/insurance/article/103123/Honey-I-Wrecked-the...
>
> >Rich bustards.
>
> ROFL - "Bustards" ... as in "busted the car".
I get it
Bastard may refer to:
Illegitimacy, the circumstance of being born of parents who are not
married to one another. It is also used as a curse word for males to
mirror the curse word bitch, which is used for females.
Bustards are large terrestrial birds mainly associated with dry open
country and steppes in the Old World. They make up the family Otididae
(formerly known as Otidae).
I know, I know I should use spell checker but there's no fun in using
spell checkers as they only make your posts easier to read and save
you from looking stupid.
'( I like to con people. And I like to insult people. If you combine
con & insult, you get consult! )
Dogbert
>
> When I was younger I used to street race with a Mazda and after
> becoming, (cough) respectable, I still had occasion to pin the speedo
> on my Bimmer. Double the double nickel (110 mph) makes for a nice
> cruise on a sunny afternoon.
>
> BUt I don't open up any more - my reflexes are slowing and its gotten
> too risky with traffic and police - ok, mostly traffic. Plus 'X'
> tires (~170mph) are just too expensive - if you can even find them,
> most places only sell 'Z' (200+) now - which is even more expensive.
> I still spring for 'V' (~140mph) to get decent performance handling
> but in hot weather they would rapidly delaminate at full speed.
>
> Take care,
> George
> --
> for email reply remove "/" from address
On Fri, 20 Jul 2007 13:39:21 -0700, Slobodan Blazeski
<·················@gmail.com> wrote:
>Bustards are large terrestrial birds mainly associated with dry open
>country and steppes in the Old World. They make up the family Otididae
>(formerly known as Otidae).
Interesting ... I had never heard of them before.
George
--
for email reply remove "/" from address
On Jul 23, 7:53 pm, George Neuner <·········@comcast.net> wrote:
> On Fri, 20 Jul 2007 13:39:21 -0700, Slobodan Blazeski
>
> <·················@gmail.com> wrote:
> >Bustards are large terrestrial birds mainly associated with dry open
> >country and steppes in the Old World. They make up the family Otididae
> >(formerly known as Otidae).
>
> Interesting ... I had never heard of them before.
>
Neither do I but wikipedia knows about them. http://en.wikipedia.org/wiki/Bustard
When someone loughs at my post I first check my spelling before
starting a flame war :)
(quote "Lately the only thing keeping me from being a serial killer is
my distaste for manual labour." - Dilbert)
Slobodan Blazeski <·················@gmail.com> writes:
> On Jul 23, 7:53 pm, George Neuner <·········@comcast.net> wrote:
>> On Fri, 20 Jul 2007 13:39:21 -0700, Slobodan Blazeski
>>
>> <·················@gmail.com> wrote:
>> >Bustards are large terrestrial birds mainly associated with dry open
>> >country and steppes in the Old World. They make up the family Otididae
>> >(formerly known as Otidae).
>>
>> Interesting ... I had never heard of them before.
>>
>
> Neither do I but wikipedia knows about them. http://en.wikipedia.org/wiki/Bustard
> When someone loughs at my post I first check my spelling before
^^^^^^
From WordNet (r) 2.1 (2005) [wn]:
lough
n 1: a long narrow (nearly landlocked) cove in Ireland
2: Irish word for a lake
You keep expanding my vocabulary ;-)
> starting a flame war :)
>
> (quote "Lately the only thing keeping me from being a serial killer is
> my distaste for manual labour." - Dilbert)
On Jul 24, 11:28 am, Tamas Papp <······@gmail.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > On Jul 23, 7:53 pm, George Neuner <·········@comcast.net> wrote:
> >> On Fri, 20 Jul 2007 13:39:21 -0700, Slobodan Blazeski
>
> >> <·················@gmail.com> wrote:
> >> >Bustards are large terrestrial birds mainly associated with dry open
> >> >country and steppes in the Old World. They make up the family Otididae
> >> >(formerly known as Otidae).
>
> >> Interesting ... I had never heard of them before.
>
> > Neither do I but wikipedia knows about them.http://en.wikipedia.org/wiki/Bustard
> > When someone loughs at my post I first check my spelling before
>
> ^^^^^^
>
> From WordNet (r) 2.1 (2005) [wn]:
>
> lough
> n 1: a long narrow (nearly landlocked) cove in Ireland
> 2: Irish word for a lake
>
> You keep expanding my vocabulary ;-)
I didn't know that I know those words :) . Anyway as I said there's
no fun in using spell checkers as they only make your posts easier to
read and save you from looking stupid.
(Quote
"My invention can detect human stupidity. It has a very simple
interface. All I do is point it at people."
"Then what does it do?"
"Why would it need to do anything else?"
- Dogbert )
On Jul 12, 9:20 am, Paul Foley <····@below.invalid> (http://
public.xdi.org/=pf) wrote:
> On Wed, 11 Jul 2007 04:41:04 -0700, Slobodan Blazeski wrote:
> > you create a better product even if your skills are the same. Who
> > would win a race between me and Shumacher if I'm driving a Bugatti
> > Veyron and he's sticked with a Fiat Punto? And don't forgeth the
>
> In a straight line and with enough distance, you'd even win against
> him driving an F1 car. But let him pick the track and I'm sure he'd
> have no problem beating you in the Punto :-)
That would have to be some very demanding & higly technical course,
were the skill matters more than a car. But there are tracks where is
just the opposite, where you can't win if your car sucks even if
you're betetr driver than the opponent, I won't speculate on
percentage. Just like in software.
>
> --
> If x is the degree of population of the United States and y is the degree
> of imbecility of the average American, then democracy is the theory that
> x times y is less than y.
> -- H. L. Mencken
> (setq reply-to
> (concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
George Neuner <·········@comcast.net> wrote:
+---------------
| The only thing most Lisps lack is a user friendly GUI. However, _any_
| Lisp will do for a newbie and both LW and ACL have nice GUIs and come
| in free versions for learning. Both are mentioned in the FAQ and both
| are routinely recommended in this forum.
|
| Would it help if someone made available a slick freeware GUI and
| graphical debugger for SBCL or CMUCL? Sure. Why don't you go work
| on that.
+---------------
CMUCL (almost) already has one. It comes with a graphical interface
to the debugger, as well as a native Emacs-like editor, "Hemlock".
Apparently few people use either these days, probably because both
the debugger & Hemlock GUIs are rather clunky & old-fashioned looking,
but they could no doubt be spruced up if someone were willing to put
a little work into it.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jul 11, 4:48 am, George Neuner <·········@comcast.net> wrote:
> >Now, if Lisp compromised what makes Lisp special there wouldn't be any
> >point. But if Lisp became more popular just by lowering some of the
> >barriers to entry and making more programmers and managers and
> >entrepeneurs aware of what it can do, that would be good for everyone.
>
> Lot's of people say this but I don't get it ... Lisp is as easy to
> learn as BASIC, newbies can be writing simple programs in 30 minutes.
> More advanced features (some of which _are_ hard) can be learned
> incrementally as needed - the same way all languages are learned.
I agree with all of this.
I think where Common Lisp faces barriers to entry are things like:
Picking a distribution to start with when you don't know the
language. Not knowing emacs. Not knowing which libraries are good.
Not knowing which libraries work with the distribution you picked.
Finding out that there is no equivalent of a library available in
another language that would be useful for you. If you didn't pick Lisp-
in-a-Box, then getting emacs and SLIME hooked up to your Lisp.
Figuring out how to work ASDF/ASDF-Install to get libraries
installed. Figuring out that some of the documentation for the APIs
you want to use is in the Hyperspec, some is in the documentation for
the distribution you picked, and some is in a 3rd party library you
need.
Many of these go away with a commercial Lisp, but then you have the
problem of either paying a few thousand dollars or figuring out you
need to start over and face all of the above problems anyway when you
reach the limitations of the free commercial versions.
> The only thing most Lisps lack is a user friendly GUI. However, _any_
> Lisp will do for a newbie and both LW and ACL have nice GUIs and come
> in free versions for learning. Both are mentioned in the FAQ and both
> are routinely recommended in this forum.
>
> Would it help if someone made available a slick freeware GUI and
> graphical debugger for SBCL or CMUCL? Sure. Why don't you go work on
> that.
I think this is rather low on the barriers to entry list.
I snipped your comments about why Lisp being more popular might not
improve the average program or average programmer, but found what you
say interesting and something to think about it.
Is there a way to make Lisp more popular with the "good" programmers?
Or are all of them already happily hacking Lisp?
I would say, though, that even if Lisp doesn't make the bad
programmers any better, Lisp being popular could improve things for
the good programmers who could then get paid to write Lisp on more
projects.
-jimbo
········@gmail.com writes:
> On Jul 11, 4:48 am, George Neuner <·········@comcast.net> wrote:
>> >Now, if Lisp compromised what makes Lisp special there wouldn't be any
>> >point. But if Lisp became more popular just by lowering some of the
>> >barriers to entry and making more programmers and managers and
>> >entrepeneurs aware of what it can do, that would be good for everyone.
>>
>> Lot's of people say this but I don't get it ... Lisp is as easy to
>> learn as BASIC, newbies can be writing simple programs in 30 minutes.
>> More advanced features (some of which _are_ hard) can be learned
>> incrementally as needed - the same way all languages are learned.
>
> I agree with all of this.
>
> I think where Common Lisp faces barriers to entry are things like:
> Picking a distribution to start with when you don't know the
> language. Not knowing emacs. Not knowing which libraries are good.
> Not knowing which libraries work with the distribution you picked.
> Finding out that there is no equivalent of a library available in
> another language that would be useful for you. If you didn't pick Lisp-
> in-a-Box, then getting emacs and SLIME hooked up to your Lisp.
> Figuring out how to work ASDF/ASDF-Install to get libraries
> installed. Figuring out that some of the documentation for the APIs
> you want to use is in the Hyperspec, some is in the documentation for
> the distribution you picked, and some is in a 3rd party library you
> need.
>
> Many of these go away with a commercial Lisp, but then you have the
> problem of either paying a few thousand dollars or figuring out you
> need to start over and face all of the above problems anyway when you
> reach the limitations of the free commercial versions.
Sounds like the problem I had when I discovered the first time I
needed to link-edit my program.
Isn't that something that should be solved early, in school?
Perhaps even not in university where you learn computer stuff, but in
school where you should learn how to use references like
dictionnaries, encyclopedies and google?
Perhaps I'm just saying that lisp is not popular because the general
population is too dumb... (or at the very least, very ill educated).
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jul 11, 7:20 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Perhaps I'm just saying that lisp is not popular because the general
> population is too dumb... (or at the very least, very ill educated).
I like my Mac.
Now, please bear with my non-sequitir for a moment.
Why are Apple products so popular with their users? Because they save
you a little bit of time in countless places with attention to
detail. They eliminate little extra steps here and there throughout
the interface, which adds up to noticeable productivity gains in
total.
What's the analogy with Common Lisp? If you start using Java or
Python, there's a good chance there's a library to do that common task
you have in mind already included. If you have Perl there's a good
chance that library is in CPAN and easy to get into your system.
These are small productivity gains compared to Common Lisp, perhaps,
but they add up. They especially add up for the new Common Lisp
programmer, who maybe had an easier time getting started in the last
language he learned.
In my opinion, Common Lisp is not very far from having the
accessibility of these other languages. Lisp-in-a-Box and Starter
Pack address a lot of them. The pieces just need to be put together
and polished to work a little more smoothly.
Isn't the whole point of using a better programming to increase
productivity? Why not do the few remaining little things that close
the gap where other languages have a productivity edge over Lisp?
-jimbo
········@gmail.com writes:
> On Jul 11, 7:20 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>> Perhaps I'm just saying that lisp is not popular because the general
>> population is too dumb... (or at the very least, very ill educated).
>
> I like my Mac.
I like all of my Macs.
> Now, please bear with my non-sequitir for a moment.
No problem; it's a perfect analogy.
> Why are Apple products so popular with their users?
Here you've changed the rules. Saying "Lisp is (not) popular" is a
far cry from saying "Apple is (not) popular with their users". Let's
put aside the ipods, etc., for now and just deal with the Macs - it is
true that Macs are extremely popular with their users; we tend to love
them, even though they are not perfect. However, what is the current
percentage of market share that Mac has in the PC world? A percent or
two? That certainly isn't popular. And with a product as useful as
the Mac, why shouldn't it be popular? Do you think it's on the cusp
of popularity, and if so, why? What should Apple do to fix their
problem? What tweak can they make to the Mac to put it over the edge
so that it competes with the obviously vastly superior Windows
machines? (I shouldn't even need the smiley here ...)
Well, let's move to Lisp - Lisp is certainly popular with its users.
Just like Macs. And Lisp has a very small share of the language
market. Do you think Lisp should follow in the Mac's footsteps?
--
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
On 2007-07-12, Duane Rettig <·····@franz.com> wrote:
> ········@gmail.com writes:
>> On Jul 11, 7:20 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>>> Perhaps I'm just saying that lisp is not popular because the
>>> general population is too dumb... (or at the very least, very ill
>>> educated).
>>
>> I like my Mac.
>
> I like all of my Macs.
>
>> Now, please bear with my non-sequitir for a moment.
>
> No problem; it's a perfect analogy.
>
> > Why are Apple products so popular with their users?
>
> Here you've changed the rules. Saying "Lisp is (not) popular" is a
> far cry from saying "Apple is (not) popular with their users".
> Let's put aside the ipods, etc., for now and just deal with the Macs
> - it is true that Macs are extremely popular with their users; we
> tend to love them, even though they are not perfect. However, what
> is the current percentage of market share that Mac has in the PC
> world? A percent or two? That certainly isn't popular. And with a
> product as useful as the Mac, why shouldn't it be popular? Do you
> think it's on the cusp of popularity, and if so, why? What should
> Apple do to fix their problem?
They should open source their hardware and go into a line of
Metaphoric Web "diagonals", the secret plan for which I have right
here in my back pocket ...
> (I shouldn't even need the smiley here ...)
On Jul 12, 12:04 am, Duane Rettig <····@franz.com> wrote:
> Well, let's move to Lisp - Lisp is certainly popular with its users.
> Just like Macs. And Lisp has a very small share of the language
> market. Do you think Lisp should follow in the Mac's footsteps?
Excellent points! Now, let's see if I can stretch this analogy past
its breaking point.
First is that while Mac market share is very low, it is growing faster
than the competition. According to some recent graphs on the
internets, that may be true of open source Common Lisp implementations
as well. (We don't have the corresponding numbers for commercial
implementations, of course.) So, maybe Lisp should just keep doing
what its doing.
I think it's worthwhile to speculate, however, what is causing this
rise in popularity and what are the next steps to continue in that
direction. Mac didn't start to increase market share until it lowered
many of the barriers to entry for Windows users. I think Starter
Pack, for example, is a very good way to lower barriers to Lisp
adoption and could benefit implementations other than LispWorks/
Windows as well. What other things may have lowered barriers to Lisp
adoption, and what could continue those trends?
Another way to look at it is to consider the iPhone. The iPhone is a
Mac in the sense of running Mac OS X. But it's the Mac competing in a
brand new market where there is not yet a dominant player (cell phone
handsets). And in another sense, it is a totally new product
category. This is kind of like what happened with Ruby and Rails;
Rails came into an existing market, but was pretty much a new product
category at the same time.
It would be great if this were to happen to Lisp. It would be
wonderful if somebody invented a new framework/programming paradigm in
Common Lisp that was just what some group of programmers wanted, Lisp
could get really popular really fast. But the trouble is you can't
really plan a "disruptive" technology. You just have to recognize it
when it happens.
Now I'm going to respond to Rafael Cavalloro, because I think I can
fit this into the Mac metaphor also.
I always tell people who want to buy a new computer "If you plan to
spend $1100 or more, buy a Mac." That's about the price of a new
MacBook, last I checked. Considering the hardware and that it's a Mac
that can also run Windows if necessary, it compares favorably to
Windows PCs in that price range.
So maybe that analogy carries over to Common Lisp as well. If you
want to spend a few thousand dollars on your programming language, you
can't do better than a commercial Common Lisp distribution. If you
want to spend less than that (say, $0), you might want to consider
another language.
Well, that's about it. I can't think of any way to stretch this
metaphor any further, so I guess I'm done.
-jimbo
Duane Rettig <·····@franz.com> wrote on Wed, 11 Jul 2007:
> However, what is the current percentage of market share that Mac has in the
> PC world? A percent or two? That certainly isn't popular. And with a
> product as useful as the Mac, why shouldn't it be popular? Do you think
> it's on the cusp of popularity, and if so, why? What should Apple do to
> fix their problem? What tweak can they make to the Mac to put it over the
> edge so that it competes with the obviously vastly superior Windows
> machines?
>
> Well, let's move to Lisp - Lisp is certainly popular with its users.
> Just like Macs. And Lisp has a very small share of the language
> market. Do you think Lisp should follow in the Mac's footsteps?
Why should Lisp follow the Mac's footsteps? Lisp and Mac may be in the same
strategic situation, but Macs have no more solutions than Lisp does.
Steve Jobs is brilliant, in at least three areas: product design, marketing,
and strategic business planning. His "fix" for Apple was _not_ to solve this
Mac-is-unpopular problem (which is shared by Lisp), but instead to morph
Apple into Sony (a consumer products company).
Jobs has done many things, but one thing he has NOT done is make the Mac
compete with Windows in any significant volumes.
What actual steps do you think the Mac took, that Lisp could even consider
emulating?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I wish I lived on a planet that had two suns---regular sun and "rogue" sun.
That way, when somebody asked me what time it was, I'd say, "Regular time?"
And they'd say, "Yeah." And I'd say, "Sorry, all I have is rogue time." It'd
be fun to be a stuck-up rogue-time guy. -- Deep Thoughts, by Jack Handey
Don Geddis <···@geddis.org> writes:
> Duane Rettig <·····@franz.com> wrote on Wed, 11 Jul 2007:
>> However, what is the current percentage of market share that Mac has in the
>> PC world? A percent or two? That certainly isn't popular. And with a
>> product as useful as the Mac, why shouldn't it be popular? Do you think
>> it's on the cusp of popularity, and if so, why? What should Apple do to
>> fix their problem? What tweak can they make to the Mac to put it over the
>> edge so that it competes with the obviously vastly superior Windows
>> machines?
>>
>> Well, let's move to Lisp - Lisp is certainly popular with its users.
>> Just like Macs. And Lisp has a very small share of the language
>> market. Do you think Lisp should follow in the Mac's footsteps?
Precisely my question to the previous poster.
> Why should Lisp follow the Mac's footsteps? Lisp and Mac may be in the same
> strategic situation, but Macs have no more solutions than Lisp does.
Precisely.
> Steve Jobs is brilliant, in at least three areas: product design, marketing,
> and strategic business planning. His "fix" for Apple was _not_ to solve this
> Mac-is-unpopular problem (which is shared by Lisp), but instead to morph
> Apple into Sony (a consumer products company).
Precisely.
> Jobs has done many things, but one thing he has NOT done is make the Mac
> compete with Windows in any significant volumes.
Precisely.
> What actual steps do you think the Mac took, that Lisp could even consider
> emulating?
Precisely!
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <··············@geddis.org>, Don Geddis <···@geddis.org>
wrote:
> Duane Rettig <·····@franz.com> wrote on Wed, 11 Jul 2007:
> > However, what is the current percentage of market share that Mac has in the
> > PC world? A percent or two? That certainly isn't popular. And with a
> > product as useful as the Mac, why shouldn't it be popular? Do you think
> > it's on the cusp of popularity, and if so, why? What should Apple do to
> > fix their problem? What tweak can they make to the Mac to put it over the
> > edge so that it competes with the obviously vastly superior Windows
> > machines?
> >
> > Well, let's move to Lisp - Lisp is certainly popular with its users.
> > Just like Macs. And Lisp has a very small share of the language
> > market. Do you think Lisp should follow in the Mac's footsteps?
>
> Why should Lisp follow the Mac's footsteps? Lisp and Mac may be in the same
> strategic situation, but Macs have no more solutions than Lisp does.
>
> Steve Jobs is brilliant, in at least three areas: product design, marketing,
> and strategic business planning. His "fix" for Apple was _not_ to solve this
> Mac-is-unpopular problem (which is shared by Lisp), but instead to morph
> Apple into Sony (a consumer products company).
>
> Jobs has done many things, but one thing he has NOT done is make the Mac
> compete with Windows in any significant volumes.
Don't underestimate Jobs. I guess he has learned his Art of War.
He is not attacking the enemy from the front. He currently
is adding new weapons that are slightly positioned to the side, but will
strengthen the center, too.
> What actual steps do you think the Mac took, that Lisp could even consider
> emulating?
Look at what Jobs did:
* first simplify the offerings and get rid of all baggage
* get a robust engine with a growth path (NeXT OS, Mach, BSD, Aqua, ...)
* leverage existing, even outside, technology (BSD, Webkit, CUPS, ...)
* take open source software, 'improve it' and write a useable
user interface (a good example is that CUPS is the base
for Mac OS X printing services - on the Mac it is simple
to use, on other platforms less so)
* get a big competitor to port its crucial software over (MS Office)
* have a grip on data formats (Quicktime, AAC, H.264, XML, ...)
* be on the Internet
* write popular applications that people like to use
(iTunes, iLife, iWork, Logic, Final Cut, ...)
* create standards for high-end multimedia apps and write/buy those
(Logic Pro, Shake, Final Cut Pro, Aperture, ...)
What Jobs did was, he was creating an environment where SOFTWARE
gets written in an incremental, evolutionary process. Software
gets released early and then improved incrementally.
10.4 has seen 10 updates. 10.3 has seen 9 updates.
The iPod went through six iterations.
Nobody else uses Objective-C, but it seems to work fine for them.
In one interview Jobs said, it's all about software. Most people don't
understand or even see that. But all their services is all
software (iTunes Music Store). The iPod is software.
The iPhone is a platform for Apple's software. Mac OS X is
software.
So what can be learned from them is to leverage better and
faster software development. They eat their own dogfood.
They don't shoot for the perfect release, but for the
perfect growth path.
Plus, as Alan Kay said, those who care about their software
should also make their own hardware. ;-)
Apple is now worth over a 100 billion dollar and growing.
But, what is more important than shipped units, they
have a lot mindshare. They are seen as 'leader'
(though from a Lisp point of view, adding GC to
Mac OS X finally in 2007 is a bit late).
>
> -- Don
> _______________________________________________________________________________
> Don Geddis http://don.geddis.org/ ···@geddis.org
> I wish I lived on a planet that had two suns---regular sun and "rogue" sun.
> That way, when somebody asked me what time it was, I'd say, "Regular time?"
> And they'd say, "Yeah." And I'd say, "Sorry, all I have is rogue time." It'd
> be fun to be a stuck-up rogue-time guy. -- Deep Thoughts, by Jack Handey
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> wrote on Thu, 12 Jul 2007:
> Don't underestimate Jobs. I guess he has learned his Art of War. He is not
> attacking the enemy from the front. He currently is adding new weapons that
> are slightly positioned to the side, but will strengthen the center, too.
I agree that Jobs' original intention in developing the iPod was to sell
more Macs. This was the accidental success that led him to transition Apple
into a consumer products company. For a year, the iPod was Mac-only, and
Jobs had been quoted internally as saying that it would "never" be available
for Windows. Jobs negotiated with the music companies so that they would keep
all the profit; he ran the iTunes store as a loss leader.
Jobs' original iPod strategy failed. He did not, in the end, make a giant
breakthrough in Mac sales. Eventually Jobs realized the gold mine he had in
the iPod, made it Windows compatible, and now it is a huge fraction of what
the company does.
The new iPhone is yet another major new market. Its affect on future Mac
sales will be minor.
If you think Jobs is doing all this sideways work with the sole purpose of
winning the PC war, you're crazy. Jobs cannot win the PC war. iPods, iPhones,
and other things like Apple TV are turning Apple into Sony, a broad consumer
products company.
These aren't end-arounds for the original objective (although the iPod may
have started out that way). They have become important enough revenue sources
that they are new goals in and of themselves.
A decade from now, Macs will STILL be a tiny fraction of all PCs sold, but
at the same time it will only be a tiny part of Apple the company.
>> What actual steps do you think the Mac took, that Lisp could even consider
>> emulating?
>
> Look at what Jobs did:
> * first simplify the offerings and get rid of all baggage
> * get a robust engine with a growth path (NeXT OS, Mach, BSD, Aqua, ...)
> * leverage existing, even outside, technology (BSD, Webkit, CUPS, ...)
> * take open source software, 'improve it'
> * get a big competitor to port its crucial software over (MS Office)
> * have a grip on data formats (Quicktime, AAC, H.264, XML, ...)
> * be on the Internet
> * write popular applications that people like to use
> * create standards for high-end multimedia apps and write/buy those
> What Jobs did was, he was creating an environment where SOFTWARE
> gets written in an incremental, evolutionary process. Software
> gets released early and then improved incrementally.
Sure, all this stuff is great, and no doubt the Mac is much better than it
was. I'm not disputing that at all.
What I'm disputing, is that Apple has made any significant impact on worldwide
PC sales.
Think of it this way: Apple could double their sales, and the rest of the PC
industry would scarcely notice. What is good for the one company is not
necessarily important for the whole industry.
> Apple is now worth over a 100 billion dollar and growing.
Not (solely) because of Mac sales.
> But, what is more important than shipped units, they have a lot mindshare.
As a consumer products company. Much less so as a PC manufacturer.
Jobs is a world-class CEO, and brilliant. But even he had no real solution to
the Mac's lack of popularity despite superior quality.
There are structural (business) things that matter in an industry, not just a
pure technical comparison between products. Macs, and Lisp, are high-quality,
low-popularity products. It is likely that there is nothing that can be done
to change that in a significant way. The barriers to acceptance are not
technical quality.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The trouble with the world is that the stupid are cocksure and the
intelligent are full of doubt. -- Bertrand Russell
In article <··············@geddis.org>, Don Geddis <···@geddis.org>
wrote:
> Rainer Joswig <······@lisp.de> wrote on Thu, 12 Jul 2007:
> > Don't underestimate Jobs. I guess he has learned his Art of War. He is not
> > attacking the enemy from the front. He currently is adding new weapons that
> > are slightly positioned to the side, but will strengthen the center, too.
>
> I agree that Jobs' original intention in developing the iPod was to sell
> more Macs. This was the accidental success that led him to transition Apple
> into a consumer products company. For a year, the iPod was Mac-only, and
> Jobs had been quoted internally as saying that it would "never" be available
> for Windows. Jobs negotiated with the music companies so that they would keep
> all the profit; he ran the iTunes store as a loss leader.
>
> Jobs' original iPod strategy failed. He did not, in the end, make a giant
> breakthrough in Mac sales. Eventually Jobs realized the gold mine he had in
> the iPod, made it Windows compatible, and now it is a huge fraction of what
> the company does.
>
> The new iPhone is yet another major new market. Its affect on future Mac
> sales will be minor.
>
> If you think Jobs is doing all this sideways work with the sole purpose of
> winning the PC war, you're crazy. Jobs cannot win the PC war. iPods, iPhones,
> and other things like Apple TV are turning Apple into Sony, a broad consumer
> products company.
Definitely not Sony. Sony has no OS. They have to take what
MS offers.
Apple wants definitely a bigger impact. All the platforms are
OSX. He moves OSX to all the platforms. iPods will run OSX
soon. He wants OSX on machines which are not PCs. Sales of consumer
machines suddenly will help improving OSX.
But it may not be traditional PCs. My bet is that they want
more radical off-the-charts stuff in the future. Low-power,
mobile machines with a full OS like the iPhone are only the
beginning. Just a guess. Apple does not care much about
the traditional PC market, since it is dead anyway. There
are almost no profits to make there. IBM sold business to Lenovo,
DELL struggles, ...
> What I'm disputing, is that Apple has made any significant impact on worldwide
> PC sales.
What is 'significant'?
Has Mercedes a 'significant' impact on world-wide car sales?
Would 'the' market care if Mercedes double their market share?
> Think of it this way: Apple could double their sales, and the rest of the PC
> industry would scarcely notice.
You mean Apple would be up from, say five percent, to ten percent?
That would be very noticeable, especially it is a more profitable
ten percent. It is also not the case that there is one big market.
There is a multitude of markets: corporate, private, gamers,
developers, creative, developers, home media, laptop,
desktop, ...
> > But, what is more important than shipped units, they have a lot mindshare.
>
> As a consumer products company. Much less so as a PC manufacturer.
If I read magazines, like c't, I read about ultra-low-power-micro
PCs, QUAD-Core Intel machines with 3 GHz, and the stuff.
I'm constantly reading about them and other machines being
compared to iMacs, Mac minis, Macbooks, MacrPros and so on.
> Jobs is a world-class CEO, and brilliant. But even he had no real solution to
> the Mac's lack of popularity despite superior quality.
>
> There are structural (business) things that matter in an industry, not just a
> pure technical comparison between products. Macs, and Lisp, are high-quality,
> low-popularity products. It is likely that there is nothing that can be done
> to change that in a significant way. The barriers to acceptance are not
> technical quality.
If you go to developer conferences these days, there is a good chance
that fifty percent have Macs.
Btw., commercial Lisp vendors have seen similar effects lately. They
sell a large(r) slice of their licenses to Macs.
>
> -- Don
> _______________________________________________________________________________
> Don Geddis http://don.geddis.org/ ···@geddis.org
> The trouble with the world is that the stupid are cocksure and the
> intelligent are full of doubt. -- Bertrand Russell
--
http://lispm.dyndns.org
On Jul 13, 10:42 am, Rainer Joswig <······@lisp.de> wrote:
> In article <··············@geddis.org>, Don Geddis <····@geddis.org>
> wrote:
>
>
>
>
>
> > Rainer Joswig <······@lisp.de> wrote on Thu, 12 Jul 2007:
> > > Don't underestimate Jobs. I guess he has learned his Art of War. He is not
> > > attacking the enemy from the front. He currently is adding new weapons that
> > > are slightly positioned to the side, but will strengthen the center, too.
>
> > I agree that Jobs' original intention in developing the iPod was to sell
> > more Macs. This was the accidental success that led him to transition Apple
> > into a consumer products company. For a year, the iPod was Mac-only, and
> > Jobs had been quoted internally as saying that it would "never" be available
> > for Windows. Jobs negotiated with the music companies so that they would keep
> > all the profit; he ran the iTunes store as a loss leader.
>
> > Jobs' original iPod strategy failed. He did not, in the end, make a giant
> > breakthrough in Mac sales. Eventually Jobs realized the gold mine he had in
> > the iPod, made it Windows compatible, and now it is a huge fraction of what
> > the company does.
>
> > The new iPhone is yet another major new market. Its affect on future Mac
> > sales will be minor.
>
> > If you think Jobs is doing all this sideways work with the sole purpose of
> > winning the PC war, you're crazy. Jobs cannot win the PC war. iPods, iPhones,
> > and other things like Apple TV are turning Apple into Sony, a broad consumer
> > products company.
>
> Definitely not Sony. Sony has no OS. They have to take what
> MS offers.
>
> Apple wants definitely a bigger impact. All the platforms are
> OSX. He moves OSX to all the platforms. iPods will run OSX
> soon. He wants OSX on machines which are not PCs. Sales of consumer
> machines suddenly will help improving OSX.
>
> But it may not be traditional PCs. My bet is that they want
> more radical off-the-charts stuff in the future. Low-power,
> mobile machines with a full OS like the iPhone are only the
> beginning. Just a guess. Apple does not care much about
> the traditional PC market, since it is dead anyway. There
> are almost no profits to make there. IBM sold business to Lenovo,
> DELL struggles, ...
>
> > What I'm disputing, is that Apple has made any significant impact on worldwide
> > PC sales.
>
> What is 'significant'?
>
> Has Mercedes a 'significant' impact on world-wide car sales?
> Would 'the' market care if Mercedes double their market share?
Not a fair comparasion, car market is not monopolised by a single
company, if I don't want toyota there's plenty of other options. In
desktop pc you must choose windows unless:
1. You are willing to pay a serious amount of cash for Mac and get
easy user interface
2. You are willing to learn more about your OS than 99.99% of people
want.
http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html
3. A lot of programs (especially games) won't operate on both Mac nor
linux/freebsd .
> > Think of it this way: Apple could double their sales, and the rest of the PC
> > industry would scarcely notice.
>
> You mean Apple would be up from, say five percent, to ten percent?
> That would be very noticeable, especially it is a more profitable
> ten percent. It is also not the case that there is one big market.
> There is a multitude of markets: corporate, private, gamers,
> developers, creative, developers, home media, laptop,
> desktop, ...
Tend to agree with Rainer. I like to make my code portable, the bigger
the market share of ms competitors more developers will look on those
markets especially if there is money but the market is underserved.
> > > But, what is more important than shipped units, they have a lot mindshare.
>
> > As a consumer products company. Much less so as a PC manufacturer.
>
> If I read magazines, like c't, I read about ultra-low-power-micro
> PCs, QUAD-Core Intel machines with 3 GHz, and the stuff.
> I'm constantly reading about them and other machines being
> compared to iMacs, Mac minis, Macbooks, MacrPros and so on.
>
> > Jobs is a world-class CEO, and brilliant. But even he had no real solution to
> > the Mac's lack of popularity despite superior quality.
>
> > There are structural (business) things that matter in an industry, not just a
> > pure technical comparison between products. Macs, and Lisp, are high-quality,
> > low-popularity products. It is likely that there is nothing that can be done
> > to change that in a significant way. The barriers to acceptance are not
> > technical quality.
>
> If you go to developer conferences these days, there is a good chance
> that fifty percent have Macs.
Good sign but how many of them are making software for mac? I have a
friend that is a die hard FreeBSD but still have to make his products
for Windows because there was no market for unices. ye s there are web
services , but some there is software that users want to to keep on
their servers, and guess what ? They run windows servers only. And
he's far from exception.
>
> Btw., commercial Lisp vendors have seen similar effects lately. They
> sell a large(r) slice of their licenses to Macs.
That's a good sign.
Rainer Joswig <······@lisp.de> wrote on Fri, 13 Jul 2007:
> In article <··············@geddis.org>, Don Geddis <···@geddis.org> wrote:
>> iPods, iPhones, and other things like Apple TV are turning Apple into
>> Sony, a broad consumer products company.
>
> Definitely not Sony. Sony has no OS. They have to take what MS offers.
I fail to see why the OS makes such a difference in this analogy.
> Apple wants definitely a bigger impact.
A bigger impact than Sony? In the 1990's, Sony made piles of different
consumer electronics gadgets: walkmans, televisions, PCs, laptops, cameras,
etc. They were known as state-of-the-art design, awesome UI and easy-of-use,
pushing the envelope in quality and technology, etc.
I don't see that a lack of OS really hurt them. Or mattered at all.
And I don't see how it necessarily helps Apple. The iPod's domination of
MP3 players has basically nothing to do with OSX.
> All the platforms are OSX. He moves OSX to all the platforms. iPods will
> run OSX soon. He wants OSX on machines which are not PCs. Sales of consumer
> machines suddenly will help improving OSX.
Could be, but why do you think this is important to the strategic business
questions?
OSX is not a revenue source for Apple in the way that Windows is for
Microsoft. MS was built on Windows sales. Apple cannot be built on OSX
sales.
>> What I'm disputing, is that Apple has made any significant impact on
>> worldwide PC sales.
>
> What is 'significant'?
> Has Mercedes a 'significant' impact on world-wide car sales?
> Would 'the' market care if Mercedes double their market share?
>
> It is also not the case that there is one big [PC] market. There is a
> multitude of markets: corporate, private, gamers, developers, creative,
> developers, home media, laptop, desktop, ...
You can segment the market, and dominate in a segment. In PC sales, niche
companies like Alienware and Voodoo and Falcon make very high-end gaming PCs.
Their total revenue is small compared to the overall PC market, but they
dominate in their niche.
In what niche do you think Apple dominates PC sales? Apple is a broad-based
PC company, attempting (but failing) to appeal to the average PC buyer.
>> Think of it this way: Apple could double their sales, and the rest of the PC
>> industry would scarcely notice.
>
> You mean Apple would be up from, say five percent, to ten percent?
> That would be very noticeable, especially it is a more profitable
> ten percent.
In 2005, it appears that Dell had 18% of worldwide sales, #2 HP, #3 Lenovo,
#4 Acer had 4.1%. In US-only sales, Dell was 33%, #2 HP, Gateway 6%, #5
Toshiba and Apple each at about 3.3%.
For 2006, in the US-only market, it looks like #1 Dell 31%, #2 HP 22%, #3
Gateway 6%, #4 Apple 5.8%, and #5 Toshiba 4.2%.
For Q1/2007, it looks like worldwide #1 HP at 19%, #2 Dell 15.2%, #3 tie
between Acer and Lenovo at 6.7%, #5 Toshiba at 4.3%.
Apple is doing great, and from 2005 to 2006 they increased their share of the
US PC market by about a percent. Which is awesome for a company.
But come on. They're only 5% of just the US market, and barely a blip on the
overall world market. Jobs deserves a ton of credit for getting Mac sales
from the depths of 2-3% US share up to almost 6%. Keep in mind that in the
early days of the PC market, Apple had more like a 12-15% share, IIRC.
If you think it is unfair to compare Mac sales to HP or Dell, then you've got
to be a little more concrete about exactly what market you think they're in.
If Apple gets a pass on this comparison, then by the same token why do people
here care about Lisp popularity vs. Java or Python or Ruby? Perhaps they are
"different markets" also, and Lisp is already dominating its own market.
Could be, but the existing comparisons are the most natural ones. If you
think a different one is more appropriate, then the burden on you is to
explain and defend the niche market.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I went on to test the program in every way I could devise. I strained it to
expose its weaknesses. I ran it for high-mass stars and low-mass stars, for
stars born exceedingly hot and those born relatively cold. I ran it assuming
the superfluid currents beneath the crust to be absent -- not because I wanted
to know the answer, but because I had developed an intuitive feel for the
answer in this particular case. Finally I got a run in which the computer
showed the pulsar's temperature to be less than absolute zero. I had found an
error. I chased down the error and fixed it. Now I had improved the program
to the point where it would not run at all.
-- George Greenstein
"Frozen Star: Of Pulsars, Black Holes and the Fate of Stars"
In article <··············@geddis.org>, Don Geddis <···@geddis.org>
wrote:
> Rainer Joswig <······@lisp.de> wrote on Fri, 13 Jul 2007:
> > In article <··············@geddis.org>, Don Geddis <···@geddis.org> wrote:
> >> iPods, iPhones, and other things like Apple TV are turning Apple into
> >> Sony, a broad consumer products company.
> >
> > Definitely not Sony. Sony has no OS. They have to take what MS offers.
>
> I fail to see why the OS makes such a difference in this analogy.
>
> > Apple wants definitely a bigger impact.
>
> A bigger impact than Sony?
A bigger impact than they have now.
> In the 1990's, Sony made piles of different
> consumer electronics gadgets: walkmans, televisions, PCs, laptops, cameras,
> etc. They were known as state-of-the-art design, awesome UI and easy-of-use,
> pushing the envelope in quality and technology, etc.
>
> I don't see that a lack of OS really hurt them. Or mattered at all.
That was the past. I used to have Sony gear, but now they
don't set trends anymore. I had a laptop, DAT recorder, disc man, ...
all Sony. Music has moved to computers. Apple sells the
player and the computer to record music. iTunes has
seen a quarter billion downloads. Software. Also for Windows.
> And I don't see how it necessarily helps Apple. The iPod's domination of
> MP3 players has basically nothing to do with OSX.
Wait a few months, next year iPods will be OSX based.
> > All the platforms are OSX. He moves OSX to all the platforms. iPods will
> > run OSX soon. He wants OSX on machines which are not PCs. Sales of consumer
> > machines suddenly will help improving OSX.
>
> Could be, but why do you think this is important to the strategic business
> questions?
Because gradually there is a larger base. Gradually there is a larger
eco-system for software.
> > It is also not the case that there is one big [PC] market. There is a
> > multitude of markets: corporate, private, gamers, developers, creative,
> > developers, home media, laptop, desktop, ...
>
> You can segment the market, and dominate in a segment. In PC sales, niche
> companies like Alienware and Voodoo and Falcon make very high-end gaming PCs.
> Their total revenue is small compared to the overall PC market, but they
> dominate in their niche.
>
> In what niche do you think Apple dominates PC sales? Apple is a broad-based
> PC company, attempting (but failing) to appeal to the average PC buyer.
I doubt they attempt to go after the average buyer. That
part of the market is not profitable.
It is also not about domination. In the overall PC market
or in submarkets it is a good start to be competitive.
To have a solution that people might buy and some even will
buy.
> In 2005, it appears that Dell had 18% of worldwide sales, #2 HP, #3 Lenovo,
> #4 Acer had 4.1%. In US-only sales, Dell was 33%, #2 HP, Gateway 6%, #5
> Toshiba and Apple each at about 3.3%.
>
> For 2006, in the US-only market, it looks like #1 Dell 31%, #2 HP 22%, #3
> Gateway 6%, #4 Apple 5.8%, and #5 Toshiba 4.2%.
>
> For Q1/2007, it looks like worldwide #1 HP at 19%, #2 Dell 15.2%, #3 tie
> between Acer and Lenovo at 6.7%, #5 Toshiba at 4.3%.
>
> Apple is doing great, and from 2005 to 2006 they increased their share of the
> US PC market by about a percent. Which is awesome for a company.
Plus there part of the market is very profitable.
> But come on. They're only 5% of just the US market, and barely a blip on the
> overall world market. Jobs deserves a ton of credit for getting Mac sales
> from the depths of 2-3% US share up to almost 6%. Keep in mind that in the
> early days of the PC market, Apple had more like a 12-15% share, IIRC.
That market was smaller and less valuable?
> If you think it is unfair to compare Mac sales to HP or Dell, then you've got
> to be a little more concrete about exactly what market you think they're in.
Education, Creative, Developers, some Science, Small business,
Home users, Multimedia, ...
> If Apple gets a pass on this comparison, then by the same token why do people
> here care about Lisp popularity vs. Java or Python or Ruby? Perhaps they are
> "different markets" also, and Lisp is already dominating its own market.
There are different markets. I'm not sure in which market Lisp
dominates. I'm not sure 'dominate' is also the right word.
I would start with being 'competitive' or even seen as competitive
in some markets. Whereas Apple as a software-based company
(really) has growth paths and is seen as competetive
in at least two business areas (relative and absolute), software
companies in the Lisp business seem to survive, but their growth
path is not so clear to me. So maybe there is something
to learn, how to expand a software business from a
niche?
>
> Could be, but the existing comparisons are the most natural ones. If you
> think a different one is more appropriate, then the burden on you is to
> explain and defend the niche market.
>
> -- Don
> _______________________________________________________________________________
> Don Geddis http://don.geddis.org/ ···@geddis.org
> I went on to test the program in every way I could devise. I strained it to
> expose its weaknesses. I ran it for high-mass stars and low-mass stars, for
> stars born exceedingly hot and those born relatively cold. I ran it assuming
> the superfluid currents beneath the crust to be absent -- not because I wanted
> to know the answer, but because I had developed an intuitive feel for the
> answer in this particular case. Finally I got a run in which the computer
> showed the pulsar's temperature to be less than absolute zero. I had found an
> error. I chased down the error and fixed it. Now I had improved the program
> to the point where it would not run at all.
> -- George Greenstein
> "Frozen Star: Of Pulsars, Black Holes and the Fate of Stars"
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> wrote on Fri, 13 Jul 2007:
> That was the past. I used to have Sony gear, but now they don't set trends
> anymore. I had a laptop, DAT recorder, disc man, ... all Sony.
Oh, sure, that's true. Sony has had a bad decade.
My point was that Jobs is in the process of turning Apple into the kind of
company that Sony was in the 1990's. At that time, Sony had a worldwide
leadership position in high-quality, innovative, high-margin consumer
electronics.
Today, Sony has stumbled badly, and the slack is taken up by Samsung, and
increasingly by Apple.
Apple's market cap success of the last few years is because Jobs has moved it
AWAY from selling PCs. Apple is becoming a different kind of company than a
personal computer manufacturer, which it was for a few decades, until the last
few years.
>> And I don't see how it necessarily helps Apple. The iPod's domination of
>> MP3 players has basically nothing to do with OSX.
>
> Wait a few months, next year iPods will be OSX based.
You missed the point, which is that the huge success of the iPod to date has
nothing at all to do with Apple's development of OSX. OSX is a mildly
interesting thing, but it is NOT the explanation for Apple's rise and Sony's
fall. Earlier you said that the difference between Sony and Apple is that
Apple makes an operating system (OSX). I dispute that this is a significant
factor in Apple's consumer electronics success, and the fact that iPods to
date have NOT been based on OSX is evidence in my favor.
>> If you think it is unfair to compare Mac sales to HP or Dell, then you've
>> got to be a little more concrete about exactly what market you think
>> they're in.
>
> Education, Creative, Developers, some Science, Small business,
> Home users, Multimedia, ...
Education, maybe. Graphic design, used to be more in the '90s; not quite as
Mac-heavy today. Small business? Home users? I'd be shocked if Apple had
more than single-digit penetration of these markets.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The human spirit is a very hard thing to kill. Even with a chainsaw.
In article <··············@geddis.org>, Don Geddis <···@geddis.org>
wrote:
> Rainer Joswig <······@lisp.de> wrote on Fri, 13 Jul 2007:
> > That was the past. I used to have Sony gear, but now they don't set trends
> > anymore. I had a laptop, DAT recorder, disc man, ... all Sony.
>
> Oh, sure, that's true. Sony has had a bad decade.
>
> My point was that Jobs is in the process of turning Apple into the kind of
> company that Sony was in the 1990's. At that time, Sony had a worldwide
> leadership position in high-quality, innovative, high-margin consumer
> electronics.
My point is that the 90s are over and the current developments are based
on software, not transistors. The PC market is also history. Grey boxes
no longer needed. People increasingly buy portable devices with networked
software. The computer looks differently and has already
replaced much of the audio/video equipment that were used in the 90s.
What was hardware is now software. Lots of people now use
laptops as their primary machines, some have tablets, smartphones,
multimedia players - new telephones are now running complex
operating systems like Symbian, Windows Mobile, Linux or even OSX.
Any company that does not have a deep understanding of software has a huge
disadvantage.
> > Wait a few months, next year iPods will be OSX based.
>
> You missed the point, which is that the huge success of the iPod to date has
> nothing at all to do with Apple's development of OSX. OSX is a mildly
> interesting thing, but it is NOT the explanation for Apple's rise and Sony's
> fall.
Of course it has to do with OSX. What do you think iTunes was developed on?
The iPod, the Mac, the PC, the AppleTV, the iPhone - all are fueled by iTunes
and the store. With OSX one even creates the contents (iLife, Logic, ...).
The whole eco-system is based on software. The UI is generated by
software, too.
> Earlier you said that the difference between Sony and Apple is that
> Apple makes an operating system (OSX). I dispute that this is a significant
> factor in Apple's consumer electronics success, and the fact that iPods to
> date have NOT been based on OSX is evidence in my favor.
It is not because they make OSX, it is because they make software in general
including the OS.
The iPod is full vertical solution. Online Store, local media software, content
creation, etc. The hardware is one factor. The more interesting thing
is that you get contents, there is a software-based distribution,
there is content creation, there are media formats and codec and
players for them. There is a UI. Much of them is written by Apple themselves.
The iTunes store is based on WebObjects. iTunes is written with
Apple's tools and ported over to Windows. The only thing they
lacked was an OS for small multimedia devices. That has been fixed now.
Sony makes good devices as anybody else. They are struggling
on the software side. Their laptops don't suck because of
the hardware, they suck because the drivers for the foreign OS
is so bad. Mine would not wake up from sleep in 40% of my attempts
and this was a common problem. It could not be fixed successfully,
they just did not control the software. Their
media software sucks big time. MP3 files had to be converted
to be downloaded to their players.
What does this have to do with this newsgroup? Here are software
developers, right? More focus on being able to deliver useful apps
for real users (plus actually delivering them) and less focus on
theoretical beauty would improve things. Is there room for
improvement? I think so. Should we learn from groups
which successfully develop software? Could be useful to
study their approach.
>
> >> If you think it is unfair to compare Mac sales to HP or Dell, then you've
> >> got to be a little more concrete about exactly what market you think
> >> they're in.
> >
> > Education, Creative, Developers, some Science, Small business,
> > Home users, Multimedia, ...
>
> Education, maybe. Graphic design, used to be more in the '90s; not quite as
> Mac-heavy today. Small business? Home users? I'd be shocked if Apple had
> more than single-digit penetration of these markets.
>
> -- Don
> _______________________________________________________________________________
> Don Geddis http://don.geddis.org/ ···@geddis.org
> The human spirit is a very hard thing to kill. Even with a chainsaw.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> wrote on Sat, 14 Jul 2007:
> My point is that the 90s are over and the current developments are based
> on software, not transistors.
There's something in the middle, which is consumer electronics design.
Sony in the 1990's was not Intel. It was something very different. So
saying "not transistors" isn't drawing the right comparison.
Saying "it's software" also leaves out critical pieces of design. We're not
talking about web sites here, or applications running on PCs. We're talking
whole-product design for small electronic devices. It's exactly the field
Sony used to dominate, and which Apple is now entering.
If you were Apple in 2000, and you were to say "our new strategy is to get
away from transistors and go into software" that would have implied a
direction different from the one Apple is actually embarked on right now.
> The PC market is also history. Grey boxes no longer needed.
I think this is simply false. Global PC sales are projected to grow 11% in
2007, to more than 250 million units.
It's crazy to just dismiss that huge, huge, huge market.
> Lots of people now use laptops as their primary machines
Laptops are part of the PC market, by the way. Perhaps you didn't mean to
include them in your "grey boxes" label.
>> You missed the point, which is that the huge success of the iPod to date has
>> nothing at all to do with Apple's development of OSX. OSX is a mildly
>> interesting thing, but it is NOT the explanation for Apple's rise and Sony's
>> fall.
>
> Of course it has to do with OSX. What do you think iTunes was developed on?
The vast majority of iPods are surely sold to PC users, running iTunes on
Windows. Not an OSX in sight...
> Sony makes good devices as anybody else. They are struggling on the
> software side. Their laptops don't suck because of the hardware, they suck
> because the drivers for the foreign OS is so bad. Mine would not wake up
> from sleep in 40% of my attempts and this was a common problem.
I doubt this example is the primary reason Sony as a company has struggled
for a decade.
Their failure to beat Apple's iPod in the MP3 market also is unlikely due to
an inability to write good software.
> Their media software sucks big time. MP3 files had to be converted to be
> downloaded to their players.
You attribute this to incompetent software engineers at Sony. In truth, they
had a more complex business environment, as Sony has a huge division which
owns and sells music. There were huge internal wars at Sony with the (MP3)
consumer electronics division fighting against the music content group.
Their resulting products were a compromise, and they suffered in the market
because of it.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Bigamy is having one husband or wife too many. Monogamy is the same.
Don Geddis wrote:
> Rainer Joswig <······@lisp.de> wrote on Sat, 14 Jul 2007:
>> Lots of people now use laptops as their primary machines
>
> Laptops are part of the PC market, by the way. Perhaps you didn't mean to
> include them in your "grey boxes" label.
In "whole user experience" terms, laptops /done right/ are very
different beasts from desktop PCs. Suspend/resume, hotplugging,
intermittent network connectivity, often issues of synchronisation with
a "base station" or "base network", size, weight, battery life, heat
output, robustness (how often do you drop a desktop?), input devices
(try doing freehand drawing with a nipple mouse or touchpad), etc etc.
There is some sense in which they're "part of the PC market", but it's
a bit like saying an iPod is "part of the audio market": you can't
replace it with a separates system.
-dan
Daniel Barlow <···@coruskate.net> wrote on Mon, 16 Jul 2007:
> Don Geddis wrote:
>> Rainer Joswig <······@lisp.de> wrote on Sat, 14 Jul 2007:
>>> Lots of people now use laptops as their primary machines
>>
>> Laptops are part of the PC market, by the way. Perhaps you didn't mean to
>> include them in your "grey boxes" label.
>
> In "whole user experience" terms, laptops /done right/ are very different
> beasts from desktop PCs. Suspend/resume, hotplugging, intermittent network
> connectivity, often issues of synchronisation with a "base station" or "base
> network", size, weight, battery life, heat output, robustness (how often do
> you drop a desktop?), input devices (try doing freehand drawing with a nipple
> mouse or touchpad), etc etc. There is some sense in which they're "part of
> the PC market", but it's a bit like saying an iPod is "part of the audio
> market": you can't replace it with a separates system.
I agree with you that they are an interesting segment of the overall global
PC market, and for many purposes cannot be directly replaced with some PC from
a different segment.
But the global PC market is full of such segments. Much the same argument
could be made about "1U rack-mounted 4-CPU PC server boxes" too. Or "high-end
overclocked liquid-cooled shuttle-box form factor gaming PCs".
Meanwhile, the big change in laptops in the last few years is that many of
them are becoming replacements for desktop machines. It used to be that a
user had a large tradeoff to make, between performance on a desktop, and
mobility on a laptop. But many high-end laptops have all the performance of
everything except the very best desktops. Now that it's no longer much of a
performance tradeoff, many users are buying laptops because "why not?" get
the mobility too. Even if they mostly use them plugged into power and a
docking station and a keyboard and a mouse and a large monitor.
So: while I agree that there is some argument to be made for examining
Apple's sales just in laptops, the market isn't so different that it is
meaningless to do the typical comparison, of Apple's Mac sales as a
percentage of the overall global PC market.
At least, no more absurd than comparing Lisp's penetration among developers,
with that of Perl or C# or Java or Haskell. Surely programming languages
could be described as belonging to a tiny niche as well, but it is still
reasonable to ask what percent of all software developers program in Lisp
vs. some other programming language.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
An unbreakable toy is useful for breaking other toys. -- Van Roy's Law
Rainer Joswig <······@lisp.de> writes:
> In article <··············@geddis.org>, Don Geddis <···@geddis.org>
> wrote:
>
>> Duane Rettig <·····@franz.com> wrote on Wed, 11 Jul 2007:
>> > However, what is the current percentage of market share that Mac has in the
>> > PC world? A percent or two? That certainly isn't popular. And with a
>> > product as useful as the Mac, why shouldn't it be popular? Do you think
>> > it's on the cusp of popularity, and if so, why? What should Apple do to
>> > fix their problem? What tweak can they make to the Mac to put it over the
>> > edge so that it competes with the obviously vastly superior Windows
>> > machines?
>> >
>> > Well, let's move to Lisp - Lisp is certainly popular with its users.
>> > Just like Macs. And Lisp has a very small share of the language
>> > market. Do you think Lisp should follow in the Mac's footsteps?
>>
>> Why should Lisp follow the Mac's footsteps? Lisp and Mac may be in the same
>> strategic situation, but Macs have no more solutions than Lisp does.
>>
>> Steve Jobs is brilliant, in at least three areas: product design, marketing,
>> and strategic business planning. His "fix" for Apple was _not_ to solve this
>> Mac-is-unpopular problem (which is shared by Lisp), but instead to morph
>> Apple into Sony (a consumer products company).
>>
>> Jobs has done many things, but one thing he has NOT done is make the Mac
>> compete with Windows in any significant volumes.
>
> Don't underestimate Jobs. I guess he has learned his Art of War.
> He is not attacking the enemy from the front. He currently
> is adding new weapons that are slightly positioned to the side, but will
> strengthen the center, too.
>
>> What actual steps do you think the Mac took, that Lisp could even consider
>> emulating?
>
> Look at what Jobs did:
>
> * first simplify the offerings and get rid of all baggage
>
> * get a robust engine with a growth path (NeXT OS, Mach, BSD, Aqua, ...)
>
> * leverage existing, even outside, technology (BSD, Webkit, CUPS, ...)
>
> * take open source software, 'improve it' and write a useable
> user interface (a good example is that CUPS is the base
> for Mac OS X printing services - on the Mac it is simple
> to use, on other platforms less so)
>
> * get a big competitor to port its crucial software over (MS Office)
>
> * have a grip on data formats (Quicktime, AAC, H.264, XML, ...)
>
> * be on the Internet
>
> * write popular applications that people like to use
> (iTunes, iLife, iWork, Logic, Final Cut, ...)
>
> * create standards for high-end multimedia apps and write/buy those
> (Logic Pro, Shake, Final Cut Pro, Aperture, ...)
>
>
> What Jobs did was, he was creating an environment where SOFTWARE
> gets written in an incremental, evolutionary process. Software
> gets released early and then improved incrementally.
> 10.4 has seen 10 updates. 10.3 has seen 9 updates.
> The iPod went through six iterations.
>
> Nobody else uses Objective-C, but it seems to work fine for them.
>
> In one interview Jobs said, it's all about software. Most people don't
> understand or even see that. But all their services is all
> software (iTunes Music Store). The iPod is software.
> The iPhone is a platform for Apple's software. Mac OS X is
> software.
>
> So what can be learned from them is to leverage better and
> faster software development. They eat their own dogfood.
> They don't shoot for the perfect release, but for the
> perfect growth path.
>
> Plus, as Alan Kay said, those who care about their software
> should also make their own hardware. ;-)
>
> Apple is now worth over a 100 billion dollar and growing.
> But, what is more important than shipped units, they
> have a lot mindshare. They are seen as 'leader'
> (though from a Lisp point of view, adding GC to
> Mac OS X finally in 2007 is a bit late).
>
I think this sort of discussion achieves very little. We are not comparing like
things. The big difference (and there are lots of differences) is that SJ had
large amounts of capital he was ready to invest into product development. CL
doesn't have this - at least it doesn't have a central point with lots of
capital that is prepared to invest in CLs development. There are commercial
vendors that do this, but they have their business plan and strategies and
discussions like this is worth little to them.
Its quite amazing how much discussions and arguments go around in circles on
this list - we see the same threads time and time again and they never reach
any resolution apart from the participants agreeing to disagree.
Bottom line, if your waiting for Common Lisp to be the next big popular
language that will either allow you to be well paid as a lisp programmer or
make squillions of dollars, your living in a fantasy world. The best we can
hope for is that new languages learn from what CL and other lisps have taught
us and we get a better language rather than just a popular language that is so
because of big business investment.
On the other hand, if you are someone who just likes coding in lisp, then just
get on and do it. If your really really lucky, you may get to do it as part of
or all of your paid job, but most likely, it will be something you just get to
do in your personal time and for your own growth and rewards.
CL is never going to be as popular or widely used as other languages like Java and it has
no single thing that is preventing it from being so - it is lots of little
things, most of which are not based on the technical merits of the language.
However, it is very likely that in time, CL will still have around the same
level of user base while other popular/trendy languages such as Java and python
have faded into the background. CL is the tortoise, here for the long haul.
Java is the hare and is likely to finish just in front of cobol.
Tim
--
tcross (at) rapttech dot com dot au
Tim X <····@nospam.dev.null> wrote on Fri, 13 Jul 2007:
> I think this sort of discussion achieves very little. We are not comparing
> like things. The big difference (and there are lots of differences) is that
> SJ had large amounts of capital he was ready to invest into product
> development. CL doesn't have this - at least it doesn't have a central
> point with lots of capital that is prepared to invest in CLs development.
Well, one point of interest is how LITTLE Steve Jobs has been able to achieve
in increasing Mac sales, DESPITE the huge amounts of capital he has available.
That's certainly relevant to theoretical discussions about what, even in
theory, might make Lisp more popular in the world.
> Bottom line, if your waiting for Common Lisp to be the next big popular
> language that will either allow you to be well paid as a lisp programmer or
> make squillions of dollars, your living in a fantasy world.
Probably correct. Nothing will happen quickly, that's for sure.
> On the other hand, if you are someone who just likes coding in lisp, then
> just get on and do it. If your really really lucky, you may get to do it as
> part of or all of your paid job, but most likely, it will be something you
> just get to do in your personal time and for your own growth and rewards.
If Lisp actually provides a productivity advantage, there's also the Paul
Graham approach of starting your own company, and using Lisp internally.
> CL is never going to be as popular or widely used as other languages like
> Java and it has no single thing that is preventing it from being so - it is
> lots of little things, most of which are not based on the technical merits
> of the language.
Agreed.
> However, it is very likely that in time, CL will still have around the same
> level of user base while other popular/trendy languages such as Java and
> python have faded into the background. CL is the tortoise, here for the
> long haul. Java is the hare and is likely to finish just in front of
> cobol.
I think you're right about that too.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The crows seemed to be calling his name, thought Caw.
-- Deep Thoughts, by Jack Handey [1999]
On Jul 12, 3:50 am, ········@gmail.com wrote:
> On Jul 11, 7:20 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>
> > Perhaps I'm just saying that lisp is not popular because the general
> > population is too dumb... (or at the very least, very ill educated).
>
> I like my Mac.
>
> Now, please bear with my non-sequitir for a moment.
>
> Why are Apple products so popular with their users? Because they save
> you a little bit of time in countless places with attention to
> detail. They eliminate little extra steps here and there throughout
> the interface, which adds up to noticeable productivity gains in
> total.
>
> What's the analogy with Common Lisp? If you start using Java or
> Python, there's a good chance there's a library to do that common task
> you have in mind already included. If you have Perl there's a good
> chance that library is in CPAN and easy to get into your system.
>
> These are small productivity gains compared to Common Lisp, perhaps,
> but they add up. They especially add up for the new Common Lisp
> programmer, who maybe had an easier time getting started in the last
> language he learned.
>
> In my opinion, Common Lisp is not very far from having the
> accessibility of these other languages. Lisp-in-a-Box and Starter
> Pack address a lot of them. The pieces just need to be put together
> and polished to work a little more smoothly.
>
> Isn't the whole point of using a better programming to increase
> productivity? Why not do the few remaining little things that close
> the gap where other languages have a productivity edge over Lisp?
>
> -jimbo
Free Lisp implementations are at minimum no inferior to free
implementations in other languages. Vendors offer high quality
editions for *learning* lisp, if you need something for production
than you have choice of buying a commercial lisp or spent some time on
your free lisp. Pick whatever suits your needs, wallet & religious
constraints. The libraries situation could be made better but you
could do something about that instead of whining all day long. Oh I
forgeth whining is easy, doing something useful requires real work.
Slobodan
On Jul 12, 4:05 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> The libraries situation could be made better but you
> could do something about that instead of whining all day long. Oh I
> forgeth whining is easy, doing something useful requires real work.
Absolutely. Whining here has been a wonderful way for me to avoid
doing productive, useful, real work.
I am getting close to the point, though, where I'm almost feeling
guilty enough to try doing something useful.
Almost.
-jimbo
On 2007-07-11 21:50:19 -0400, ········@gmail.com said:
> Why not do the few remaining little things that close
> the gap where other languages have a productivity edge over Lisp?
There is a market for these few remaining little things. It is being
served by the commercial implementations. What you are lamenting is the
fact that the free lisps do not have the ease of use of the commercial
offerings, but this is only a problem for those who refuse to pay for
more usable tools.
On Jul 12, 7:07 am, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-11 21:50:19 -0400, ········@gmail.com said:
>
> > Why not do the few remaining little things that close
> > the gap where other languages have a productivity edge over Lisp?
>
> There is a market for these few remaining little things. It is being
> served by the commercial implementations. What you are lamenting is the
> fact that the free lisps do not have the ease of use of the commercial
> offerings, but this is only a problem for those who refuse to pay for
> more usable tools.
Maybe something like Microsoft empower https://partner.microsoft.com/40011351
could help. I'm not trying to teach Franz how to do their business,
far from that, but we have a quite simigliar situation, high quality
but high priced product and a lot of companies who have problems
stepping through the threshold of going for my product.
Raffael Cavallaro escreveu:
> On 2007-07-11 21:50:19 -0400, ········@gmail.com said:
>
>> Why not do the few remaining little things that close
>> the gap where other languages have a productivity edge over Lisp?
>
> There is a market for these few remaining little things. It is being
> served by the commercial implementations. What you are lamenting is the
> fact that the free lisps do not have the ease of use of the commercial
> offerings, but this is only a problem for those who refuse to pay for
> more usable tools.
>
Humm. . . no!
It is a (non) problem to those that make the decisions (do not) to pay
for tools which in the average give the same results as the less
expensive ones.
On 2007-07-15 22:25:32 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> It is a (non) problem to those that make the decisions (do not) to pay
> for tools which in the average give the same results as the less
> expensive ones.
And yet commercial lisps continue to sell licenses, so either all
commercial lisp customers are fools, or (more likely) commercial common
lisps provide usability and productivity tools not available with free
offerings.
Raffael Cavallaro escreveu:
> On 2007-07-15 22:25:32 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
>> It is a (non) problem to those that make the decisions (do not) to pay
>> for tools which in the average give the same results as the less
>> expensive ones.
>
> And yet commercial lisps continue to sell licenses, so either all
> commercial lisp customers are fools, or (more likely) commercial common
> lisps provide usability and productivity tools not available with free
> offerings.
>
I don't have the statistics on the recent sales of commercial lisp
licenses, so I cannot comment on the likelihood you pose.
My opinion, though, from the facts I have acess to is that most of the
'usability' and 'productivity' does not show in the patrons bottom lines
and due this the sales of Lisp technology does not grow.
Or said in other words the features commercial lisp offers is available
in other technologies, otherwise lisp would have taken the language market.
On Jul 17, 5:32 am, Cesar Rabak <·······@yahoo.com.br> wrote:
> Raffael Cavallaro escreveu:> On 2007-07-15 22:25:32 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
> >> It is a (non) problem to those that make the decisions (do not) to pay
> >> for tools which in the average give the same results as the less
> >> expensive ones.
>
> > And yet commercial lisps continue to sell licenses, so either all
> > commercial lisp customers are fools, or (more likely) commercial common
> > lisps provide usability and productivity tools not available with free
> > offerings.
>
> I don't have the statistics on the recent sales of commercial lisp
> licenses, so I cannot comment on the likelihood you pose.
>
> My opinion, though, from the facts I have acess to is that most of the
> 'usability' and 'productivity' does not show in the patrons bottom lines
> and due this the sales of Lisp technology does not grow.
>
You're statement sounds quite confusingto me , maybe because English
is not my native langauge, please explain what do you want to say.
> Or said in other words the features commercial lisp offers is available
> in other technologies, otherwise lisp would have taken the language market.
I wish it was that simple.
Slobodan Blazeski escreveu:
> On Jul 17, 5:32 am, Cesar Rabak <·······@yahoo.com.br> wrote:
[snipped]
> You're statement sounds quite confusingto me , maybe because English
> is not my native langauge, please explain what do you want to say.
>
>> Or said in other words the features commercial lisp offers is available
>> in other technologies, otherwise lisp would have taken the language market.
Above is more explicit, I hope.
>
> I wish it was that simple.
>
Well, you touched the sore tooth now! For us more techies, we may see a
'non simple' matter. From a business point of view, it has to come
_that_ simple, even if with the help of a hammer.
I still trying hard to use Lisp in projects I participate, but it is
becoming harder to show any _real_ difference when you factor in all the
aspects of application development.
Regards,
--
Cesar Rabak
On 2007-07-16 23:32:29 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> Or said in other words the features commercial lisp offers is available
> in other technologies, otherwise lisp would have taken the language
> market.
1. The features commercial lisps offer are *not* available in free lisps.
2. The features common lisp offers are not available in other
technologies - notably the *combination* of these: a mature,
standardized, language with easy to use facilities for metaprogramming
(due to code = data), a powerful, standardized object system with MI,
generic functions, and a MOP, supported commercial implementations that
allow delivery of platform native binaries and double-clickable GUI
apps for Win, Mac and Linux.
Raffael Cavallaro escreveu:
> On 2007-07-16 23:32:29 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
>> Or said in other words the features commercial lisp offers is
>> available in other technologies, otherwise lisp would have taken the
>> language market.
>
> 1. The features commercial lisps offer are *not* available in free lisps.
>
OK, my comment was on the (perceived by the persons who are to patron)
ROI for the additional cost.
> 2. The features common lisp offers are not available in other
> technologies - notably the *combination* of these: a mature,
> standardized, language with easy to use facilities for metaprogramming
> (due to code = data), a powerful, standardized object system with MI,
> generic functions, and a MOP, supported commercial implementations that
> allow delivery of platform native binaries and double-clickable GUI apps
> for Win, Mac and Linux.
I agree with description and not disputing these aspects. What I surmise
is that this *combination* is not in so need in the market to the point
it be so unnoticed by the large community of developers.
Getting back on my comment to poster who mentioned the (blog) article, I
maintain the features above are not cure for the illness described in
the article.
--
Cesar Rabak
On Jul 18, 11:59 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> Raffael Cavallaro escreveu:
>
> > On 2007-07-16 23:32:29 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
> >> Or said in other words the features commercial lisp offers is
> >> available in other technologies, otherwise lisp would have taken the
> >> language market.
>
> > 1. The features commercial lisps offer are *not* available in free lisps.
>
> OK, my comment was on the (perceived by the persons who are to patron)
> ROI for the additional cost.
I don't know where you happen to work but with my experience with my
employers paying few thousands for an implementation was not a proble,
don't forgeth that I live in Macedonia a country with average salary
of ~200 euros, they have a problem using that esoteric language called
lisp. Second most of the companies I know don't want to use OpenSource
tools at all. They want a vendor. YMMV
> > 2. The features common lisp offers are not available in other
> > technologies - notably the *combination* of these: a mature,
> > standardized, language with easy to use facilities for metaprogramming
> > (due to code = data), a powerful, standardized object system with MI,
> > generic functions, and a MOP, supported commercial implementations that
> > allow delivery of platform native binaries and double-clickable GUI apps
> > for Win, Mac and Linux.
>
> I agree with description and not disputing these aspects. What I surmise
> is that this *combination* is not in so need in the market to the point
> it be so unnoticed by the large community of developers.
>
> Getting back on my comment to poster who mentioned the (blog) article, I
> maintain the features above are not cure for the illness described in
> the article.
>
> --
> Cesar Rabak
Slobodan Blazeski escreveu:
> On Jul 18, 11:59 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
>> Raffael Cavallaro escreveu:
>>
>>> On 2007-07-16 23:32:29 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>>>> Or said in other words the features commercial lisp offers is
>>>> available in other technologies, otherwise lisp would have taken the
>>>> language market.
>>> 1. The features commercial lisps offer are *not* available in free lisps.
>> OK, my comment was on the (perceived by the persons who are to patron)
>> ROI for the additional cost.
>
> I don't know where you happen to work but with my experience with my
> employers paying few thousands for an implementation was not a proble,
> don't forgeth that I live in Macedonia a country with average salary
> of ~200 euros, they have a problem using that esoteric language called
> lisp.
I can grok the individual periods, but not the idea of this phrase. What
you say is that paying money (high in relation to wages) is not a
problem, _except_ when connected to an esoteric language (one of them
being Lisp)?
This is near to what I'm saying: "the perceived ROI..."
> Second most of the companies I know don't want to use OpenSource
> tools at all. They want a vendor. YMMV
>
Yes, here the mileage varies very much!
On Jul 23, 1:21 am, Cesar Rabak <·······@yahoo.com.br> wrote:
> Slobodan Blazeski escreveu:
>
>
>
> > On Jul 18, 11:59 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> >> Raffael Cavallaro escreveu:
>
> >>> On 2007-07-16 23:32:29 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> >>>> Or said in other words the features commercial lisp offers is
> >>>> available in other technologies, otherwise lisp would have taken the
> >>>> language market.
> >>> 1. The features commercial lisps offer are *not* available in free lisps.
> >> OK, my comment was on the (perceived by the persons who are to patron)
> >> ROI for the additional cost.
>
> > I don't know where you happen to work but with my experience with my
> > employers paying few thousands for an implementation was not a proble,
> > don't forgeth that I live in Macedonia a country with average salary
> > of ~200 euros, they have a problem using that esoteric language called
> > lisp.
>
> I can grok the individual periods, but not the idea of this phrase. What
> you say is that paying money (high in relation to wages) is not a
> problem, _except_ when connected to an esoteric language (one of them
> being Lisp)?
In my country average programmer wage is something around 400 euro,
(don't hold me for it I don't make a full scale statistic). LW &
scieneer are starting from 1200 / 1500 euros. Any self-respecting
company would not have a problem buying a license if they feel that
their business need it. The problem is to convince that they need lisp
to help them run their business.
> This is near to what I'm saying: "the perceived ROI..."
>
> > Second most of the companies I know don't want to use OpenSource
> > tools at all. They want a vendor. YMMV
>
> Yes, here the mileage varies very much!
Don't get me wrong we have a lot of LAMP (p stands for PHP) shops,
also there is shops using FreeBSD & Java but I never heard of anybody
using python nor ruby.
Slobodan Blazeski escreveu:
> On Jul 23, 1:21 am, Cesar Rabak <·······@yahoo.com.br> wrote:
>> Slobodan Blazeski escreveu:
>>
>>
>>
>>> On Jul 18, 11:59 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
>>>> Raffael Cavallaro escreveu:
>>>>> On 2007-07-16 23:32:29 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>>>>>> Or said in other words the features commercial lisp offers is
>>>>>> available in other technologies, otherwise lisp would have taken the
>>>>>> language market.
>>>>> 1. The features commercial lisps offer are *not* available in free lisps.
>>>> OK, my comment was on the (perceived by the persons who are to patron)
>>>> ROI for the additional cost.
>>> I don't know where you happen to work but with my experience with my
>>> employers paying few thousands for an implementation was not a proble,
>>> don't forgeth that I live in Macedonia a country with average salary
>>> of ~200 euros, they have a problem using that esoteric language called
>>> lisp.
>> I can grok the individual periods, but not the idea of this phrase. What
>> you say is that paying money (high in relation to wages) is not a
>> problem, _except_ when connected to an esoteric language (one of them
>> being Lisp)?
>
> In my country average programmer wage is something around 400 euro,
> (don't hold me for it I don't make a full scale statistic). LW &
> scieneer are starting from 1200 / 1500 euros. Any self-respecting
> company would not have a problem buying a license if they feel that
> their business need it. The problem is to convince that they need lisp
> to help them run their business.
OK. Same problem here (in fact I'm finishing an assessment on this to
send Clive about this sad state of affairs. . .
>
>> This is near to what I'm saying: "the perceived ROI..."
>>
>>> Second most of the companies I know don't want to use OpenSource
>>> tools at all. They want a vendor. YMMV
>> Yes, here the mileage varies very much!
> Don't get me wrong we have a lot of LAMP (p stands for PHP) shops,
> also there is shops using FreeBSD & Java but I never heard of anybody
> using python nor ruby.
>
Here you'll find for the P: Perl (older but still employed), PHP,
Python. More recently I saw an increase on Ruby use, specially due the
widespread of eXtreme Programming teams using them.
On Jul 23, 11:39 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> Slobodan Blazeski escreveu:
>
>
>
>
>
> > On Jul 23, 1:21 am, Cesar Rabak <·······@yahoo.com.br> wrote:
> >> Slobodan Blazeski escreveu:
>
> >>> On Jul 18, 11:59 pm, Cesar Rabak <·······@yahoo.com.br> wrote:
> >>>> Raffael Cavallaro escreveu:
> >>>>> On 2007-07-16 23:32:29 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> >>>>>> Or said in other words the features commercial lisp offers is
> >>>>>> available in other technologies, otherwise lisp would have taken the
> >>>>>> language market.
> >>>>> 1. The features commercial lisps offer are *not* available in free lisps.
> >>>> OK, my comment was on the (perceived by the persons who are to patron)
> >>>> ROI for the additional cost.
> >>> I don't know where you happen to work but with my experience with my
> >>> employers paying few thousands for an implementation was not a proble,
> >>> don't forgeth that I live in Macedonia a country with average salary
> >>> of ~200 euros, they have a problem using that esoteric language called
> >>> lisp.
> >> I can grok the individual periods, but not the idea of this phrase. What
> >> you say is that paying money (high in relation to wages) is not a
> >> problem, _except_ when connected to an esoteric language (one of them
> >> being Lisp)?
>
> > In my country average programmer wage is something around 400 euro,
> > (don't hold me for it I don't make a full scale statistic). LW &
> > scieneer are starting from 1200 / 1500 euros. Any self-respecting
> > company would not have a problem buying a license if they feel that
> > their business need it. The problem is to convince that they need lisp
> > to help them run their business.
>
> OK. Same problem here (in fact I'm finishing an assessment on this to
> send Clive about this sad state of affairs. . .
>
>
>
> >> This is near to what I'm saying: "the perceived ROI..."
>
> >>> Second most of the companies I know don't want to use OpenSource
> >>> tools at all. They want a vendor. YMMV
> >> Yes, here the mileage varies very much!
> > Don't get me wrong we have a lot of LAMP (p stands for PHP) shops,
> > also there is shops using FreeBSD & Java but I never heard of anybody
> > using python nor ruby.
>
> Here you'll find for the P: Perl (older but still employed), PHP,
> Python. More recently I saw an increase on Ruby use, specially due the
> widespread of eXtreme Programming teams using them.- Hide quoted text -
>
> - Show quoted text -
Yeah we got Perl too I just forgoth them.
On 2007-07-22 19:21:18 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> This is near to what I'm saying: "the perceived ROI..."
My point is that the *perceived* ROI is wrong.
Raffael Cavallaro escreveu:
> On 2007-07-22 19:21:18 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
>> This is near to what I'm saying: "the perceived ROI..."
>
> My point is that the *perceived* ROI is wrong.
>
In order we can start to solve it, we first have to accept this
perception. In Quality we have a saying: "Perception _is_ reality."
After we accept it, we can start a plan to communicate and correct the
perception.
Otherwise we will stay here bragging about the 'superiority' of
something no one else sees!
What a paradox, don't you agree!?
On 2007-07-23 17:34:59 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> In order we can start to solve it, we first have to accept this
> perception. In Quality we have a saying: "Perception _is_ reality."
>
> After we accept it, we can start a plan to communicate and correct the
> perception.
Only if you think it is a realistic goal to change mass perception via
rational argument. History suggests otherwise.
>
> Otherwise we will stay here bragging about the 'superiority' of
> something no one else sees!
Or you can just choose the superior alternative for your own projects
and not worry so much that there is a common misperception about what
you are using. Some would see this as a kind of secret weapon.
>
> What a paradox, don't you agree!?
Again, it's only a paradox if your goal is to correct the
misperceptions of masses of others via logical suasion. I gave up
tilting that windmill long ago. Therefore I am not required to accept
that this mistaken "perception _is_ reality." I simply see it for the
error that is is.
Raffael Cavallaro escreveu:
> On 2007-07-23 17:34:59 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
>> In order we can start to solve it, we first have to accept this
>> perception. In Quality we have a saying: "Perception _is_ reality."
>>
>> After we accept it, we can start a plan to communicate and correct the
>> perception.
>
> Only if you think it is a realistic goal to change mass perception via
> rational argument. History suggests otherwise.
>
Where in my words did I say I want use rational arguments _only_?
Again, as we seem to agree on the diagnostic, perhaps we can start to
think in ways to solve the problem.
I surmise some marketing techniques would be part of the recipe...
>
>>
>> Otherwise we will stay here bragging about the 'superiority' of
>> something no one else sees!
>
> Or you can just choose the superior alternative for your own projects
> and not worry so much that there is a common misperception about what
> you are using. Some would see this as a kind of secret weapon.
>
Well it is another half truth: most of the big money is on contracts
where the project is not 'yours' but rather is a solution that involves
HW and SW infrastructure, an aproved approach, etc. There is no room to
'secret weapons' only to accepted technologies.
>
>>
>> What a paradox, don't you agree!?
>
> Again, it's only a paradox if your goal is to correct the misperceptions
> of masses of others via logical suasion. I gave up tilting that windmill
> long ago. Therefore I am not required to accept that this mistaken
> "perception _is_ reality." I simply see it for the error that is is.
>
Yes. I also not willing to be burned in a fire saying the Earth revolves
around the Sun, _but_ if the ship's captain thinks Earth is flat, then I
fight!
Regards,
--
Cesar Rabak
On 2007-07-24 13:46:31 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> Where in my words did I say I want use rational arguments _only_?
Why would one want to add to the lisp user community programmers who
are not susceptible to rational argument, but only irrational suasion?
On Jul 25, 8:09 am, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-24 13:46:31 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
> > Where in my words did I say I want use rational arguments _only_?
>
> Why would one want to add to the lisp user community programmers who
> are not susceptible to rational argument, but only irrational suasion?
The effort to persuade with rational arguments may exceed the effort
to persuade with irrational ones.
More important - humans are susceptible to irrational arguments. If
you don't want to add humans to the lisp community, who are you
planning to get?
On 2007-07-25 12:24:13 -0400, Andy Freeman <······@earthlink.net> said:
> More important - humans are susceptible to irrational arguments.
not uniquely.
> If
> you don't want to add humans to the lisp community, who are you
> planning to get?
People who choose lisp for rational reasons, not slick advertising or
internet fads.
On Jul 25, 12:55 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-25 12:24:13 -0400, Andy Freeman <······@earthlink.net> said:
> > If
> > you don't want to add humans to the lisp community, who are you
> > planning to get?
>
> People who choose lisp for rational reasons, not slick advertising or
> internet fads.
In other words, you're happy with a lisp community that can fit in a
phone booth.
I'd like to add (among others) folks who'd like to program with sex
expressions.
On 2007-07-25 17:16:00 -0400, Andy Freeman <······@earthlink.net> said:
> In other words, you're happy with a lisp community that can fit in a
> phone booth.
The last time lisp was 'sold' based on inflated expectations - 'human
level AI real soon now' - it nearly killed the language outright. The
community of programmers who will choose a language based on what has
actually been accomplished rather than hype is clearly far larger than
your silly phone booth quip.
It isn't as large as the giant herds of code monkeys who migrate from
C++ to Java to Python to Ruby, etc., but you can never hold these
people's intereset for long anyway. They will always be off in search
of the latest hype after a few months/years. They are in constant
search of something external that they desperately hope will fix a
problem that they dimly (and sadly, correctly) suspect is internal -
they simply don't have a very good understanding of what they are doing.
On Jul 25, 10:44 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-25 17:16:00 -0400, Andy Freeman <······@earthlink.net> said:
>
> > In other words, you're happy with a lisp community that can fit in a
> > phone booth.
>
> The last time lisp was 'sold' based on inflated expectations - 'human
> level AI real soon now' - it nearly killed the language outright.
There's an important difference between overly inflated expectations
and puffery.
Folks who don't understand the difference end up completely
marginalized, no matter how wonderful what they're selling is.
And yes, "selling" is the right word. If you're not selling
effectively, you're losing.
BTW - One important part of selling effectively is respecting other
people. Even if you don't want specific ones as customers, you don't
want them to be actively hostile because they're places you're not, so
you can't fix any of their sabotage.
On 2007-07-26 13:08:12 -0400, Andy Freeman <······@earthlink.net> said:
> There's an important difference between overly inflated expectations
> and puffery.
Which is which? Honestly, they both sound bad to me.
>
> Folks who don't understand the difference end up completely
> marginalized, no matter how wonderful what they're selling is.
Since you've made the difference as clear as mud it's difficult to know
what you think gets something "completely marginalized."
Simply stating the truth about something isn't 'selling' it, though it
may attract users/buyers if you do so. There is a class of people who
think that everything can by forced into the procrustean bed of their
own worldview - political scientists think everything reduces to
politics, MBAs think everything reduces to 'selling' and so on. The
merits of a programming language can be laid out by simply showing
what's been done with it and how much manpower it took to do it. If
those facts 'sell' potential users then great. But doing so is no more
'selling' than going jogging is 'selling' exercise. Simply stating the
facts is neither 'inflated expectations' or 'puffery' (whatever you
take that to mean).
On Jul 26, 9:39 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-26 13:08:12 -0400, Andy Freeman <······@earthlink.net> said:
>
> > There's an important difference between overly inflated expectations
> > and puffery.
>
> Which is which? Honestly, they both sound bad to me.
And that's why Cavallaro can't sell lisp.
For some, the line between puffery and overly inflated expectations is
somewhere between a bikini and implants.
You can ignore how people work, but don't expect be successful if you
do. In fact, you're just going to ensure that the things that you're
doing correctly will be ignored.
> Simply stating the truth about something isn't 'selling' it,
Bingo. Selling telling truths that that matter. It's story-telling.
See "Made to Stick". ( http://www.amazon.com/Made-Stick-Ideas-Survive-Others/dp/1400064287
). Note that idea quality isn't enough.
-andy
On Jul 25, 9:55 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-25 12:24:13 -0400, Andy Freeman <······@earthlink.net> said:
>
> > More important - humans are susceptible to irrational arguments.
>
> not uniquely.
>
> > If
> > you don't want to add humans to the lisp community, who are you
> > planning to get?
>
> People who choose lisp for rational reasons, not slick advertising or
> internet fads.
What were your reasons for choosing lisp ?
Here's my thoughts about choosing lisp:
Somebody in a gamedev forum suggested that you need lisp or prolog to
do ai so I got curious why do you need a special language to do
something. I decided to try one of those and looked which one has :
1. Active community - dead languages are hm dead.
2. Literature - the more the better especially the one to get you
started
3. Up to date Vendors & Open source implementations- influences the
quality of the implementation
4. David lamkins saying : Most programming languages are more similar
to each other than they are to Lisp. This one is probably irrational
but i always liked the road less traveled.
5. Orthogonality - few days to learn , lifetime to master.
Later I found Paul Graham esseys but I was already hooked to lisp.
On 2007-07-26 03:26:06 -0400, Slobodan Blazeski
<·················@gmail.com> said:
> What were your reasons for choosing lisp ?
Actual experiences using it after having used (in approximate
chronological order)
opcodes for some 8 bit handheld monstrosity
cobol
snobol
basic
apl
pl1
c
forth
pascal
hypertalk
c++
scheme
smalltalk
dylan
After first using lisp I also tried/used the following, none of which I
preferred to lisp:
java
perl
python
objective-c
ocaml
ruby
haskell
erlang
I may be leaving a few out (scripting languages for various software
packages, etc.) but for me, to this day nothing is as convenient as
common lisp (though I've always thought scheme, forth smalltalk and
dylan were pretty nice languages as well).
If put to it, it would choose next after common lisp in this order:
scheme (obviously)
smalltalk
objective-c (because of it's huge library and soon-to-be gc)
ruby
python
dylan (only this low down because no IDE is available on Mac OS X - one
of the principal attractions of the original Apple implementation was
the really nice integration of the language and slick IDE).
I suppose I would hold my nose and even use java or perl if they were
the only real option.
I think I'd probably give up programming if I could only use a
statically typed language like ocaml or haskell - or I'd just implement
a toy dynamic language on top of one of these and use that instead.
Andy Freeman <······@earthlink.net> writes:
> The effort to persuade with rational arguments may exceed the effort
> to persuade with irrational ones.
>
> More important - humans are susceptible to irrational arguments. If
> you don't want to add humans to the lisp community, who are you
> planning to get?
AIs! ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
Raffael Cavallaro escreveu:
> On 2007-07-24 13:46:31 -0400, Cesar Rabak <·······@yahoo.com.br> said:
>
>> Where in my words did I say I want use rational arguments _only_?
>
> Why would one want to add to the lisp user community programmers who are
> not susceptible to rational argument, but only irrational suasion?
>
I'm affraid you did not understand what side I'm trying to be the
attorney of!
I'm writing about the non Lisp user community, which I see divided in
two groups:
1) Programmers (here understood as the whole 'food chain') that shy away
as viable tecnology;
2) Application (a.k.a. business) users.
For the second, have you read about an Airline that wrote off 30 million
US dollars for a brand new reservation system, which was supposed to be
"more flexible using J2EE, Linux and Web services"?
On 2007-07-25 14:53:02 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> 2) Application (a.k.a. business) users.
>
> For the second, have you read about an Airline that wrote off 30
> million US dollars for a brand new reservation system, which was
> supposed to be "more flexible using J2EE, Linux and Web services"?
Selling lisp to this second group is an excercise in marketing (or
social constructionism, or some other intersection of psychology,
sociology and anthropology) not in lisp itself. If you want to do a dog
and pony show for these people go right ahead. But your desire to sell
these people on lisp in no way requires me to adopt their broken
worldview that lisp is 'outmoded' or 'inferior' technology.
On Jul 25, 12:59 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-25 14:53:02 -0400, Cesar Rabak <·······@yahoo.com.br> said:
> > 2) Application (a.k.a. business) users.
>
> Selling lisp to this second group is an excercise in marketing (or
> social constructionism, or some other intersection of psychology,
> sociology and anthropology) not in lisp itself. If you want to do a dog
> and pony show for these people go right ahead. But your desire to sell
> these people on lisp in no way requires me to adopt their broken
> worldview that lisp is 'outmoded' or 'inferior' technology.
Huh? Who said anything about trying to sell them on lisp as
'outmoded' or 'inferior'?
BTW - No language is sold to anyone as "itself". They're all sold as
"use this language and good things will happen".
On 2007-07-25 17:22:09 -0400, Andy Freeman <······@earthlink.net> said:
> Huh? Who said anything about trying to sell them on lisp as
> 'outmoded' or 'inferior'?
You haven't been following the thread very carefully - Cesar said that
we have to 'accept' the common misconception that lisp is inferior
because "perception _is_ reality" before the 'problem' can be solved.
On 2007-07-25 17:22:09 -0400, Andy Freeman <······@earthlink.net> said:
> BTW - No language is sold to anyone as "itself". They're all sold as
> "use this language and good things will happen".
When the "good things" are actual accomplishments and features of the
language then yes, it is being sold as itself.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>
writes:
>
> Why would one want to add to the lisp user community programmers who are
> not susceptible to rational argument, but only irrational suasion?
Well, for one--that adequately describes every human being. Even you &
I.
I'm reminded of two beer tastings I went to in college. The first
brewery sold amazing beer--really quite amazing. The owner/brewmaster
(in his sixties) came to our local pub and gave a lecture on the beer he
made. Everything he said was accurate; it was even, to a beer geek,
interesting. But it didn't win the attention of the crowd, and his
demeanour was a bit peevish.
The second brewery sent in a young marketing fellow. He had very, very
little of information to give about his beer (right about on the level
of 'beer's made with barley and hops--who'd have thunk it?'). But he
had some 'fun facts,' he handed out pint glasses and t-shirts (I still
have the pint glass I won for answering a question properly); he won the
crowd's attention and their affection.
Today, Yellow Rose Brewery is closed; Pyramid Brewery is going
gangbusters. It's all about appealing to people with both facts and
emotions.
A beautiful chair and an ugly chair both support my rear end just fine,
but I'd prefer the lovely one.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Though intelligence is powerless to modify character, it is a dab hand at
finding euphemisms for its weaknesses. --Quentin Crisp
On 2007-07-30 10:48:16 -0400, Robert Uhl <·········@NOSPAMgmail.com> said:
> Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>
> writes:
>>
>> Why would one want to add to the lisp user community programmers who are
>> not susceptible to rational argument, but only irrational suasion?
>
> Well, for one--that adequately describes every human being. Even you &
> I.
Just to be clear, do you really contend that *all* people are
susceptible *only* to irrational argument? You may care to rethink that
- I think you're confusing categories.
My point was *not* that we only want people who are *only* susceptible
to rational argument.
My point is that we don't want people who are *only* susceptible to
irrational argument.
This being the case, we make the rational case and let those who are at
least somewhat rational see what we have to offer. We don't make the
irrational case, and draw all the lemmings who are *only* susceptible
to irrational suasion.
On Jul 30, 8:21 am, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> My point is that we don't want people who are *only* susceptible to
> irrational argument.
That's nice, but isn't actually what's going on.
Cavallaro wants to exclude people from the lisp community. Fair
enough. However, his methods for doing so will basically create a
lisp community that fits in a phone booth.
NOTHING is sold on a purely rational basis. Why? Because things that
are sold on a purely rational basis are bought by so few people that
they disappear.
Cavallaro may disagree. Perhaps he'll start by listing three things
that are sold on a purely rational basis. (Not even pure math
qualifies.)
Or, maybe he'll tell us why Lisp can be the exception to this rule.
On 2007-07-30 11:46:47 -0400, Andy Freeman <······@earthlink.net> said:
> Cavallaro wants to exclude people from the lisp community. Fair
> enough. However, his methods for doing so will basically create a
> lisp community that fits in a phone booth.
I don't want to *exclude* them, I just don't want to run after them.
> NOTHING is sold on a purely rational basis.
Again, you're confusing two different things - not wanting
*predominantly* irrational people (my position), with wanting *pure*
rationality (*not* my position).
I'm against selling *purely* (or even mostly) on the basis of hype, and
in favor of selling principally (or to whatever extent is reasonably
possible) on the basis of reality. This will naturally tend to attact
fewer hype-oriented lemmings who I don't wish to 'exclude' but neither
wish to actively court.
You see some inherent virtue in having a large user community composed
mostly of largely irrational people who will bolt at the next fad. This
is just begging for another list winter.
On 2007-07-31 02:25:05 -0400, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> said:
> This is just begging for another list winter.
should be 'lisp' of course - (mumble mumble, ... 2:30 am)
On Jul 30, 11:25 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-30 11:46:47 -0400, Andy Freeman <······@earthlink.net> said:
> > Cavallaro wants to exclude people from the lisp community. Fair
> > enough. However, his methods for doing so will basically create a
> > lisp community that fits in a phone booth.
>
> I don't want to *exclude* them, I just don't want to run after them.
>
> > NOTHING is sold on a purely rational basis.
>
> Again, you're confusing two different things - not wanting
> *predominantly* irrational people (my position),
The problem with that ideal is that rationality is the exception. No
one is predominantly rational most of the time on more than a few
things.
> You see some inherent virtue in having a large user community composed
> mostly of largely irrational people who will bolt at the next fad.
Oh really? How about some actual evidence for the above claim?
Rational evidence will be composed of things that I've actually
written.
We're about to get a demonstration of "what they hear is far more
important than what you say". FWIW, rational people hear what is
said.
My actual position is that I see inherent virtue in having a large
community over a long period of time. Churn is bad, as are wide
oscillations, but a persistently small community is worse. I don't
see any large communities whose fundamental appeal is mostly
rational. If Lisp is to be the exception, I'd like to see the
argument.
I don't have a rational basis for preferring to have a large lisp
community. (I'll bet that my reasons are not unlike Cavallaro's, but
I'll let him post his before I point out the irrationality.)
On 2007-07-31 11:18:47 -0400, Andy Freeman <······@earthlink.net> said:
> The problem with that ideal is that rationality is the exception. No
> one is predominantly rational most of the time on more than a few
> things.
I'm just saying that choice of programming language should be one of
those things.
>
>> You see some inherent virtue in having a large user community composed
>> mostly of largely irrational people who will bolt at the next fad.
>
> Oh really? How about some actual evidence for the above claim?
> Rational evidence will be composed of things that I've actually
> written.
Sure:
On 2007-07-26 13:08:12 -0400, Andy Freeman <······@earthlink.net> said:
> And yes, "selling" is the right word. If you're not selling
> effectively, you're losing.
On 2007-07-30 11:46:47 -0400, Andy Freeman <······@earthlink.net> said:
> NOTHING is sold on a purely rational basis.
> On 2007-07-25 17:22:09 -0400, Andy Freeman <······@earthlink.net> said:
> BTW - No language is sold to anyone as "itself". They're all sold as
> "use this language and good things will happen".
>
So we can conclude that you think that lisp needs to be sold, and it
needs to be sold *not* on a rational basis. For confirmation of this we
have this statement.
On 2007-07-25 17:16:00 -0400, Andy Freeman <······@earthlink.net> said:
> I'd like to add (among others) folks who'd like to program with sex
> expressions.
A group who will have clearly chosen lisp for largely irrational
reasons, precisely the type to bolt at the next fad.
But you don't care about that because:
On 2007-07-31 11:18:47 -0400, Andy Freeman <······@earthlink.net> said:
> My actual position is that I see inherent virtue in having a large
> community over a long period of time. Churn is bad, as are wide
> oscillations, but a persistently small community is worse.
So you would rather see large numbers of lemmings choose lisp and bolt
at the next fad while I would rather see a small community of users who
have chosen lisp principally for rational reasons.
On Aug 1, 6:54 am, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-07-31 11:18:47 -0400, Andy Freeman <······@earthlink.net> said:
>
> > The problem with that ideal is that rationality is the exception. No
> > one is predominantly rational most of the time on more than a few
> > things.
>
> I'm just saying that choice of programming language should be one of
> those things.
Perhaps Cavallaro can point to a reasonably popular programming
language which is mostly sold on a rational basis. Heck - I'll settle
for one whose users mostly picked it for rational reasons. Failing
that, how about explaining how lisp can be the exception to that
rule? The phrase "reasonably popular" is important.
> >> You see some inherent virtue in having a large user community composed
> >> mostly of largely irrational people who will bolt at the next fad.
>
> > Oh really? How about some actual evidence for the above claim?
> > Rational evidence will be composed of things that I've actually
> > written.
Note the word "mostly". Then there's also the term "will bolt at the
next fad".
I don't much care why folks program in lisp. I just want them to do
so now and for the forseeable future.
Cavallaro seems to want only folks who program in lisp for reasons
that he finds acceptable.
Which approach is likely to result in a lisp community that doesn't
die off?
> So we can conclude that you think that lisp needs to be sold,
As does Cavallaro - we're just arguing about HOW to sell it, even if
he thinks that selling is beneath him.
> needs to be sold *not* on a rational basis.
Actually, I pointed out that nothing gets popular for rational
reasons. Cavallaro is free to disagree, argue that Lisp can be
different, or admit that he'd rather that lisp be unpopular than sell
it with "bad" reasons. If he believes that there is some other
alternative, let's see it. Right now, it looks like he's going with
"unpopular".
> > My actual position is that I see inherent virtue in having a large
> > community over a long period of time. Churn is bad, as are wide
> > oscillations, but a persistently small community is worse.
>
> So you would rather see large numbers of lemmings choose lisp and bolt
> at the next fad while I would rather see a small community of users who
> have chosen lisp principally for rational reasons.
Since I explicitly wrote that churn and wide oscillations are bad,
it's "curious" that Cavallaro thinks that I'd rather see those things.
I've ranked the three alternatives. I assume that Cavallaro agrees
with my top choice, so let's compare the next two.
A temporarily large community will leave behind things that a small
community can't produce on its own, useful things like books,
compilers, tools, libraries, etc, that folks will produce for a large
community but not for a small one. A persistently large community
will produce more of such things, but I don't see the virtue in having
none of those things, which is Cavallaro's preference.
Cavallaro may think that bolting lemmings somehow exclude the "small
community of users". Surely he's not going to argue that such
rational people are going to avoid/abandon lisp because other people
picked it for irrational reasons and then wandered off.
Andy Freeman wrote:
> Perhaps Cavallaro can point to a reasonably popular programming
> language which is mostly sold on a rational basis.
Perhaps that would be pointless.
> The phrase "reasonably popular" is important.
Only for wasting time and money on buggy, poorly designed code
written by mediocre programmers.
> I don't much care why folks program in lisp. I just
> want them to do so now and for the forseeable future.
I only want programmers to use Lisp if they can work effectively with
its features. Many programmers would just hurt themselves with Lisp.
> Cavallaro seems to want only folks who program in lisp for reasons
> that he finds acceptable.
As do you, except you seem to consider shallow salesmanship acceptable.
> Which approach is likely to result in a lisp community that doesn't
> die off?
The approach that excludes unreliable "script kiddies".
> If he believes that there is some other alternative, let's see it.
The alternative is the marketplace. Companies are already thriving
or going under depending in part on the quality of their programmers
and the languages they use.
> Right now, it looks like he's going with "unpopular".
Lisp is very popular with smart, agressive hackers. These are
the people who reliably write good code.
>> So you would rather see large numbers of lemmings choose lisp
>> and bolt at the next fad while I would rather see a small community
>> of users who have chosen lisp principally for rational reasons.
>
> Since I explicitly wrote that churn and wide oscillations are bad,
> it's "curious" that Cavallaro thinks that I'd rather see those things.
Not at all. Raphael's position is that a large community is possible
only by luring in naive, fad-driven "lemmings", and these individuals
are inherently destabilizing.
> A temporarily large community will leave behind
a trail of destruction.
> A persistently large community will produce more of such things,
> but I don't see the virtue in having none of those things,
> which is Cavallaro's preference.
The virtue is that it's currently, practically feasible, and that it's
an exaggeration. I'll take one Edi Weitz over a thousand lemmings
any day.
> Cavallaro may think that bolting lemmings somehow exclude the "small
> community of users". Surely he's not going to argue that such
> rational people are going to avoid/abandon lisp because other people
> picked it for irrational reasons and then wandered off.
Why not? Bad programmers can have a real, adverse effect on
commercial projects by influencing design, implementation, and
even managerial decisions.
--
Dan
www.prairienet.org/~dsb/
On 2007-08-01 14:31:22 -0400, Andy Freeman <······@earthlink.net> said:
> Since I explicitly wrote that churn and wide oscillations are bad,
> it's "curious" that Cavallaro thinks that I'd rather see those things.
1. Stop referring to me in the third person, it's condescending and
rude. I address you directly. Please have the courtesy to do likewise.
2. You specifically wrote that you'd rather see churn than a small community:
On 2007-07-31 11:18:47 -0400, Andy Freeman <······@earthlink.net> said:
> Churn is bad, as are wide
> oscillations, but a persistently small community is worse.
You can't have it both ways. Either churn is worse than a small
community or a small community is worse than churn. I think churn is
worse since the boom and bust hurts commercial implementors.
If you think that churn is not just bad, but *worse* than "a
persistently small community" then you agree with me, and your quote
above is *not* what you mean.
If you think that "a persistently small community" is worse than churn,
as you wrote, then own up to it.
On Aug 1, 1:38 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com> wrote:
> On 2007-08-01 14:31:22 -0400, Andy Freeman <······@earthlink.net> said:
>
> > Since I explicitly wrote that churn and wide oscillations are bad,
> > it's "curious" that Cavallaro thinks that I'd rather see those things.
>
> 1. Stop referring to me in the third person, it's condescending and
> rude. I address you directly. Please have the courtesy to do likewise.
If I was addressing Cavallaro, I'd send e-mail. I'm discussing his
ideas as they relate to lisp.
> 2. You specifically wrote that you'd rather see churn than a small community:
Yes, I did. However, Cavallaro wrote, incorrectly, that I thought
that churn was good. The fact that thing x is preferrable to thing y
does not imply that thing x is good.
> You can't have it both ways.
I'm not trying to. I said that churn, while bad, is better than
persistently small. I went further - I said that oscillation was
better than persistently small. (Churn doesn't imply oscillation and
can easily provide a big steady state - see university admissions for
an example.)
> ... I think churn is
> worse since the boom and bust hurts commercial implementors.
Let's test that theory.
Suppose that a persistently small community spends $1M/year on tools
and let's add oscillation. During "boom times", the spending jumps to
$10M/year on tools. During bust times, it falls back to $1M/year.
Let's say that booms last 2 years and busts last 8. Over 10 years,
the persistently small community will spend $10M on tools. The
oscillating community will spend $28M.
Yes, some/much of the $18M difference will go to support and not
development, but I'm pretty sure that the extra development will
produce something of value.
I suspect that most commercial implementors would prefer almost 3x the
revenue, even though it does come with some planning problems.
On 2007-08-02 12:03:49 -0400, Andy Freeman <······@earthlink.net> said:
> If I was addressing Cavallaro, I'd send e-mail. I'm discussing his
> ideas as they relate to lisp.
iow, you'll continue to be rude. Got it.
>
>> 2. You specifically wrote that you'd rather see churn than a small community:
>
> Yes, I did. However, Cavallaro wrote, incorrectly, that I thought
> that churn was good. The fact that thing x is preferrable to thing y
> does not imply that thing x is good.
>
>> You can't have it both ways.
>
> I'm not trying to. I said that churn, while bad, is better than
> persistently small. I went further - I said that oscillation was
> better than persistently small. (Churn doesn't imply oscillation and
> can easily provide a big steady state - see university admissions for
> an example.)
>
>> ... I think churn is
>> worse since the boom and bust hurts commercial implementors.
>
> Let's test that theory.
>
> Suppose that a persistently small community spends $1M/year on tools
> and let's add oscillation. During "boom times", the spending jumps to
> $10M/year on tools. During bust times, it falls back to $1M/year.
>
> Let's say that booms last 2 years and busts last 8.
In the real world, the bust often puts the company out of business.
On 2007-07-24 23:21:08 -0400, Madhu <·······@meer.net> said:
> For others interested in legitimizing the perception
> instead of calling it an error there is always (as usual in these
> matters) help from wikipodia:
>
> wikipedia.org/wiki/Social_constructionism
Programmers are *way* outside their area of competence when they start
delving into social constructionism in order to push their preferred
language. They should produce exceptional software and let others find
their way to lisp because of what lisp has been used for, not because
of some clever application of psycho-social theory.
On Wed, 11 Jul 2007 10:11:54 -0700, ········@gmail.com wrote:
>I think where Common Lisp faces barriers to entry are things like:
>Picking a distribution to start with when you don't know the
>language. Not knowing emacs. Not knowing which libraries are good.
>Not knowing which libraries work with the distribution you picked.
>Finding out that there is no equivalent of a library available in
>another language that would be useful for you. If you didn't pick Lisp-
>in-a-Box, then getting emacs and SLIME hooked up to your Lisp.
>Figuring out how to work ASDF/ASDF-Install to get libraries
>installed. Figuring out that some of the documentation for the APIs
>you want to use is in the Hyperspec, some is in the documentation for
>the distribution you picked, and some is in a 3rd party library you
>need.
I'll give you Emacs, but I think many of the rest are red herrings.
The biggest problem I see is one of unrealistic expectations. Not
infrequently we see threads that begin "I'm trying to learn lisp by
porting my whatsit from language X - how do I do ... in lisp?" I'm
willing to bet money that most of the people who try this did _not_
learn language X the same way. So we have people trying to, e.g.,
start tcp threads and serve HTML queries when they should be learning
how to use packages and exploring CLOS.
Most here are too polite to tell others they should not be attempting
whatever it is they are doing and should read a primer instead.
Instead a discussion ensues over how best to accomplish the posed task
and, I think, many times the person goes away with a plug-in answer
but little understanding gained.
After a few such go-rounds, some people see the light - but I think a
lot more people simply go away discouraged.
>Many of these go away with a commercial Lisp, but then you have the
>problem of either paying a few thousand dollars or figuring out you
>need to start over and face all of the above problems anyway when you
>reach the limitations of the free commercial versions.
By the time someone routinely bumps the limits of the free commercial
versions, they should be an intermediate level lisp programmer and
able to find out the answers to the questions you posed.
>I would say, though, that even if Lisp doesn't make the bad
>programmers any better, Lisp being popular could improve things for
>the good programmers who could then get paid to write Lisp on more
>projects.
That's a possible.
George
--
for email reply remove "/" from address
········@gmail.com wrote:
> If you think that the popularity of a language has no correlation with
> the ability to use that language to solve real problems, I don't know
> what to tell you.
Rather than taking gross statistics, look at all of the software tools you
use every day and list how many were written in each language. In my case,
there is quite a spread (ledit, emacs, etc.).
> More, better debugged libraries
I've been stifled by many more bugs in g++ than in ocamlopt.
> and frameworks,
I find the libraries for many non-mainstream languages to be far better,
basically because non-mainstream languages self-select the programming
elite.
I wanted an FFT in OCaml, there are bindings to the excellent FFTW. I wanted
an FFT in C#, there is nothing for free that's reliable and $400 buys you
an O(n^2) algorithm.
> larger developer pool,
Of idiots. I've spent the best part of a week trying to translate a 3-line
Python program doing RPCs onto .NET. I asked why they don't promote dynamic
typing for this task and got a response along the lines of "everything is
fundamentally dynamically typed in .NET".
> better odds of finding someone who has found your particular problem
Definitely. Whenever I have a problem with a mainstream language/framework,
Google refers me to an endless number of people with the same unsolved
problem.
> more tools
I'm still looking for a decent IDE in any language...
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
On Jul 9, 5:55 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> I find the libraries for many non-mainstream languages to be far better,
> basically because non-mainstream languages self-select the programming
> elite.
>
> I wanted an FFT in OCaml, there are bindings to the excellent FFTW. I wanted
> an FFT in C#, there is nothing for free that's reliable and $400 buys you
> an O(n^2) algorithm.
A new interest of mine is machine learning. I took one course in the
Spring and intend to take another this fall.
Here's a discussion of programming languages for machine learning:
http://hunch.net/?p=230
"1. Weka is one of the best known general purpose machine learning
toolkits. It is implemented in Java and has far more algorithmic
coverage than any other system I know of."
And he cites other libraries in C and C++. Further casual browsing
reveals this list of java machine learning libraries:
http://del.icio.us/machinelearningsoftware/java
Lisp is not even listed in the languages in the side bar.
Lisp gets mentioned in the blog post comments, but pepito is the only
library cited. Its from Franz and you can't even find out how much it
costs without calling for a quote (translation: you probably can't
afford it if you need to ask).
Google search on "Lisp machine learning" yields this:
ftp://ftp.cs.utexas.edu/pub/mooney/ml-progs/
and not much else in the way of available code. Note the 1996-1997
file dates.
The sad thing is that Lisp is exactly in the place that the above
blogger longs for. A high level language that compiles to fast,
native code. But the libraries and developers just aren't there.
I did all of my homeworks for my previous class in SBCL. But when I
worked with others on a final team project, the sum total of my
homework code couldn't compare to something like weka and I didn't
have the time or expertise to write all of the equivalent code myself.
········@gmail.com wrote:
> You need to weigh this against all the advantages of using a popular
> language. If two languages are equally good on technical merits, are
> there any actual advantages to picking the one that is less popular?
> Sure, there are advantages to using the most powerful (in the Paul
> Graham sense) language available even if it is not very popular, but
> does becoming more popular really make the language worse?
As a *programmer* I doubt I'd agree out of hand - it depends an awful
lot on who it's popular _with_. Trying to get anything
Javascript-related out of Google, for example, is a deeply
unsatisfactory experience - because all you'll get for any query term
you can think of is (a) morons asking how to do something related, (b)
cargo-culted answers from other morons who don't understand; (c) web
pages written by yet more morons advertising scripts that you can
download for $15. Which is a shame because the language is actually not
totally without merit. But there are just too many people using it who
think that copy and paste coding is an acceptable substitute for knowing
what they're doing.
As an *end-user* I have a different take on the
popularity-vs-competitive-advantage argument, but I'm not going to
repeat what I already said on that subject in
http://ww.telent.net/diary/2004/2/#26.84907
-dan
On Jul 9, 5:30 pm, Daniel Barlow <····@coruskate.net> wrote:
> As a *programmer* I doubt I'd agree out of hand - it depends an awful
> lot on who it's popular _with_. Trying to get anything
> Javascript-related out of Google, for example, is a deeply
> unsatisfactory experience - because all you'll get for any query term
> you can think of is (a) morons asking how to do something related, (b)
> cargo-culted answers from other morons who don't understand; (c) web
> pages written by yet more morons advertising scripts that you can
> download for $15. Which is a shame because the language is actually not
> totally without merit. But there are just too many people using it who
> think that copy and paste coding is an acceptable substitute for knowing
> what they're doing.
So, popularity can make a programming language worse by decreasing the
signal-to-noise ratio. Interesting.
The confounding factor with Javascript as an example is that it's
massively deployed, in more or less every web browser on Earth. But
that is a different metric of "popularity" than I had in mind, I
admit.
I think you can also find people doing interesting things with
Javascript, though, so it amounts to how you weigh wading through the
muck to find the occasional pearl.
-jimbo
Don Geddis wrote:
> Some thoughts spurred -- I am ashamed to admit -- by our local spammer JH.
> Just curious if anyone here has thoughts on these possible additions to a
> core (new) Lisp, or perhaps other similar topics that ought to be included.
I think it's good to keep asking this question but I suspect everyone
wants different things.
For me, Common Lisp occupies an interesting middle ground. The
standard is much more than just some EBNF but much less than say Java
which is both a language standard and an extensive framework of
standard libraries.
I'm not sure how easy it is to add stuff into that core without
breaking things or upsetting a lot of people (look at R6RS) but maybe
identifying a set of generally useful and portable libraries as
'recommended extensions' is a good place to start (a bit like Edi
Weitz starter pack)?
But I'm sure people will hate that idea too :-)
Phil
http://phil.nullable.eu/
On Jul 2, 4:58 am, ···············@gmail.com wrote:
> I'm not sure how easy it is to add stuff into that core without
> breaking things or upsetting a lot of people (look at R6RS) but maybe
> identifying a set of generally useful and portable libraries as
> 'recommended extensions' is a good place to start (a bit like Edi
> Weitz starter pack)?
I've been trying to push the meme of making Starter Pack a standard
part of every Lisp distribution any chance I get [1], especially all
the free Lisps. Lisp in a Box plus Starter Pack prepackaged and
double clickable would be a brilliant introduction to Common Lisp,
provided you know Emacs or are willing to learn.
-jimbo
[1] Standard disclaimer: yes, I should be doing more to actually make
this happen. It's on the list of "this would be a great thing to do
if I found the time."
On Jul 2, 8:04 pm, ········@gmail.com wrote:
> the free Lisps. Lisp in a Box plus Starter Pack prepackaged and
> double clickable would be a brilliant introduction to Common Lisp,
> provided you know Emacs or are willing to learn.
I agree apart from Lisp in a Box...but I'm not exactly impartial ;-)
-- Phil
http://phil.nullable.eu/
On Jul 2, 3:19 pm, ···············@gmail.com wrote:
> I agree apart from Lisp in a Box...but I'm not exactly impartial ;-)
Aha! I had browsed your ABLE page before, but did not remember the
name of the author :).
Well, by bundling a Starter Pack you would be way ahead of the Lisp in
a Box and SLIME distributions.
I'm going to stick with Aquamacs with bundled SLIME + SBCL on my Mac,
but I think ABLE + CLisp or SBCL + Starter Pack could be a great
solution for programmers who don't know Emacs to be introduced to
Lisp.
Good luck with ABLE. Looks like a neat project.
-jimbo
········@gmail.com writes:
>
> Good luck with ABLE. Looks like a neat project.
It really does. Who knows, in thirty years it might be ablemacs:-)
--
Robert Uhl <http://public.xdi.org/=ruhl>
A prohibitionist is the sort of man one wouldn't care to drink with even
if he drank. --H.L. Mencken
Don Geddis wrote:
> Maybe multiprocessing too.
In the Mundus Novus Bellus[1] of multicore concurrency, I've been
wondering how CL's mapping functions and binding forms will fare,
since they're all guaranteed in the spec to be eval'd in order.
> The previously mentioned spammer has suggested that pattern-matching
> function definition is one such thing.
ML-style pattern matching seems to be pretty easy.
> Call/CC?
Haskellers seem to think they're higher on the power spectrum than Lisp.
Apparently, continuations can be implemented in monads.
[1] (Thanks for the idea, MT :))
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Don Geddis wrote:
> > Maybe multiprocessing too.
> In the Mundus Novus Bellus[1] of multicore concurrency, I've been
> wondering how CL's mapping functions and binding forms will fare,
> since they're all guaranteed in the spec to be eval'd in order.
The IEEE 754 types are having a discussion about similar issues
involving bitwise reproducibility, especially on parallel platforms.
There seems to be a general consensus to provide two modes: slow and
(somewhat) reproducible (on one machine, i.e., ./a.out called twice
returns the same answer), and fast and not necessarily reproducible.
Perhaps a CL implementation could offer the same choice of modes -- it
defaults to the standard, but allows relaxation if the user accepts the
possible consequences.
> [1] (Thanks for the idea, MT :))
Ha, I push this stuff too hard... ;-P
mfh
Dan Bensen wrote:
> Don Geddis wrote:
> > Maybe multiprocessing too.
> In the Mundus Novus Bellus[1] of multicore concurrency, I've been
> wondering how CL's mapping functions and binding forms will fare,
> since they're all guaranteed in the spec to be eval'd in order.
The IEEE 754 types are having a discussion about similar issues
involving bitwise reproducibility, especially on parallel platforms.
There seems to be a general consensus to provide two modes: slow and
(somewhat) reproducible (on one machine, i.e., ./a.out called twice
returns the same answer), and fast and not necessarily reproducible.
Perhaps a CL implementation could offer the same choice of modes -- it
defaults to the standard, but allows relaxation if the user accepts the
possible consequences.
> [1] (Thanks for the idea, MT :))
Ha, I push this stuff too hard... ;-P
mfh
Dan Bensen wrote:
> ML-style pattern matching seems to be pretty easy.
Then you'll be able to post a shorter and faster Lisp implementation of the
symbolic simplifier benchmark we discussed recently.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
> Dan Bensen wrote:
>> ML-style pattern matching seems to be pretty easy.
Jon Harrop wrote:
> Then you'll be able to post a shorter and faster Lisp implementation
> of the symbolic simplifier benchmark we discussed recently.
Could you point me to it please?
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Jon Harrop wrote:
> > Then you'll be able to post a shorter and faster Lisp implementation
> > of the symbolic simplifier benchmark we discussed recently.
>
> Could you point me to it please?
http://groups.google.com/group/comp.lang.functional/msg/bffeb5a3948a3a1a
The problem is to simplify symbolic expressions by applying the following
rewrite rules from the leaves up:
rational n + rational m -> rational(n + m)
rational n * rational m -> rational(n * m)
symbol x -> symbol x
0+f -> f
f+0 -> f
0*f -> 0
f*0 -> 0
1*f -> f
f*1 -> f
a+(b+c) -> (a+b)+c
a*(b*c) -> (a*b)*c
This can be written in OCaml as:
let rec ( +: ) f g = match f, g with
| `Int n, `Int m -> `Int (n +/ m)
| `Int (Int 0), e | e, `Int (Int 0) -> e
| f, `Add(g, h) -> f +: g +: h
| f, g -> `Add(f, g)
let rec ( *: ) f g = match f, g with
| `Int n, `Int m -> `Int (n */ m)
| `Int (Int 0), e | e, `Int (Int 0) -> `Int (Int 0)
| `Int (Int 1), e | e, `Int (Int 1) -> e
| f, `Mul(g, h) -> f *: g *: h
| f, g -> `Mul(f, g)
let rec simplify = function
| `Int _ | `Var _ as f -> f
| `Add (f, g) -> simplify f +: simplify g
| `Mul (f, g) -> simplify f *: simplify g
Several people came up with different approaches in Lisp.
Andre Thieme came up with quite an elegant solution that is 100x slower than
the OCaml:
(defun simplify (a)
(if (atom a)
a
(destructuring-bind (op x y) a
(let* ((f (simplify x))
(g (simplify y))
(nf (numberp f))
(ng (numberp g))
(+? (eq '+ op))
(*? (eq '* op)))
(cond
((and +? nf ng) (+ f g))
((and +? nf (zerop f)) g)
((and +? ng (zerop g)) f)
((and (listp g) (eq op (first g)))
(destructuring-bind (op2 u v) g
(simplify `(,op (,op ,f ,u) ,v))))
((and *? nf ng) (* f g))
((and *? (or (and nf (zerop f))
(and ng (zerop g)))) 0)
((and *? nf (= 1 f)) g)
((and *? ng (= 1 g)) f)
(t `(,op ,f ,g)))))))
Nathan Froyd compiled the pattern match down into Lisp by hand to greatly
improve performance at the cost of obfuscation but the result is still many
times slower than the OCaml:
(defun simplify-no-redundant-checks (xexpr)
(declare (optimize (speed 3)))
(if (atom xexpr)
xexpr
(let ((op (first xexpr))
(z (second xexpr))
(y (third xexpr)))
(let* ((f (simplify-no-redundant-checks z))
(g (simplify-no-redundant-checks y))
(nf (numberp f))
(ng (numberp g)))
(tagbody
START
(if (eq '+ op) (go OPTIMIZE-PLUS) (go TEST-MULTIPLY))
OPTIMIZE-PLUS
(when (and nf ng) (return-from simplify-no-redundant-checks (+
f g)))
TEST-PLUS-ZEROS
(when (eql f 0) (return-from simplify-no-redundant-checks g))
(when (eql g 0) (return-from simplify-no-redundant-checks f))
(go REARRANGE-EXPR)
TEST-MULTIPLY
(unless (eq '* op) (go REARRANGE-EXPR))
OPTIMIZE-MULTIPLY
(when (and nf ng) (return-from simplify-no-redundant-checks (*
f g)))
TEST-MULTIPLY-ZEROS-AND-ONES
(when (or (eql f 0) (eql g 0)) (return-from
simplify-no-redundant-checks 0))
(when (eql f 1) (return-from simplify-no-redundant-checks g))
(when (eql g 1) (return-from simplify-no-redundant-checks f))
REARRANGE-EXPR
(when (and (listp g) (eq op (first g)))
(let ((op2 (first g))
(u (second g))
(v (third g)))
(declare (ignore op2))
(return-from simplify-no-redundant-checks
(simplify-no-redundant-checks (list op (list op f u)
v)))))
MAYBE-CONS-EXPR
(if (and (eq f z) (eq g y))
(return-from simplify-no-redundant-checks xexpr)
(return-from simplify-no-redundant-checks (list op f
g))))))))
The fastest Lisp implementation to date was written by Pascal Constanza. It
is also quite elegant but still 3x slower than the OCaml. More
interestingly, it avoids s-exprs:
(defstruct add x y)
(defstruct mul x y)
(defgeneric simplify-add (x y)
(declare (optimize (speed 3)))
(:method ((x number) (y number)) (+ x y))
(:method ((x (eql 0)) y) y)
(:method (x (y (eql 0))) x)
(:method (x (y add))
(simplify-add (simplify-add x (add-x y)) (add-y y)))
(:method (x y) (make-add :x x :y y)))
(defgeneric simplify-mul (x y)
(declare (optimize (speed 3)))
(:method ((x number) (y number)) (* x y))
(:method ((x (eql 0)) y) 0)
(:method (x (y (eql 0))) 0)
(:method ((x (eql 1)) y) y)
(:method (x (y (eql 1))) x)
(:method (x (y mul))
(simplify-mul (simplify-mul x (mul-x y)) (mul-y y)))
(:method (x y) (make-mul :x x :y y)))
(defgeneric simplify (exp)
(declare (optimize (speed 3)))
(:method (exp) exp)
(:method ((exp add))
(simplify-add (simplify (add-x exp)) (simplify (add-y exp))))
(:method ((exp mul))
(simplify-mul (simplify (mul-x exp)) (simplify (mul-y exp)))))
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
If you're interested in practical applications of term rewriting then check
out the genfft program from FFTW, which is part of Matlab:
http://www.fftw.org
It generates codelets to perform FFTs, symbolically simplifies them and then
compiles them into C code, e.g.:
and splusM l =
let fma_heuristics x =
if !Magic.enable_fma then
match x with
| [Uminus (Times _); Times _] -> Some false
| [Times _; Uminus (Times _)] -> Some false
| [Uminus (_); Times _] -> Some true
| [Times _; Uminus (Plus _)] -> Some true
| [_; Uminus (Times _)] -> Some false
| [Uminus (Times _); _] -> Some false
| _ -> None
else
None
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
>> Jon Harrop wrote:
>> > Then you'll be able to post a shorter and faster Lisp
>> > implementation of the symbolic simplifier benchmark
> Dan Bensen wrote:
>> Could you point me to it please?
Jon Harrop wrote:
> groups.google.com/group/comp.lang.functional/msg/bffeb5a3948a3a1a
> The problem is to simplify symbolic expressions by applying the
> following rewrite rules from the leaves up:
> rational n + rational m -> rational(n + m)
> rational n * rational m -> rational(n * m)
> symbol x -> symbol x
> 0+f -> f f+0 -> f
> 0*f -> 0 f*0 -> 0
> 1*f -> f f*1 -> f
> a+(b+c) -> (a+b)+c
> a*(b*c) -> (a*b)*c
Okay, here's an entry. I'm not sure anyone here
expects Lisp to be faster than OCaml at runtime,
since that's what OCaml is optimized for, but
at least the code for + and * can be consolidated:
(defmacro defop (func op ident zero-case)
(let ((e1 (gensym "E1"))
(e2 (gensym "E2")))
`(defun ,func (,e1 ,e2)
,(delete :no-case
`(case ,e1
,zero-case
(,ident ,e2)
(t ,(delete :no-case
`(case ,e2
,zero-case
(,ident ,e1)
(t (if (atom ,e2) (list ,e1 ,op ,e2)
(case (cadr ,e2)
(,op (,func (,func ,e1 (car ,e2)) (caddr ,e2)))
(t (list ,e1 ,op ,e2)))))))))))))
(defop expr+ '+ 0 :no-case)
(defop expr* '* 1 ( 0 0 ))
(defun simplify (expr)
(if (atom expr)
expr
(let ((e1 (simplify (car expr)))
(e2 (simplify (caddr expr))))
(case (cadr expr)
('+ (expr+ e1 e2))
('* (expr* e1 e2))))))
(defvar eqn
'((1 * ((4 + (3 + 6)) + 0)) * (0 + ((2 * (8 * 9)) * 1))))
(format t "~A~%" eqn )
(format t "~A~%" (simplify eqn))
=>
((1 * ((4 + (3 + 6)) + 0)) * (0 + ((2 * (8 * 9)) * 1)))
(((((4 + 3) + 6) * 2) * 8) * 9)
--
Dan
www.prairienet.org/~dsb/
Don Geddis <···@geddis.org> writes:
> Just curious if anyone here has thoughts on these possible additions to a
> core (new) Lisp, or perhaps other similar topics that ought to be included.
> ITERATE? SERIES? Partial evaluation? Call/CC?
What's the difference between having feature X "included" and loading
a library that implements it? Lisp is very easy to extend.
Sure, if the library doesn't exist yet, you have to write it, but that
also has to happen for having it "included".
Tamas
Tamas Papp <······@gmail.com> wrote on Mon, 02 Jul 2007:
> What's the difference between having feature X "included" and loading
> a library that implements it? Lisp is very easy to extend.
Think about that in terms of garbage collection and macros. If Lisp had
begun without them, could they be merely added later as a "library"?
CLOS is probably on the border. In ANSI CL, it kind of is just bolted on at
the end, much as a library that will always be loaded.
So what's the difference? To me, it seems that there are some things you
expect every Lisp programmer to be aware of, to be capable of using in their
own code, and to immediately recognize if they read code written by others.
Things like GC and macros permeate code written for every application area.
This isn't like numerical analysis, or sockets, or something, where if you
aren't doing that kind of programming, you wouldn't necessarily use those
libraries.
But regular expressions, or prolog-style inference, could appear in any piece
of code at any time. I suspect they aren't more common in Lisp because they
aren't a standard part of the language, not because they aren't useful to the
programmer.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I can please only one person per day.
Today is not your day.
Tomorrow isn't looking good either.
-- DNRC Motto
Don Geddis schrieb:
> Tamas Papp <······@gmail.com> wrote on Mon, 02 Jul 2007:
>> What's the difference between having feature X "included" and loading
>> a library that implements it? Lisp is very easy to extend.
>
> Think about that in terms of garbage collection and macros. If Lisp had
> begun without them, could they be merely added later as a "library"?
Yes.
Andr� Thieme wrote:
> Don Geddis schrieb:
>> Tamas Papp <······@gmail.com> wrote on Mon, 02 Jul 2007:
>>> What's the difference between having feature X "included" and loading
>>> a library that implements it? Lisp is very easy to extend.
>>
>> Think about that in terms of garbage collection and macros. If Lisp had
>> begun without them, could they be merely added later as a "library"?
>
> Yes.
at a grave cost in terms of performance.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Tamas Papp wrote:
> What's the difference between having feature X "included" and loading
> a library that implements it?
Performance, reliability and uniformity. Try writing a correct optimizing
pattern match compiler, for example. Then try getting as many people to use
it has Haskell and OCaml have done.
> Lisp is very easy to extend.
No more than the next language.
> Sure, if the library doesn't exist yet, you have to write it...
If you get that far: Greenspun.
Most Lispers don't get that far though. They fall for the hype and believe
that everything invented in all other languages since Lisp is both obvious
and easily retrofitted onto Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Matthias Buelow wrote:
> Jon Harrop wrote:
>> Try writing a correct optimizing pattern match compiler, for example.
>
> Have you?
Yes.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Re: Unification...
An interesting programming language along that particular line is Oz -
one of the few languages that is built around the Prolog model of
unification. I can't really say how well it stacks up with Lisp, but
I did do a bit of translation of Friedman and Felleisen for anyone
interested in a more involved Scheme/Oz comparison:
http://www.codepoetics.com/wiki/index.php?title=Topics:TRS_in_other_languages:Oz
It's also worth mentioning Kanren here as well, as it is basically
Scheme with unification. And speaking of which, the best source for
O'Caml and Scheme would probably be Oleg Kiselyov, as he's a leading
expert on both languages. Of course, Common Lisp (which appears to be
the main subject of comp.lang.lisp) and Scheme are two different
languages. And sometimes the closer the languages are to each other,
the more inflammatory the rhetoric can get. But then I'm one that
likes to see the similarity in programming languages, as much as I
like to see their differences.
I was wondering if there has been some work on unification and/or
futures in Lisp? (Alice-ML draws from the work of futures in
MultiLisp).
Thanks,
Chris Rathman
On Jul 1, 10:38 pm, Don Geddis <····@geddis.org> wrote:
>
> And the pattern-matching programming idea got me thinking of unification. At
> one time, people touted Prolog as the future of programming languages. Very,
> very different from Lisp, and hugely useful when it applies. I think Prolog
> failed as a general purpose programming language, but should that technology
> be part of the bag of tricks available to every Lisp programmer? Unification
> and inference is probably a generalization of the pattern-matching idea.
>
> -- Don
> _______________________________________________________________________________
> Don Geddis http://don.geddis.org/ ····@geddis.org
> In bed the other night my girlfriend asked "if you could know exactly when and
> where you would die, would you want to?" I said "no". She said, "ok, then
> forget it". -- Steven Wright
Of course LISP is blub. All languages are blub given the right
context. Certain programming language features are mutually exclusive,
and simplicity is also a worthy feature, hence leading to the
conclusion that the perfect language, the one that incorporates all
features of all other languages, does not exist.
On Jul 2, 5:38 am, Don Geddis <····@geddis.org> wrote:
> Some thoughts spurred -- I am ashamed to admit -- by our local spammer JH.
>
> Probably most of us are familiar with Paul Graham's hypothetical "Blub"
> language, as described in the section "The Blub Paradox" in the middle ofhttp://paulgraham.com/avg.html
> It was a hypothetical example to show how some programmers, only used to
> languages less powerful than Lisp, might not appreciate the power of Lisp,
> simply because they don't understand those features of Lisp that their own
> favorite language lacks.
>
> The core of the argument is here:
>
> Blub falls right in the middle of the abstractness continuum. It is
> not the most powerful language, but it is more powerful than Cobol or
> machine language.
>
> And in fact, our hypothetical Blub programmer wouldn't use either of
> them. Of course he wouldn't program in machine language. That's what
> compilers are for. And as for Cobol, he doesn't know how anyone can
> get anything done with it. It doesn't even have x (Blub feature of
> your choice).
>
> As long as our hypothetical Blub programmer is looking down the power
> continuum, he knows he's looking down. Languages less powerful than
> Blub are obviously less powerful, because they're missing some
> feature he's used to. But when our hypothetical Blub programmer looks
> in the other direction, up the power continuum, he doesn't realize
> he's looking up. What he sees are merely weird languages. He probably
> considers them about equivalent in power to Blub, but with all this
> other hairy stuff thrown in as well. Blub is good enough for him,
> because he thinks in Blub.
>
> When we switch to the point of view of a programmer using any of the
> languages higher up the power continuum, however, we find that he in
> turn looks down upon Blub. How can you get anything done in Blub? It
> doesn't even have y.
>
> By induction, the only programmers in a position to see all the
> differences in power between the various languages are those who
> understand the most powerful one.
>
> Along the same lines, John McCarthy apparently once said something like:
> Lisp seems to be a lucky discovery of a local maximum in the space of
> programming languages.
> Also paraphrased as:
> Lisp is a kind of local maximum in programming language quality: not
> necessarily the best thing possible, but hard to change in any simple
> way without making it worse.
>
> OK, so now the question. Common Lisp was formalized quite some time ago;
> ANSI CL a bit later, but without many radical changes. Are there tools now
> known in the abstract space of programming language design that "ought" to be
> part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
> surely have been strongly suggested to get added to the language?
>
> I'd like to distinguish this from libraries or specific applications, which
> are easy enough to layer on top of existing ANSI CL. Of course everybody can
> name sockets, or web programming (XML parsers, HTTP servers). I'm thinking
> of generic ideas in the description of computation, which apply across a wide
> range of applications. Things like "iteration" or "recursion" or "CLOS".
>
> There are some things clearly on the edge. All the existing trig functions
> (SIN, COS, TAN) are highly useful to some small set of programmers, and
> generally ignored by the rest. They could have easily been an add-on
> library. (On the other hand, the basic numeric tower in Lisp, the automatic
> conversion of numbers between data types, is far more fundamental to the
> language.)
>
> Regular expression matching, which is missing from the ANSI CL standard, is
> probably of this "edge" class and would have been included in a CL2. Maybe
> multiprocessing too.
>
> So I'm wondering about language expressions that are so fundamental to
> describing computation, that they "ought" to be part of the vocabulary of any
> advanced programmer.
>
> The previously mentioned spammer has suggested that pattern-matching function
> definition is one such thing. As best I can tell, this seems to be sort of
> related to CLOS generic methods, with different code called for different
> argument lists, although the power of the expressions to choose the different
> code that is called is greater with pattern-matching than with CLOS.
>
> Static typing is another interesting corner case. Lots of pros and cons.
> Qi seems to claim a Lisp-like language with "optional" static typing. Would
> that be something that "should" be in a CL2?
>
> And the pattern-matching programming idea got me thinking of unification. At
> one time, people touted Prolog as the future of programming languages. Very,
> very different from Lisp, and hugely useful when it applies. I think Prolog
> failed as a general purpose programming language, but should that technology
> be part of the bag of tricks available to every Lisp programmer? Unification
> and inference is probably a generalization of the pattern-matching idea.
>
> Just curious if anyone here has thoughts on these possible additions to a
> core (new) Lisp, or perhaps other similar topics that ought to be included.
> ITERATE? SERIES? Partial evaluation? Call/CC?
>
> -- Don
> ___________________________________________________________________________ ____
> Don Geddis http://don.geddis.org/ ····@geddis.org
> In bed the other night my girlfriend asked "if you could know exactly when and
> where you would die, would you want to?" I said "no". She said, "ok, then
> forget it". -- Steven Wright
Don Geddis wrote:
> OK, so now the question. Common Lisp was formalized quite some time ago;
> ANSI CL a bit later, but without many radical changes. Are there tools now
> known in the abstract space of programming language design that "ought" to be
> part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
> surely have been strongly suggested to get added to the language?
>
> I'd like to distinguish this from libraries or specific applications, which
> are easy enough to layer on top of existing ANSI CL. Of course everybody can
> name sockets, or web programming (XML parsers, HTTP servers). I'm thinking
> of generic ideas in the description of computation, which apply across a wide
> range of applications. Things like "iteration" or "recursion" or "CLOS".
Maybe it's more natural to let programming languages evolve on their
own, as hardware and applications evolve. For example, who could have
seen in the late 1950's that parallelism would become both important for
performance, and difficult to reason about in code? If they had tried
to formulate parallel language constructs back then, it's almost certain
that they wouldn't have hit the right level of abstraction.
There are some things I'd like to see made part of a CL implementation,
but these are not so much language features:
1. More control over the garbage collector in a multithreaded
environment -- in particular, being able to "pin" array data without
interrupting the GC or synchronizing threads;
2. Guarantees of bit-level compatibility with C / Fortran arrays for
certain array types.
> There are some things clearly on the edge. All the existing trig functions
> (SIN, COS, TAN) are highly useful to some small set of programmers, and
> generally ignored by the rest. They could have easily been an add-on
> library. (On the other hand, the basic numeric tower in Lisp, the automatic
> conversion of numbers between data types, is far more fundamental to the
> language.)
It's interesting that you point this out, because the "basic numeric
tower" isn't quite as tower-like as you think: there are all kinds of
floating-point numbers that people want (e.g., arbitrary or controllable
precision, "exact real" types, decimal arithmetic), and the relations
between them don't always fit into a hierarchy. (For example, sometimes
you _want_ sqrt(-1) to be an error, because otherwise it invalidates
things like the Cholesky factorization.)
This suggests an interesting language feature: more control over the
relationships between numeric types, what conversions between them are
legal, how they round, etc. A kind of "CLOS for number properties."
This power would revolutionize numerical analysis -- the hard-core IEEE
754 types would worship whoever set something like this up.
mfh
Mark Hoemmen <············@gmail.com> writes:
> There are some things I'd like to see made part of a CL
> implementation, but these are not so much language features:
>
> 1. More control over the garbage collector in a multithreaded
> environment -- in particular, being able to "pin" array data without
> interrupting the GC or synchronizing threads;
>
> 2. Guarantees of bit-level compatibility with C / Fortran arrays for
> certain array types.
Yes! Exactly whay I need. Scheme is ahead of CL regarding these
features.
Tamas
Don Geddis wrote:
> OK, so now the question. Common Lisp was formalized quite some time ago;
> ANSI CL a bit later, but without many radical changes. Are there tools now
> known in the abstract space of programming language design that "ought" to be
> part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
> surely have been strongly suggested to get added to the language?
>
> I'd like to distinguish this from libraries or specific applications, which
> are easy enough to layer on top of existing ANSI CL. Of course everybody can
> name sockets, or web programming (XML parsers, HTTP servers). I'm thinking
> of generic ideas in the description of computation, which apply across a wide
> range of applications. Things like "iteration" or "recursion" or "CLOS".
Maybe it's more natural to let programming languages evolve on their
own, as hardware and applications evolve. For example, who could have
seen in the late 1950's that parallelism would become both important for
performance, and difficult to reason about in code? If they had tried
to formulate parallel language constructs back then, it's almost certain
that they wouldn't have hit the right level of abstraction.
There are some things I'd like to see made part of a CL implementation,
but these are not so much language features:
1. More control over the garbage collector in a multithreaded
environment -- in particular, being able to "pin" array data without
interrupting the GC or synchronizing threads;
2. Guarantees of bit-level compatibility with C / Fortran arrays for
certain array types.
> There are some things clearly on the edge. All the existing trig functions
> (SIN, COS, TAN) are highly useful to some small set of programmers, and
> generally ignored by the rest. They could have easily been an add-on
> library. (On the other hand, the basic numeric tower in Lisp, the automatic
> conversion of numbers between data types, is far more fundamental to the
> language.)
It's interesting that you point this out, because the "basic numeric
tower" isn't quite as tower-like as you think: there are all kinds of
floating-point numbers that people want (e.g., arbitrary or controllable
precision, "exact real" types, decimal arithmetic), and the relations
between them don't always fit into a hierarchy. (For example, sometimes
you _want_ sqrt(-1) to be an error, because otherwise it invalidates
things like the Cholesky factorization.)
This suggests an interesting language feature: more control over the
relationships between numeric types, what conversions between them are
legal, how they round, etc. A kind of "CLOS for number properties."
This power would revolutionize numerical analysis -- the hard-core IEEE
754 types would worship whoever set something like this up.
mfh
Mark Hoemmen <············@gmail.com> writes:
> Don Geddis wrote:
>> OK, so now the question. Common Lisp was formalized quite some time ago;
>> ANSI CL a bit later, but without many radical changes. Are there tools now
>> known in the abstract space of programming language design that "ought" to be
>> part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
>> surely have been strongly suggested to get added to the language?
>> I'd like to distinguish this from libraries or specific
>> applications, which
>> are easy enough to layer on top of existing ANSI CL. Of course everybody can
>> name sockets, or web programming (XML parsers, HTTP servers). I'm thinking
>> of generic ideas in the description of computation, which apply across a wide
>> range of applications. Things like "iteration" or "recursion" or "CLOS".
>
> Maybe it's more natural to let programming languages evolve on their
> own, as hardware and applications evolve. For example, who could
> have seen in the late 1950's that parallelism would become both
> important for performance, and difficult to reason about in code?
> If they had tried to formulate parallel language constructs back
> then, it's almost certain that they wouldn't have hit the right
> level of abstraction.
There's a problem with *that* in that Common Lisp is in a phase where
it is difficult to "make it evolve" in that making standard changes
would require opening up a process that seems impractical to open up.
I don't think that XML parsing is well enough definable (in a
sufficiently standard way) to make that something highly worth "adding
to the language," whether as a 'native construct' or as a library.
There are too many well-known viable models out there (DOM, SAX, to
mention two) for there to be a clear *one* thing to add.
It seems plausible that having quasi-standard mechanisms for pattern
matching (which pretty well all of the functional languages have
gotten *very* keen on, of late) and Prolog-style unification might be
useful additions. If that could be handled via libraries that would
have a small impact on the 'language design,' I suppose so much the
better...
Improving parallelism capabilities seems like a tougher one, in that
it might require, for support of "threading-like" models, deeper
changes to language semantics.
--
output = reverse("ofni.sesabatadxunil" ·@" "enworbbc")
http://linuxfinances.info/info/lisp.html
"If your parents never had children, chances are you won't either."
-- Dick Cavett
On Jul 2, 3:50 pm, Christopher Browne <········@mail.libertyrms.com>
wrote:
> I don't think that XML parsing is well enough definable (in a
> sufficiently standard way) to make that something highly worth "adding
> to the language," whether as a 'native construct' or as a library.
> There are too many well-known viable models out there (DOM, SAX, to
> mention two) for there to be a clear *one* thing to add.
Then pick one or two and call it a day.
Java and Python and other languages with large standard libraries have
many XML libraries available, but they still pick one or a few to
include in the standard distribution by default. This means that
every programmer has SOME way of dealing with XML without thinking
about where to find good libraries, whether a library works with their
distribution, whether a library is any good, and downloading and
installing it. The programmer still has the option of downloading a
library that better suits his needs if necessary.
I will now take this opportunity to push my personal meme regarding
this topic: convince the Lisp implementors to all bundle Edi Weitz'
Starter Pack. See my disclaimer from earlier in this thread.
Hmm, maybe I should organize an email campaign to all of the Common
Lisp implementors out there.
-jimbo
Christopher Browne wrote:
> I don't think that XML parsing is well enough definable (in a
> sufficiently standard way) to make that something highly worth "adding
> to the language," whether as a 'native construct' or as a library.
> There are too many well-known viable models out there (DOM, SAX, to
> mention two) for there to be a clear *one* thing to add.
Which is why, IMO, it is not evidence for "lisp is a blub": lispers can
easily identify when they need to parse XML and how, and get a library
that does it.
> It seems plausible that having quasi-standard mechanisms for pattern
> matching (which pretty well all of the functional languages have
> gotten *very* keen on, of late) and Prolog-style unification might be
> useful additions. If that could be handled via libraries that would
> have a small impact on the 'language design,' I suppose so much the
> better...
OK, my only experience of pattern matching is from using O'Caml and its
predecessor Caml Light about 12 years ago (one of those ironies of life,
the Caml language family was a strong influence in pushing me to learn
Lisp), but as I experienced it then it seemed to be about centralising
decision making ("glorified switch statement") whereas OO is more about
decentralising it. AOP decentralises it even further with its talk of
"cross-cutting concerns" - you can now also make decisions based on
categories that aren't modelled in the class hierarchy . So, unless
that's not what we're talking about any more when we say "pattern
matching", it doesn't seem like anything _new_, just a swing back
towards having more of the logic in the same place. Of course, that's
exactly what a blub programmer would say, and maybe languages with
pattern-matching support have different tradeoffs that make that style
more elegant and expressive than the decentralised model.
> Improving parallelism capabilities seems like a tougher one, in that
> it might require, for support of "threading-like" models, deeper
> changes to language semantics.
I wouldn't be at all surprised if this is the Next Big Thing(tm). Not
because I understand anything about it, but just because I have a mental
image of the Superior language advocate saying "you just do foo and bar
and then baz happens, and it's trivially re-entrant and won't deadlock
because of the quux guarantees", and the Blub programmer going "that's
not special, you just need mutexes here and here and this is a
producer-consumer pattern and I could do it in an afternoon. Nobody
gets race conditions if they've thought about the problem at all, and
your way must introduce overhead."
The more I think about it the more I tend to the opinion that Blub is
more about the attitude of the programmer than the facilities provided
by the language, and the attitude is typified by a willingness to do
$some_hard_problem by hand instead of looking for a way to make the
computer handle the bookkeeping.
* subroutines: "it's not hard to keep a stack of the PC location so you
know where to jump back to"
* interactive development: "you should be forced to program with punched
cards, then you'd learn to get it right the first time"
* structured programming: "it's all just syntactic sugar over GOTO"
* GC: "a crutch for lazy programmers who can't keep track of their own
allocations"
* OO: "I can do that, it's just structs with function pointers in them"
* macros: "how often would you want to do that? anyway, you can use the
preprocessor"
I'd like to hope that Lisp programmers are less susceptible to this than
most programmers, just because we do have a language that has given us
the tools to invent new ways of abstracting stuff, and maybe that helps
keep our brains alert. But maybe I'm kidding myself ...
-dan
Daniel Barlow <···@coruskate.net> writes:
> Christopher Browne wrote:
>> Improving parallelism capabilities seems like a tougher one, in that
>> it might require, for support of "threading-like" models, deeper
>> changes to language semantics.
>
> I wouldn't be at all surprised if this is the Next Big Thing(tm).
A lot of people have been wanting "inherent parallelism" to be the
Next Big Thing(tm) for a long time now.
So long, indeed, that ConnectionMachine Lisp* (a Lisp variation
intended to harness certain sorts of highly parallel machines) came
and went at least 15 years ago.
In the *recent* past, the fact that Erlang uses FP to minimize
concurrency issues along with a threading model allowing huge numbers
of concurrent processes has brought that into something of a
forefront; the Stackless Python folks have taken a different tack on
it.
Of course, neither of those recent things diminish the fact that there
have been failed attempts to build better ways to program 'clustered'
systems more or less continually over the last 20 years...
Long and short of it: I don't think we have the 'silver bullet' on
parallelism yet. Unfortunately, CL seems a bit less friendly to "fine
grained parallelism" than more primitive languages. Whether that
means that CL needs to be "fixed" or whether it should be applied to
its favoured domains is less clear...
--
output = reverse("moc.enworbbc" ·@" "enworbbc")
http://linuxdatabases.info/info/linuxxian.html
Howe's Law:
Everyone has a scheme that will not work.
Christopher Browne wrote:
> A lot of people have been wanting "inherent parallelism" to be the
> Next Big Thing(tm) for a long time now.
That kind of died in the 90's (or perhaps earlier). The compiler people
worked on it and found out that it was a Hard Problem (tm).
> So long, indeed, that ConnectionMachine Lisp* (a Lisp variation
> intended to harness certain sorts of highly parallel machines) came
> and went at least 15 years ago.
Picky point -- CMLisp was sort of the "Omega Point" of *Lisp; it was
never implemented in full. *Lisp was considered an intermediate
solution. It also doesn't do anything like "inherent parallelism" --
all the parallelism is quite explicit (all the parallel operations have
different names, parallel data isn't garbage-collected and must be
explicitly freed, etc.).
> Of course, neither of those recent things diminish the fact that there
> have been failed attempts to build better ways to program 'clustered'
> systems more or less continually over the last 20 years...
How do you define "failed"? Certainly no satisfactory dominant paradigm
has emerged, but many of them had their successes (and some continue to
have successes!).
> Long and short of it: I don't think we have the 'silver bullet' on
> parallelism yet. Unfortunately, CL seems a bit less friendly to "fine
> grained parallelism" than more primitive languages.
How "fine-grained" is "fine-grained"? Do you mean SIMD instructions,
like SSE? Do you mean data parallelism, like OpenMP?
You're right that there is no "silver bullet," and maybe searching for
one is the wrong approach. I was at a conference recently that pointed
out three different parallel C variants, each of which had an advantage
for expressing a particular sort of parallelism: UPC for SPMD-style
computations, Cilk for task trees, and some other dialect whose name I
can't recall for distributed stuff. For example, Cilk makes task trees
easy but sacrifices some performance and clarity for data-parallel
operations (you have to spawn processes recursively to add a long vector
to another long vector in parallel). Maybe it's better to keep the
language as simple as possible and tailor it to a certain class of
applications.
mfh
On 3 Jul., 20:33, Mark Hoemmen <············@gmail.com> wrote:
> Picky point -- CMLisp was sort of the "Omega Point" of *Lisp; it was
> never implemented in full. *Lisp was considered an intermediate
> solution. It also doesn't do anything like "inherent parallelism" --
> all the parallelism is quite explicit (all the parallel operations have
> different names, parallel data isn't garbage-collected and must be
> explicitly freed, etc.).
The Connection Machine was attached to a front end machine. The Lisp
was running on the front end. There was no Lisp on the Connection
Machine
as I understand it. The front end Lisp had instructions for
communicating
with the Connection Machine, running programs on it (a SIMD machine)
and working with data on it. Thus the operations were explicit, since
they were executed on the Connection Machine - not the host's Lisp.
The processors on the first Connection Machine were tiny, but many (up
to 65536).
But there were also a more than a a dozen other attempts to add
support
for parallel execution to Common Lisp or to write parallel languages
on top of Common Lisp.
Don't know much about the Connection Machine, but could this effort be
revived using the IBM CELL based machines - for example the Sony
Playstation 3.
Right now there is linux for it, and you can talk to the 6 SPU's (only 6
are available of 8 total). Each SPU has 256kb of memory, so no much lisp
can live there (unless it's interpretted, or some other tricks are made).
But it could be used where the main lisp operates on the PPU (The dual
PowerPC chip) where you have about 200MB of memory, and it can generate
code for the SPU.
Btw, is anyone thinking of working with lisp on the PS3 trying to
isolate the SPU (SPE) CELL power? I was able to get slime + any of
OpenMCL, SBCL and Allegro to work on it, but that was all. Didn't do
much more than that, as I myself am still learning the language.
······@corporate-world.lisp.de wrote:
> On 3 Jul., 20:33, Mark Hoemmen <············@gmail.com> wrote:
>
>> Picky point -- CMLisp was sort of the "Omega Point" of *Lisp; it was
>> never implemented in full. *Lisp was considered an intermediate
>> solution. It also doesn't do anything like "inherent parallelism" --
>> all the parallelism is quite explicit (all the parallel operations have
>> different names, parallel data isn't garbage-collected and must be
>> explicitly freed, etc.).
>
> The Connection Machine was attached to a front end machine. The Lisp
> was running on the front end. There was no Lisp on the Connection
> Machine
> as I understand it. The front end Lisp had instructions for
> communicating
> with the Connection Machine, running programs on it (a SIMD machine)
> and working with data on it. Thus the operations were explicit, since
> they were executed on the Connection Machine - not the host's Lisp.
> The processors on the first Connection Machine were tiny, but many (up
> to 65536).
>
> But there were also a more than a a dozen other attempts to add
> support
> for parallel execution to Common Lisp or to write parallel languages
> on top of Common Lisp.
>
>
Don't know much about the Connection Machine, but could this effort be
revived using the IBM CELL based machines - for example the Sony
Playstation 3.
Right now there is linux for it, and you can talk to the 6 SPU's (only 6
are available of 8 total). Each SPU has 256kb of memory, so no much lisp
can live there (unless it's interpretted, or some other tricks are made).
But it could be used where the main lisp operates on the PPU (The dual
PowerPC chip) where you have about 200MB of memory, and it can generate
code for the SPU.
Btw, is anyone thinking of working with lisp on the PS3 trying to
isolate the SPU (SPE) CELL power? I was able to get slime + any of
OpenMCL, SBCL and Allegro to work on it, but that was all. Didn't do
much more than that, as I myself am still learning the language.
······@corporate-world.lisp.de wrote:
> On 3 Jul., 20:33, Mark Hoemmen <············@gmail.com> wrote:
>
>> Picky point -- CMLisp was sort of the "Omega Point" of *Lisp; it was
>> never implemented in full. *Lisp was considered an intermediate
>> solution. It also doesn't do anything like "inherent parallelism" --
>> all the parallelism is quite explicit (all the parallel operations have
>> different names, parallel data isn't garbage-collected and must be
>> explicitly freed, etc.).
>
> The Connection Machine was attached to a front end machine. The Lisp
> was running on the front end. There was no Lisp on the Connection
> Machine
> as I understand it. The front end Lisp had instructions for
> communicating
> with the Connection Machine, running programs on it (a SIMD machine)
> and working with data on it. Thus the operations were explicit, since
> they were executed on the Connection Machine - not the host's Lisp.
> The processors on the first Connection Machine were tiny, but many (up
> to 65536).
>
> But there were also a more than a a dozen other attempts to add
> support
> for parallel execution to Common Lisp or to write parallel languages
> on top of Common Lisp.
>
>
On Jul 3, 12:55 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
wrote:
> Don't know much about the Connection Machine, but could this effort be
> revived using the IBM CELL based machines - for example the Sony
> Playstation 3.
>
> Right now there is linux for it, and you can talk to the 6 SPU's (only 6
> are available of 8 total). Each SPU has 256kb of memory, so no much lisp
> can live there (unless it's interpretted, or some other tricks are made).
You'll probably want to build a "Lisp for Cell" on the existing Cell
API. See for example:
http://www.bsc.es/projects/deepcomputing/linuxoncell/ -> Documentation
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/FC857AE550F7EB83872571A80061F788
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E
Cell's parallel model is much different than the CM model used by
*Lisp: Cell has 128-bit SIMD vector instructions, shared-memory
thread-based parallelism, and an explicitly managed memory hierarchy
in the SPE's, whereas *Lisp treats the parallel machine like a remote
massively SIMD thing that operates on configurable grids of data.
> Btw, is anyone thinking of working with lisp on the PS3 trying to
> isolate the SPU (SPE) CELL power? I was able to get slime + any of
> OpenMCL, SBCL and Allegro to work on it, but that was all. Didn't do
> much more than that, as I myself am still learning the language.
Maybe a good starting point would be hacking a Lisp -> C compiler,
like ECL?
mfh
Christopher Browne wrote:
> A lot of people have been wanting "inherent parallelism" to be the
> Next Big Thing(tm) for a long time now.
That kind of died in the 90's (or perhaps earlier). The compiler people
worked on it and found out that it was a Hard Problem (tm).
> So long, indeed, that ConnectionMachine Lisp* (a Lisp variation
> intended to harness certain sorts of highly parallel machines) came
> and went at least 15 years ago.
Picky point -- CMLisp was sort of the "Omega Point" of *Lisp; it was
never implemented in full. *Lisp was considered an intermediate
solution. It also doesn't do anything like "inherent parallelism" --
all the parallelism is quite explicit (all the parallel operations have
different names, parallel data isn't garbage-collected and must be
explicitly freed, etc.).
> Of course, neither of those recent things diminish the fact that there
> have been failed attempts to build better ways to program 'clustered'
> systems more or less continually over the last 20 years...
How do you define "failed"? Certainly no satisfactory dominant paradigm
has emerged, but many of them had their successes (and some continue to
have successes!).
> Long and short of it: I don't think we have the 'silver bullet' on
> parallelism yet. Unfortunately, CL seems a bit less friendly to "fine
> grained parallelism" than more primitive languages.
How "fine-grained" is "fine-grained"? Do you mean SIMD instructions,
like SSE? Do you mean data parallelism, like OpenMP?
You're right that there is no "silver bullet," and maybe searching for
one is the wrong approach. I was at a conference recently that pointed
out three different parallel C variants, each of which had an advantage
for expressing a particular sort of parallelism: UPC for SPMD-style
computations, Cilk for task trees, and some other dialect whose name I
can't recall for distributed stuff. For example, Cilk makes task trees
easy but sacrifices some performance and clarity for data-parallel
operations (you have to spawn processes recursively to add a long vector
to another long vector in parallel). Maybe it's better to keep the
language as simple as possible and tailor it to a certain class of
applications.
mfh
Don Geddis wrote:
> Some thoughts spurred -- I am ashamed to admit -- by our local spammer JH.
>
> Probably most of us are familiar with Paul Graham's hypothetical "Blub"
> language, as described in the section "The Blub Paradox" in the middle of
> http://paulgraham.com/avg.html
> It was a hypothetical example to show how some programmers, only used to
> languages less powerful than Lisp, might not appreciate the power of Lisp,
> simply because they don't understand those features of Lisp that their own
> favorite language lacks.
This is one of Paul Graham's worst text fragments, IMHO (the rest of
"Beating the Averages is quite good, though). You can only relate to it
when you think that you're "up in the power continuum." However, you may
simply not know that others are even "higher" in the "power continuum."
There are essentially two possibilities: Either another language is
worse than the one you prefer, or you simply don't understand it, in
which case it simply _appears_ to be worse to you. This effectively
means that, if you think that another language is worse than the one you
prefer, you simply cannot draw any conclusions. [This is an
exaggeration, of course, things are different if you know the involved
languages very closely.]
Bjarne Stroustrup's remarks about language comparisons apply here:
"I also worry about a phenomenon I have repeatedly observed in honest
attempts at language comparisons. The authors try hard to be impartial,
but are hopelessly biased by focusing on a single application, a single
style of programming, or a single culture among programmers. Worse, when
one language is significantly better known than others, a subtle shift
in perspective occurs: Flaws in the well-known language are deemed minor
and simple workarounds are presented, whereas similar flaws in other
languages are deemed fundamental. Often, the workarounds commonly used
in the less-well-known languages are simply unknown to the people doing
the comparison or deemed unsatisfactory because they would be unworkable
in the more familiar language."
See http://www.research.att.com/~bs/bs_faq.html#compare
In contrast, I find Paul Graham's ideas about "Blub" counter-enlightening.
Also: There is nothing special about being "up in the power continuum."
Just because most languages suck nowadays doesn't mean that you're
special because you happen to know a language that doesn't suck that
much. The ideas behind Lisp are only mind blowing when compared to more
mainstream languages. In 200 years from now, though, these ideas will be
regarded as trivial.
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 on Mon, 02 Jul 2007:
> This is one of Paul Graham's worst text fragments, IMHO (the rest of "Beating
> the Averages is quite good, though). You can only relate to it when you think
> that you're "up in the power continuum." However, you may simply not know
> that others are even "higher" in the "power continuum." There are essentially
> two possibilities: Either another language is worse than the one you prefer,
> or you simply don't understand it, in which case it simply _appears_ to be
> worse to you. This effectively means that, if you think that another language
> is worse than the one you prefer, you simply cannot draw any
> conclusions.
I understand this perspective, and to a large extent, agree with it.
Let me try to express it a different way. If you talk to somebody that has
only programmed in C, and try to explain the benefits of having a built-in
garbage collector, they often just "don't get it". Don't understand how it
would aid programmer productivity. Similarly, a Java-only programmer might
not get the power of macros.
In both cases, most Lispers respond with a "higher power" argument: these are
tools that are useful in almost EVERY domain (not just one limited
application), and if you can't appreciate it, it probably means you don't
understand it.
So, I'm interested in avoiding this C/Java limited vision, but coming from
a Lisp background instead. I agree completely with you that Graham provides
no constructive way to tell the difference. He doesn't aid you at all in
understanding where you are in the middle of the power spectrum of programming
languages.
Lispers often believe themselves to be "at the top", or at least nearby.
I'm looking for pointers to generic programming language concepts that might
possibly indicate a higher-power language, but which are missing from Lisp.
Pattern-matching programming is at least a valid candidate. Prolog-style
unification and inference probably is too.
Is it so absurd to try to look beyond Lisp at programming in the abstract?
> In contrast, I find Paul Graham's ideas about "Blub" counter-enlightening.
Upon reflection, I agree with your criticism. But at least he brought up
the topic :-).
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Eagles may soar, free and proud, but weasels never get sucked into jet engines.
Don Geddis <···@geddis.org> writes:
> Lispers often believe themselves to be "at the top", or at least nearby.
> I'm looking for pointers to generic programming language concepts that might
> possibly indicate a higher-power language, but which are missing from Lisp.
> Pattern-matching programming is at least a valid candidate. Prolog-style
> unification and inference probably is too.
>
> Is it so absurd to try to look beyond Lisp at programming in the abstract?
>
>> In contrast, I find Paul Graham's ideas about "Blub" counter-enlightening.
>
> Upon reflection, I agree with your criticism. But at least he brought up
> the topic :-).
The point is whether a feature needs specific support from the core of
the lisp system (eg EVAL/COMPILE), or if you can integrate it smoothly
only by user code.
It happens that most features just don't call for any change to
EVAL/COMPILE, and can be integrated as smoonthly as wanted (using
macros or reader macros).
That's also the reason why lisp programmers can confidently say that
they're using the top notch programming language: it's very rare to
find a high level feature(*) in another programming language that cannot
be integrated into lisp with just user level code.
(*) continuations are considered a low-level feature, therefore we
don't have any scheme envy.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Don Geddis wrote:
> Pascal Costanza <··@p-cos.net> wrote on Mon, 02 Jul 2007:
>> This is one of Paul Graham's worst text fragments, IMHO (the rest of "Beating
>> the Averages is quite good, though). You can only relate to it when you think
>> that you're "up in the power continuum." However, you may simply not know
>> that others are even "higher" in the "power continuum." There are essentially
>> two possibilities: Either another language is worse than the one you prefer,
>> or you simply don't understand it, in which case it simply _appears_ to be
>> worse to you. This effectively means that, if you think that another language
>> is worse than the one you prefer, you simply cannot draw any
>> conclusions.
>
> I understand this perspective, and to a large extent, agree with it.
>
> Let me try to express it a different way. If you talk to somebody that has
> only programmed in C, and try to explain the benefits of having a built-in
> garbage collector, they often just "don't get it".
It seems to be the case that for ultra-large-scale programs, garbage
collection is not feasible anymore. (That was also the message in Jans
Aasman's talk at ILC'07.)
> Don't understand how it
> would aid programmer productivity. Similarly, a Java-only programmer might
> not get the power of macros.
Gregor Kiczales most certainly knows about the power of macros and
argues against them: http://www.ddj.com/dept/windows/184415142 (Note
that I disagree with his position, it's just to note that views may
differ even when knowing about the benefits.)
> In both cases, most Lispers respond with a "higher power" argument: these are
> tools that are useful in almost EVERY domain (not just one limited
> application), and if you can't appreciate it, it probably means you don't
> understand it.
The problem here is that you seem to confuse "higher power" with
"better". Not every increase in expressive power makes a language
better. For example, Common Lisp forbids changing source code by way of
side effects (a practice that was apparently common in previous Lisp
dialects). That's clearly a decrease in expressive power, but generally
considered an improvement of the language.
If it were that simple, that more expressive power equals better
language, then we could just look for the most expressive language and
be done with it. Unfortunately, this is not so.
This ultimately means that the decision for or against a language is
ultimately a subjective one, and depends highly on personal preferences.
For example, some of my colleagues definitely have a very good idea
about the expressive power of Lisp and Scheme dialects, but prefer to
work in Smalltalk because of its minimal set of basic language
constructs and _because_ there is no straightforward way to extend the
language (not in spite of that fact). They have good reasons for that
(to which I don't agree, but this doesn't prevent me from acknowledging
their reasons).
> So, I'm interested in avoiding this C/Java limited vision, but coming from
> a Lisp background instead. I agree completely with you that Graham provides
> no constructive way to tell the difference. He doesn't aid you at all in
> understanding where you are in the middle of the power spectrum of programming
> languages.
Yes, and it's important to understand that this is a dangerous position
to take. You should be able to explain your preferences, and not just
say "I know better than thou", without giving any good reasons. The
latter is just condescending.
We all made the experience that we were wrong about some of our choices
in the past. It is not so unlikely that we are still wrong, at least in
some regards.
Computer science is only a couple of decades old. It would be a great
surprise if we already know everything there is to know about it.
> Lispers often believe themselves to be "at the top", or at least nearby.
> I'm looking for pointers to generic programming language concepts that might
> possibly indicate a higher-power language, but which are missing from Lisp.
> Pattern-matching programming is at least a valid candidate. Prolog-style
> unification and inference probably is too.
>
> Is it so absurd to try to look beyond Lisp at programming in the abstract?
No, many of us are doing this all the time.
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/
I didn't come away with the impression that Kiczales was against
macros. More like he was saying that macros can be overused and
abused, and that they must be used judiciously. Anyhow, interesting
article in that it draws the comparison between C# and Java tags and
macro facilities. Though I suspect the Lisp community would consider
them as seriously hobbled. :-)
Chris
On Jul 2, 1:22 pm, Pascal Costanza <····@p-cos.net> wrote:
>
> Gregor Kiczales most certainly knows about the power of macros and
> argues against them:http://www.ddj.com/dept/windows/184415142(Note
> that I disagree with his position, it's just to note that views may
> differ even when knowing about the benefits.)
>
> 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/
Chris Rathman wrote:
> I didn't come away with the impression that Kiczales was against
> macros. More like he was saying that macros can be overused and
> abused, and that they must be used judiciously. Anyhow, interesting
> article in that it draws the comparison between C# and Java tags and
> macro facilities. Though I suspect the Lisp community would consider
> them as seriously hobbled. :-)
Sure. :)
Here is another data point where someone (Gilad Bracha) argues against
macro (more specifically against the inclusion of macros in Java):
http://www.artima.com/weblogs/viewpost.jsp?thread=5246
That is more outspoken than Kiczales's position.
Again, note that I don't share those views. It's just to show that
people who are aware of what macros are can be against their use, for
what they consider to be good reasons.
And to make this absolutely clear: This is in the discussion of a text
by Paul Graham which seems to suggest that there is a clear hierarchy of
programming languages in terms of better and worse in an objective
sense. That's the part I dispute. Of course, I definitely have my
subjective opinions. ;)
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> writes:
> Don Geddis wrote:
>> Is it so absurd to try to look beyond Lisp at programming in the abstract?
>
> No, many of us are doing this all the time.
To qualify: time is a finite resource. You can spend it on
exploration of new things, or "exploitation" (operations research
jargon, sorry), which in this case means learning Lisp really well.
Spending zero amount of time on exploration is possibly foolish,
because the marginal benefit of even a small amount of exploration is
large. But spending a lot or all the time exploring is also
suboptimal, since we wouldn't get anything done.
I am raising this point because many people (and trolls) come to this
list urging lispers to try their pet language and take offense when
they don't. c.l.l seems to get a heavy load of this kind of posts,
compared to, say, comp.lang.fortran. I wonder why.
Tamas
Tamas Papp wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Don Geddis wrote:
>>> Is it so absurd to try to look beyond Lisp at programming in the abstract?
>> No, many of us are doing this all the time.
>
> To qualify: time is a finite resource. You can spend it on
> exploration of new things, or "exploitation" (operations research
> jargon, sorry), which in this case means learning Lisp really well.
> Spending zero amount of time on exploration is possibly foolish,
> because the marginal benefit of even a small amount of exploration is
> large. But spending a lot or all the time exploring is also
> suboptimal, since we wouldn't get anything done.
There are quite a few libraries with well-working language extensions
for Common Lisp. So we have a rather healthy situation in that regard.
Of course, things could always be improved, but that's obvious.
> I am raising this point because many people (and trolls) come to this
> list urging lispers to try their pet language and take offense when
> they don't. c.l.l seems to get a heavy load of this kind of posts,
> compared to, say, comp.lang.fortran. I wonder why.
They take ANSI Common Lisp as the final word on Common Lisp, when it's
clearly just the starting point.
They are also used to the notion that some higher authority is typically
in charge of deciding what gets in and out of a language. This is not
the case for Common Lisp. This has both advantages and disadvantages.
Some people seem to focus on the disadvantages, but forget about the
advantages (like: an extension can be optimal for a particular problem
domain without having to be compatible with everything else, which
typically restricts what you can and cannot do in a language extension).
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 Mon, 02 Jul 2007 20:22:31 +0200, Pascal Costanza <··@p-cos.net> wrote:
> It seems to be the case that for ultra-large-scale programs, garbage
> collection is not feasible anymore.
It also seems not everybody agrees on this:
http://lukego.livejournal.com/4773.html
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Mon, 02 Jul 2007 20:22:31 +0200, Pascal Costanza <··@p-cos.net> wrote:
>
> > It seems to be the case that for ultra-large-scale programs, garbage
> > collection is not feasible anymore.
>
> It also seems not everybody agrees on this:
>
> http://lukego.livejournal.com/4773.html
And if you follow it through, Foderaro also backs away from that
claim. Which is a good thing since the claim makes no sense and I've
always considered JF a very savvy guy.
What you can say about this is something like "free wheeling _consing_
in 'ultra-large-scale' <whatever that is...> programs is a foolish
(and potentially disastrous) practice."[1] Of course, that's not
controversial or even particularly interesting, and so doesn't lend
itself to the subsequent marketing spin...
/Jon
1. Oddly enough (given the context here) there is unnecessary consing
in the lowlevel btree write code for applications that need to
handle very large low level buffering. I'm sure this only affects
applications that are "at least six sigmas out", and so is, last I
discussed with JF, a low priority item. Similar discussions
resulted in the analogous situation being completely resolved on
the read side.
--
'j' - a n t h o n y at romeo/charley/november com
Edi Weitz wrote:
> On Mon, 02 Jul 2007 20:22:31 +0200, Pascal Costanza <··@p-cos.net> wrote:
>
>> It seems to be the case that for ultra-large-scale programs, garbage
>> collection is not feasible anymore.
>
> It also seems not everybody agrees on this:
>
> http://lukego.livejournal.com/4773.html
The fact that there is disagreement proves my point.
But more to the point: I recall Guy Steele making similar statements -
something like if you have to deal with terabytes of data, garbage
collection becomes infeasible because a program starts to spend more
time on collecting garbage than on anything else. I may be
misremembering and he may have said something different, but I think it
was close to that. Unfortunately, I don't remember where I got this from...
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> writes:
>
> But more to the point: I recall Guy Steele making similar statements -
> something like if you have to deal with terabytes of data, garbage
> collection becomes infeasible because a program starts to spend more
> time on collecting garbage than on anything else.
Might that not be the result of an improper GC algorithm or improper
arrangement of memory? E.g. naïvely I wouldn't think that a terabyte
array would incur that much GC overhead, whereas 1.0995116e12 individual
bytes might very well do so.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Listening to someone who brews his own beer is like listening to a
religious fanatic talk about the day he saw the light.
--Ross Murray, Montreal Gazette, 1991
Pascal Costanza <··@p-cos.net> writes:
>
> It seems to be the case that for ultra-large-scale programs, garbage
> collection is not feasible anymore. (That was also the message in Jans
> Aasman's talk at ILC'07.)
It's unfortunate that that is what his talk appeard to emphasize.
I've read other posts on this thread, as well as following the links
through Edi Weitz's answer, and on to John Foderaro's conversation on
the sbcl mailing list (which explains better what our position and
practice is than a one-hour presentation that was too short to get
everything said that Jans wanted to say). Perhaps the blashphemous
statement was a bit of hyperbole that he made at the beginning of the
talk, which was intended more to inspire thought than to state a "new
direction". To expand on it further: consider that the term "garbage
collector" isn't even defined in the Ansi Spec, and it is used is very
few places (mostly to describe implementation-dependent actions that
functions may take involving gcs). No assumptions are made about a
garbage collector in CL, and in fact there need not be one (a
perfectly legal garbage collector might be to spawn a new lisp and
die, thus automatically removing non-ephemeral garbage very quickly).
There are no rules made in CL about manual memory management,
resourcing, or reduction of consing, though I franky have no idea why
some Lispers seem to treat these concepts as ugly or even anti-Lisp -
on the contrary: Common Lisp promotes diversity and multiple
solutions, and that is what makes it so hard to promote or eeven
describe Common Lisp, and it is what makes Common Lisp so special.
There is also a mistaken notion that gc is magic, and takes no time
when it is generational. The fallacy in this notion is due to the
fact that it is so often true: when the garbage generated is truly
ephemeral, the gc time tends to be ignorable. But what do you do when
your garbage is not ephemeral? The memory-management strategy then
becomes one of decisions made on how to deal with the data that
becomes medium-lived, and the choice that one might make to simply
generate less garbage should not be a choice that is shunned. I think
that this is what Jans was trying to get people to think about in his
talk.
>> Don't understand how it
>> would aid programmer productivity. Similarly, a Java-only programmer might
>> not get the power of macros.
>
> Gregor Kiczales most certainly knows about the power of macros and
> argues against them: http://www.ddj.com/dept/windows/184415142 (Note
> that I disagree with his position, it's just to note that views may
> differ even when knowing about the benefits.)
Chris Rathman already disagreed with your assessment, and although I
usually don't say "me too", I will do so here, only because it ties in
to what is being said about GC: I often find it to be the case that
Lispers will latch onto a concept - "X is the greatest thing in Lisp"
and then promote the use of that concept ad nauseum - when a more
experienced Lisper (such as Gregor; I'm sure you'll agree that he
has more Lisp experience than you or me combined :-) comes along and
says "well, it's not the only thing", we tend to view it as a
statement of rejection of that concept rather than a call for wisdom.
For my own experience, I got a taste of the good - and the bad - of
macros when I first started learning Lisp, in 1984 when I ported Franz
Lisp to the IBM 370 architecture while I was at Amdahl; included with
the distribution tape was an in-memory database program called pearl -
it was an exercise in extreme macrology. I found it fascinating at
first, because _everything_ was a macro; there were extremely few
actual functions in the package. But I found two problems with the
system: First, it was impossible to debug, and second, it killed the
mainframe's caches due to the extreme spread and non-locality of the
code. It was then and there that I learned to _balance_ use of
macrology and out-of-line code, and, as with any other great concept,
to use it in moderation, where it was necessary, rather than where it
was possible.
Well, I just looked back on my response, and it was much too long and
rambling. Sorry.
--
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
Duane Rettig wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> It seems to be the case that for ultra-large-scale programs, garbage
>> collection is not feasible anymore. (That was also the message in Jans
>> Aasman's talk at ILC'07.)
>
> It's unfortunate that that is what his talk appeard to emphasize.
My statement was obviously too dense. Sorry for that. If I understand
correctly, what seems to be feasible is to divide storage into different
regions which are handled differently. Some regions can be nicely
garbage collected, while others need a more manual approach, due to the
size and longevity of the data to be stored. My understanding was that
Jans's talk was about similar ideas. I have never understood it as
saying that we should get rid of garbage collection altogether.
>>> Don't understand how it
>>> would aid programmer productivity. Similarly, a Java-only programmer might
>>> not get the power of macros.
>> Gregor Kiczales most certainly knows about the power of macros and
>> argues against them: http://www.ddj.com/dept/windows/184415142 (Note
>> that I disagree with his position, it's just to note that views may
>> differ even when knowing about the benefits.)
>
> Chris Rathman already disagreed with your assessment, and although I
> usually don't say "me too", I will do so here, only because it ties in
> to what is being said about GC: I often find it to be the case that
> Lispers will latch onto a concept - "X is the greatest thing in Lisp"
> and then promote the use of that concept ad nauseum - when a more
> experienced Lisper (such as Gregor; I'm sure you'll agree that he
> has more Lisp experience than you or me combined :-) comes along and
> says "well, it's not the only thing", we tend to view it as a
> statement of rejection of that concept rather than a call for wisdom.
I think the subtext of Gregor's article is important here: It basically
tries to suggest that annotations + AOP are good enough. (While they in
fact only provide a fraction of what macros can do. At least that's how
I understand his article. It's also interesting to read his follow-up
article in that regard - see http://www.ddj.com/dept/architect/184415205
- to quote: "In April, I summarized attributes, explaining that they
introduce into C# the basic syntactic hook required to enable Lisp-style
macros.")
> For my own experience, I got a taste of the good - and the bad - of
> macros when I first started learning Lisp, in 1984 when I ported Franz
> Lisp to the IBM 370 architecture while I was at Amdahl; included with
> the distribution tape was an in-memory database program called pearl -
> it was an exercise in extreme macrology. I found it fascinating at
> first, because _everything_ was a macro; there were extremely few
> actual functions in the package. But I found two problems with the
> system: First, it was impossible to debug, and second, it killed the
> mainframe's caches due to the extreme spread and non-locality of the
> code. It was then and there that I learned to _balance_ use of
> macrology and out-of-line code, and, as with any other great concept,
> to use it in moderation, where it was necessary, rather than where it
> was possible.
Yes, these are very wise insights, but not good reasons to drop macros
altogether and replace them with something much weaker, IMHO.
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> writes:
> Duane Rettig wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>> It seems to be the case that for ultra-large-scale programs, garbage
>>> collection is not feasible anymore. (That was also the message in Jans
>>> Aasman's talk at ILC'07.)
>> It's unfortunate that that is what his talk appeard to emphasize.
>
> My statement was obviously too dense. Sorry for that. If I understand
> correctly, what seems to be feasible is to divide storage into
> different regions which are handled differently. Some regions can be
> nicely garbage collected, while others need a more manual approach,
> due to the size and longevity of the data to be stored.
Yes. When it comes down to it, memory has always been (and will
likely be for a long time, barring some inventions) a linear resource,
and dividing that linear resource into "the right size" segments for a
task is always going to be an issue. Right now, we have a new
breathing space, having expanded into the world of 64-bit addresses,
and thus the segments of memory allocation are less likely to run into
each other like they were starting to do for 32-bits, but that will
not last forever, and truly scalable programs will quickly use up this
memory space which will still have to be managed carefully.
>> My
> understanding was that Jans's talk was about similar ideas. I have
> never understood it as saying that we should get rid of garbage
> collection altogether.
That's a relief, but it's not surprising. My comment was not made to
you, per se, but to your statement, which you have now retracted but
which I have heard others say as well (and perhaps meant it when they
said it).
> I think the subtext of Gregor's article is important here: It
> basically tries to suggest that annotations + AOP are good
> enough. (While they in fact only provide a fraction of what macros can
> do. At least that's how I understand his article. It's also
> interesting to read his follow-up article in that regard - see
> http://www.ddj.com/dept/architect/184415205 - to quote: "In April, I
> summarized attributes, explaining that they introduce into C# the
> basic syntactic hook required to enable Lisp-style macros.")
Well, doesn't this suggest to you then that either he was wrong in his
implication that annotation + AOP are good enough, or that he changed
his mind, or that your understanding of his emphasis was not quite
right? Why would he be looking toward providing Lisp-style macros
unless he thought what was available was _not_ good enough? I don't
personally know what he is thinking, so I don't know which of the
three are true. And it doesn't matter much, but I have a gut feeling
that in his career as language-improvement researcher, he would tend
to _never_ call something good enough, unless it is only for the
moment.
>> It was then and there that I learned to _balance_ use of
>> macrology and out-of-line code, and, as with any other great concept,
>> to use it in moderation, where it was necessary, rather than where it
>> was possible.
>
> Yes, these are very wise insights, but not good reasons to drop macros
> altogether and replace them with something much weaker, IMHO.
Since I never advocated dropping macros, I am assuming that you are
referring to Gregor's move out of Lisp and into other languages with
AOP. It is interesting that many old Lispers move away from Lisp and
try their hand at something else - many of the Dylan inventors were
ex-lispers, who tried to fix the "problem" of Lisp's syntax (which
turned out not to be a problem at all) - others try to invent new
ways of programming altogether. Gregor seems to have moved into
an area that is more productive; taking existing languages and
retrofitting them with Lisp-like qualities. It is clear that these
retrofits will be weaker; the moment someone discovers a hybrid that
is better than Lisp, we'll probably all start moving toward that
next-generation language... But the retrofits clearly make the other
language stronger, if not as strong as Lisp.
--
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
On Jul 3, 10:38 am, Duane Rettig <····@franz.com> wrote:
Hi, Duane!
[snip]
> Since I never advocated dropping macros, I am assuming that you are
> referring to Gregor's move out of Lisp and into other languages with
> AOP. It is interesting that many old Lispers move away from Lisp and
> try their hand at something else - many of the Dylan inventors were
> ex-lispers, who tried to fix the "problem" of Lisp's syntax (which
> turned out not to be a problem at all) - others try to invent new
> ways of programming altogether.
Just a small nit to pick here: I don't think this is a very good
description of what happened with Dylan's syntax. Dylan was a language
with s-expression syntax and a working implementation for a while
before the syntax changed. It was prospective users, most of them in
Apple but not on the Dylan team, who provided the pressure for a
different syntax. The language designers were obeying their mandate to
take input from the people who were supposed to be their customers,
and a bunch of those customers wanted a different syntax.
Originally, the language was supposed to support either syntax, but in
the fullness of of time s-expressions fell away. At the time, I didn't
think syntax was a big deal, but I've changed my mind. I think the
change in syntax was a mistake. It changed Dylan from the language
that I preferred to use to one that I look at once a year or so with
mild curiosity.
······@evins.net" <···········@gmail.com> writes:
> On Jul 3, 10:38 am, Duane Rettig <····@franz.com> wrote:
>
> Hi, Duane!
Hi, Mikel. Hope you're well.
> [snip]
>
>> Since I never advocated dropping macros, I am assuming that you are
>> referring to Gregor's move out of Lisp and into other languages with
>> AOP. It is interesting that many old Lispers move away from Lisp and
>> try their hand at something else - many of the Dylan inventors were
>> ex-lispers, who tried to fix the "problem" of Lisp's syntax (which
>> turned out not to be a problem at all) - others try to invent new
>> ways of programming altogether.
>
> Just a small nit to pick here: I don't think this is a very good
> description of what happened with Dylan's syntax. Dylan was a language
> with s-expression syntax and a working implementation for a while
> before the syntax changed. It was prospective users, most of them in
> Apple but not on the Dylan team, who provided the pressure for a
> different syntax. The language designers were obeying their mandate to
> take input from the people who were supposed to be their customers,
> and a bunch of those customers wanted a different syntax.
Well, you were in a position to know, being an Apple insider. But
when two of us from Franz paid Apple a visit in Feb of 1995, with the
strong interest in taking over the product before Apple dumped it, we
had the distint impression that the people we talked to were not at
all interested in bringing back the old syntax; they gave us the
impression that the syntax had been changed for good, and that it was
part of the plan; there was no going back, and that they viewed the
situation as precisely the right direction. We also questioned them
on the state of the macro facility, and they were fairly cavalier
about it; they seemed to view it as an add-on to the language, rather
than a fundamental element of it. We went away with a sense that
their team and ours were going in completely different directions, and
we declined to take the project.
I don't know what the internal vendor/customer dynamics were, and as a
developer I understand the need to satisfy a customer (especially a
powerful, internal organization) but I also believe that it is a
developer's responsibility to defend technically the direction that he
is going - and so whether or not the developers changed their minds
midstream, or whether they were just bootstrapping from lisp syntax
into the already-conceived syntax change that had been preplanned, in
effect they are one and the same. I can also buy that they were
forced _into_ the C-like syntax, but I don't at all buy that they were
forced _out_ of the lisp syntax - lisp (and Dylan, presumably) has
always been powerful enough to support both styles, if the will to do
so is there.
> Originally, the language was supposed to support either syntax, but in
> the fullness of of time s-expressions fell away. At the time, I didn't
> think syntax was a big deal, but I've changed my mind. I think the
> change in syntax was a mistake. It changed Dylan from the language
> that I preferred to use to one that I look at once a year or so with
> mild curiosity.
Agreed. And to be fair to the times, back then everybody was trying
to keep warm in the midst of the AI/Lisp winter, and they had definite
ideas about what should be burned in order to do so. We even had
factions within Franz (all no longer with us) that tried to remove the
L word from our literature. Fortunately, they did not succeed.
--
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
On Jul 3, 7:17 pm, Duane Rettig <····@franz.com> wrote:
> ·····@evins.net" <···········@gmail.com> writes:
> > On Jul 3, 10:38 am, Duane Rettig <····@franz.com> wrote:
>
> > Hi, Duane!
>
> Hi, Mikel. Hope you're well.
As well as can be expected. :-)
> > [snip]
>
> >> Since I never advocated dropping macros, I am assuming that you are
> >> referring to Gregor's move out of Lisp and into other languages with
> >> AOP. It is interesting that many old Lispers move away from Lisp and
> >> try their hand at something else - many of the Dylan inventors were
> >> ex-lispers, who tried to fix the "problem" of Lisp's syntax (which
> >> turned out not to be a problem at all) - others try to invent new
> >> ways of programming altogether.
>
> > Just a small nit to pick here: I don't think this is a very good
> > description of what happened with Dylan's syntax. Dylan was a language
> > with s-expression syntax and a working implementation for a while
> > before the syntax changed. It was prospective users, most of them in
> > Apple but not on the Dylan team, who provided the pressure for a
> > different syntax. The language designers were obeying their mandate to
> > take input from the people who were supposed to be their customers,
> > and a bunch of those customers wanted a different syntax.
>
> Well, you were in a position to know, being an Apple insider. But
> when two of us from Franz paid Apple a visit in Feb of 1995, with the
> strong interest in taking over the product before Apple dumped it, we
> had the distint impression that the people we talked to were not at
> all interested in bringing back the old syntax; they gave us the
> impression that the syntax had been changed for good, and that it was
> part of the plan; there was no going back, and that they viewed the
> situation as precisely the right direction. We also questioned them
> on the state of the macro facility, and they were fairly cavalier
> about it; they seemed to view it as an add-on to the language, rather
> than a fundamental element of it. We went away with a sense that
> their team and ours were going in completely different directions, and
> we declined to take the project.
Nothing in this account surprises me, but 1995 is pretty late in the
game. The language-design meetings at which syntax was discussed
happened something like three or four years earlier, when the Lisp
folks had not yet been thoroughly ghoettoized within Apple.
We had a series of meetings back then in which Apple Cambridge folks
(Andrew Shalit, Jeremy Jones, Gail Zacharias, Jeff Piazza, etc. etc.)
would fly out and meet with a bunch of folks from ATG and talk about
what the language should be like. Feature after feature went in, no
problem, but the non-lispers kept asking over and over and over, "can
we get rid of the Lisp syntax?"
And eventually, designers started saying, "well, maybe, sure; what if
we add another syntax that you like better? We could support them
both, no problem." Naturally, this idea met with an enthusiastic
response from the we-hate-lisp-syntax crowd, and I said, "what the
heck? It's just syntax; why not, if it makes them happy?" And, to be
fair, the idea of languages with alternate surface syntaxes was pretty
popular back then; I wonder how many people remember that there used
to be, for example, Japanese and Italian syntaxes for AppleScript.
A couple years later the "infix syntax," as it was known, was in, but
the major projects that had been committed to Dylan were being
encouraged by management to abandon it for various reasons, and the
people who had pushed hardest for the infix syntax were sure not using
it much, if at all. By 1994 Dylan had become a non-issue in Cupertino;
nobody would have taken seriously a proposal to use it for a project,
and those projects that had been using it were told to stop (my own
project was told, "great job! you guys really showed what Dylan can
do! Now stop that and start using C++ right now."). By 1995, anything
to do with Dylan was surely in shutting-down mode, dragged along by
whatever promises and deals Apple had made before, when people who
were enthusiastic about it had more influence in the company.
By the way, the language was originally called "Ralph", and Apple paid
a large sum of money to some firm to come up with a better name for
it. All of us who were users, designers, or implementors were asked to
comment on the names, which varied from bad to awful. I remember
posting comments asking us to stay away from names that sounded like
economy cars, Japanese movie monsters, or classic bugs from CS 101. I
wish I could repeat some of them for amusement value, but maybe Apple
regards the contents of those discussions as trade secrets, I don't
know.
> I don't know what the internal vendor/customer dynamics were, and as a
> developer I understand the need to satisfy a customer (especially a
> powerful, internal organization) but I also believe that it is a
> developer's responsibility to defend technically the direction that he
> is going - and so whether or not the developers changed their minds
> midstream, or whether they were just bootstrapping from lisp syntax
> into the already-conceived syntax change that had been preplanned, in
> effect they are one and the same. I can also buy that they were
> forced _into_ the C-like syntax, but I don't at all buy that they were
> forced _out_ of the lisp syntax - lisp (and Dylan, presumably) has
> always been powerful enough to support both styles, if the will to do
> so is there.
The pressure to make it less lisp-like was relentless. It was a topic
at every single meeting attended by non-Lisp programmmers. If I were
of a cynical frame of mind I might speculate that the anti-Lisp crowd
used the addition of the infix syntax as a lever to get rid of the
hated Lisp syntax: "Why do we need to support and document 2 syntaxes?
We have a perfectly good one that ISN'T LISP. Isn't one enough? Isn't
it less work and expense to support and document just the one?"
> > Originally, the language was supposed to support either syntax, but in
> > the fullness of of time s-expressions fell away. At the time, I didn't
> > think syntax was a big deal, but I've changed my mind. I think the
> > change in syntax was a mistake. It changed Dylan from the language
> > that I preferred to use to one that I look at once a year or so with
> > mild curiosity.
>
> Agreed. And to be fair to the times, back then everybody was trying
> to keep warm in the midst of the AI/Lisp winter, and they had definite
> ideas about what should be burned in order to do so. We even had
> factions within Franz (all no longer with us) that tried to remove the
> L word from our literature. Fortunately, they did not succeed.
Hooray for that. I miss the old Dylan. I keep thinking I'll get around
to writing an implementation of a language like it, but with some
updated libraries and things. I've gone so far as to write a couple of
interpreters and a compiler for subsets of it. My exciting health
issues put a stop to that (and almost everything else) for a while,
but it's not cmpletely out of the realm of possibility that I'll
evnetually produce something along those lines, if only to please
myself. As a language qua language, the old s-expression Dylan is
still my favorite.
On Tue, 03 Jul 2007 22:22:31 -0700, ·····@evins.net wrote:
> I miss the old Dylan. I keep thinking I'll get around
> to writing an implementation of a language like it, but with some
> updated libraries and things. I've gone so far as to write a couple of
> interpreters and a compiler for subsets of it. My exciting health
> issues put a stop to that (and almost everything else) for a while,
> but it's not cmpletely out of the realm of possibility that I'll
> evnetually produce something along those lines, if only to please
> myself.
Well there is goo: http://people.csail.mit.edu/jrb/goo/ though it seems
kind of comatose at this point.
> As a language qua language, the old s-expression Dylan is still my
> favorite.
I suppose s-expression syntax is not something modern Dylan users want
to embrace. Do any current Dylan implementors still read this list?
On the other hand, if s-expression Dylan was a language a Lisper wanted to
use, it probably wouldn't be too hard to write a preprocessor using the
pretty printer in LTD: http://norvig.com/ltd/doc/ltd.html. Given Dylan's
more traditional write/compile cycle, s-expressions -> Dylan would just be
another stage. Good Old Fashioned Interactive Development (tm) would
require more work of course.
Matt
--
"You do not really understand something unless you
can explain it to your grandmother." — Albert Einstein.
On Jul 4, 1:48 am, Matthew D Swank <akopa-is-very-much-like-my-mail-
·······@c.net> wrote:
> On Tue, 03 Jul 2007 22:22:31 -0700, ····@evins.net wrote:
> > I miss the old Dylan. I keep thinking I'll get around
> > to writing an implementation of a language like it, but with some
> > updated libraries and things. I've gone so far as to write a couple of
> > interpreters and a compiler for subsets of it. My exciting health
> > issues put a stop to that (and almost everything else) for a while,
> > but it's not cmpletely out of the realm of possibility that I'll
> > evnetually produce something along those lines, if only to please
> > myself.
>
> Well there is goo:http://people.csail.mit.edu/jrb/goo/though it seems
> kind of comatose at this point.
>
> > As a language qua language, the old s-expression Dylan is still my
> > favorite.
>
> I suppose s-expression syntax is not something modern Dylan users want
> to embrace. Do any current Dylan implementors still read this list?
>
> On the other hand, if s-expression Dylan was a language a Lisper wanted to
> use, it probably wouldn't be too hard to write a preprocessor using the
> pretty printer in LTD:http://norvig.com/ltd/doc/ltd.html. Given Dylan's
> more traditional write/compile cycle, s-expressions -> Dylan would just be
> another stage. Good Old Fashioned Interactive Development (tm) would
> require more work of course.
There is a small but nonzero chance that I will eventually finish an
implementation of a (circa 1992) Dylan-like language that works in the
familiar way that Lisp programmers expect, with a REPL and incremental
compilation and so on.
There is zero chance that I will ever even start an implementation
that doesn't work that way, because I have not the slightest interest
in it.
Apple's original Dylan implementation, when the language was still
called "Ralph", was a set of extensions to MCL. In fact, an entire MCL
environment was available, with Common Lisp editors and listeners,
alongside the Dylan editors and listeners. The compiled Dylan code ran
on a differennt processor--an ARM board was ribbon-cabled to our Mac
development platforms--but aside from that, interacting with Dylan was
scarcely different from interacting with Common Lisp.
The "more traditional write/compile cycle" you refer to is just one
more reason I don't care to use current Dylan implementations.
·····@evins.net wrote:
> I miss the old Dylan. I keep thinking I'll get around
> to writing an implementation of a language like it, but with some
> updated libraries and things. I've gone so far as to write a couple of
> interpreters and a compiler for subsets of it. My exciting health
> issues put a stop to that (and almost everything else) for a while,
> but it's not cmpletely out of the realm of possibility that I'll
> evnetually produce something along those lines, if only to please
> myself. As a language qua language, the old s-expression Dylan is
> still my favorite.
I think this could even have some real impact. R6RS Scheme seems to be
turning out as a real mess (as far as I can tell), so a neater
Lisp-1-dialect could be interesting to some people. (Just speculating,
but still...)
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 2007-07-04 00:10:30 +0200, ······@evins.net" <···········@gmail.com> said:
> On Jul 3, 10:38 am, Duane Rettig <····@franz.com> wrote:
>
> Hi, Duane!
>
> [snip]
>
>> Since I never advocated dropping macros, I am assuming that you are
>> referring to Gregor's move out of Lisp and into other languages with
>> AOP. It is interesting that many old Lispers move away from Lisp and
>> try their hand at something else - many of the Dylan inventors were
>> ex-lispers, who tried to fix the "problem" of Lisp's syntax (which
>> turned out not to be a problem at all) - others try to invent new
>> ways of programming altogether.
>
> Just a small nit to pick here: I don't think this is a very good
> description of what happened with Dylan's syntax. Dylan was a language
> with s-expression syntax and a working implementation for a while
> before the syntax changed. It was prospective users, most of them in
> Apple but not on the Dylan team, who provided the pressure for a
> different syntax. The language designers were obeying their mandate to
> take input from the people who were supposed to be their customers,
> and a bunch of those customers wanted a different syntax.
>
> Originally, the language was supposed to support either syntax, but in
> the fullness of of time s-expressions fell away. At the time, I didn't
> think syntax was a big deal, but I've changed my mind. I think the
> change in syntax was a mistake. It changed Dylan from the language
> that I preferred to use to one that I look at once a year or so with
> mild curiosity.
I was just thinking about it today: is there a HTML version of
the first Dylan Interim Reference Manual? The one with
Lisp syntax/semantics?
This one:
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/others/dylan/doc/manual/0.html
--
http://lispm.dyndns.org/
On Jul 3, 4:47 pm, Rainer Joswig <······@lisp.de> wrote:
> On 2007-07-04 00:10:30 +0200, ·····@evins.net" <···········@gmail.com> said:
> > Originally, the language was supposed to support either syntax, but in
> > the fullness of of time s-expressions fell away. At the time, I didn't
> > think syntax was a big deal, but I've changed my mind. I think the
> > change in syntax was a mistake. It changed Dylan from the language
> > that I preferred to use to one that I look at once a year or so with
> > mild curiosity.
>
> I was just thinking about it today: is there a HTML version of
> the first Dylan Interim Reference Manual? The one with
> Lisp syntax/semantics?
>
> This one:http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/others/dyl...
There sure is, because I have it (along with a stack of paper copies,
stored 1200 miles from where I now live). But I don't remember where I
got it, and don't know where you can find it.
Apple Computer claims the copyright; maybe if you could find the right
person there you could wangle permission to reproduce it, in which
case I could send you a copy of what I have. My past attempts to get
Apple to give permission to reproduce the Bauhaus code (the OS code we
were writing in Dylan) met with no success. Basically I think folks at
Apple are not interested in spending the time to find out whether
allowing copies is a good idea or not.
On Jul 3, 4:47 pm, Rainer Joswig <······@lisp.de> wrote:
[snip]
> I was just thinking about it today: is there a HTML version of
> the first Dylan Interim Reference Manual? The one with
> Lisp syntax/semantics?
Hi, Rainer!
I stumbled across a webbed copy of the old DIRM today. It's here:
http://oop.rosweb.ru/dylan/book.annotated/contents.html
In article <························@w3g2000hsg.googlegroups.com>,
······@evins.net" <···········@gmail.com> wrote:
> On Jul 3, 4:47 pm, Rainer Joswig <······@lisp.de> wrote:
>
> [snip]
>
> > I was just thinking about it today: is there a HTML version of
> > the first Dylan Interim Reference Manual? The one with
> > Lisp syntax/semantics?
>
> Hi, Rainer!
>
> I stumbled across a webbed copy of the old DIRM today. It's here:
>
> http://oop.rosweb.ru/dylan/book.annotated/contents.html
Cool! Thanks!
It is just so much better than the later one...
--
http://lispm.dyndns.org
In article <························@w3g2000hsg.googlegroups.com>,
······@evins.net" <···········@gmail.com> wrote:
> On Jul 3, 4:47 pm, Rainer Joswig <······@lisp.de> wrote:
>
> [snip]
>
> > I was just thinking about it today: is there a HTML version of
> > the first Dylan Interim Reference Manual? The one with
> > Lisp syntax/semantics?
>
> Hi, Rainer!
>
> I stumbled across a webbed copy of the old DIRM today. It's here:
>
> http://oop.rosweb.ru/dylan/book.annotated/contents.html
Btw.,
for those interested, there was a real big project
in Germany written in (new) Dylan:
http://www-i2.informatik.rwth-aachen.de/lufgi2/fp02/Folien/Dylan.pdf
Project FIM for GEMA
- Central application of the company
- About 50 person-years development effort
- About 4 million lines of code written completely in Dylan
- 1.5 million lines of code for technical framework
- 2.5 million lines of code for the application
- About 400 dialogs and 45 batches
- About 800 persistent classes (tables) in the underlying database
- Some tables have about 30 million entrie
--
http://lispm.dyndns.org
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Don Geddis wrote:
> > Pascal Costanza <··@p-cos.net> wrote on Mon, 02 Jul 2007:
> >> This is one of Paul Graham's worst text fragments, IMHO (the rest of "Beating
> >> the Averages is quite good, though). You can only relate to it when you think
> >> that you're "up in the power continuum." However, you may simply not know
> >> that others are even "higher" in the "power continuum." There are essentially
> >> two possibilities: Either another language is worse than the one you prefer,
> >> or you simply don't understand it, in which case it simply _appears_ to be
> >> worse to you. This effectively means that, if you think that another language
> >> is worse than the one you prefer, you simply cannot draw any
> >> conclusions.
> >
> > I understand this perspective, and to a large extent, agree with it.
> >
> > Let me try to express it a different way. If you talk to somebody that has
> > only programmed in C, and try to explain the benefits of having a built-in
> > garbage collector, they often just "don't get it".
>
> It seems to be the case that for ultra-large-scale programs, garbage
> collection is not feasible anymore. (That was also the message in Jans
> Aasman's talk at ILC'07.)
For a lot of software naive consing and using naive Garbage Collection
was never feasible.
Reducing consing has a long history. Just check out the manual
of the MIT Lisp Machine. Specifically the chapters
on memory management and areas. This is probably more than
25 years old. I think it is easy to see that Garbage Collection
is not THE single method of memory management. Even
Garbage Collection? Which one? Once you write any program
that has certain demands on memory management, you see
that the 'simple' garbage collection won't do it.
It has nothing to do with 'ultra-large scale'.
Say, you have a 3d Modeller for complex models.
Do you want to see GCs during interaction?
You have a disk driver. GCs during disk read and write?
There are lots of situations where the user don't want to
see delays. There are also lots of situations where
consing reduces the system performance in situations
not easy to see (reduced throughput in networking or
writing to disk, ...).
A few examples:
* a TCP stack. Packets as objects. Plain memory management?
Probably not, you want fast allocation and you want
them to be wired in memory.
Cost of varying access times?
* 24/32bit (or larger) deep bitmaps with tens or
hundreds of mega-bytes of space needed for image processing.
You really want to reallocate them when you need new?
The Lisp Machine had special datatypes for bitmaps
and special storage areas for them.
Cost of reinitialization? Cost of getting fresh memory?
* large amount of pointers in data structures. Think
objects pointing to other objects. Do you really want
them to be scattered across your address space?
How about locality of data?
* (Almost?) no production-quality Lisp has a concurrent GC.
What is with (near) real-time demands? How to
have bounds on the time used for incremental GC?
* You may need more data than what fits into main memory.
How to make sure that the GC doesn't create
bad paging behavior?
In web-applications you can sometimes get away with
many small GCs. Or you can pre-allocate all data-structure.
"On the Internet, nobody knows you are a dog." ;-)
Users will see nothing or only effects that are similar to
other factors contributing to latency. So a simple
app might not be a problem. These are the same apps
people write in languages like Python, Ruby, ...
which are often one or two orders of magnitudes slower
and have relatively primitive memory management
(reference counting and up).
But when you start using
CLOS and you have lots of changing domain data,
say, you cons lots of memory at page creation time and so
on - then you want to introduce simple user-level
optimizations (stack allocation, memoization, resources,
destructive operations, ...). If that doesn't help, then it gets
tricky.
--
http://lispm.dyndns.org
Rainer Joswig wrote:
> Say, you have a 3d Modeller for complex models.
> Do you want to see GCs during interaction?
This is exactly the kind of work that we do and OCaml's incremental GC
or .NET's concurrent GC handle it very well.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Pascal Costanza wrote:
> Don Geddis wrote:
[...]
Also it is important to repeat again and again that the design space of
computer languages is multi-dimentional. There's not a single line from
"sucks" to "superior abstraction".
From concise/obfuscated to verbose/readable, from imperative to
functional, from dynamic typing/exploratory to static typing/static
checks... pick a point in all these dimensions (and others), and the
rest of the language will flow from these.
The local extremum quote from McCarthy says it all.
Sacha
Pascal Costanza <··@p-cos.net> writes:
> Also: There is nothing special about being "up in the power
> continuum." Just because most languages suck nowadays doesn't mean
> that you're special because you happen to know a language that doesn't
> suck that much. The ideas behind Lisp are only mind blowing when
> compared to more mainstream languages. In 200 years from now, though,
> these ideas will be regarded as trivial.
The 200 year assertion is interesting. Since modern day languages
(english compared to say, phoenician) are not that different then
their 5000 year old ancestors, how can that assertion be made?
Computer languages (so far) are about human expression and
communication. People try to "tell" a machine to do something and
machines being thick as a brick do not cooperate very well. This is
compounded by people not really knowing what they are saying and you
end up with hands waving around in grand style.
I suppose the next step are programs that are more introspective, that
know what they are doing. Then instead of just "knowing" what they
are supposed to do they also know and discover what they are "not"
supposed to do. Its the negative space knowledge that programs lack.
You even see that with programs now, ones that have better error
checking and detection have better running behaviour. That is a
simple example but things like "search" can be greatly improved by the
program being critical of its own operations and learning what not to
do.
Wade
Wade Humeniuk wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Also: There is nothing special about being "up in the power
>> continuum." Just because most languages suck nowadays doesn't mean
>> that you're special because you happen to know a language that doesn't
>> suck that much. The ideas behind Lisp are only mind blowing when
>> compared to more mainstream languages. In 200 years from now, though,
>> these ideas will be regarded as trivial.
>
> The 200 year assertion is interesting. Since modern day languages
> (english compared to say, phoenician) are not that different then
> their 5000 year old ancestors, how can that assertion be made?
> Computer languages (so far) are about human expression and
> communication. People try to "tell" a machine to do something and
> machines being thick as a brick do not cooperate very well. This is
> compounded by people not really knowing what they are saying and you
> end up with hands waving around in grand style.
...but we are not doing science about natural languages in the same way
as we do science about programming languages. Except for very few
examples (like Esperanto), we don't try to come up with new natural
languages / language constructs and try to study in what ways they make
things more or less convenient.
My hope is that, like in other sciences and engineering disciplines,
there will be shifts in perspectives.
> I suppose the next step are programs that are more introspective, that
> know what they are doing. Then instead of just "knowing" what they
> are supposed to do they also know and discover what they are "not"
> supposed to do. Its the negative space knowledge that programs lack.
> You even see that with programs now, ones that have better error
> checking and detection have better running behaviour. That is a
> simple example but things like "search" can be greatly improved by the
> program being critical of its own operations and learning what not to
> do.
Interesting.
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> writes:
>
>> I suppose the next step are programs that are more introspective, that
>> know what they are doing. Then instead of just "knowing" what they
>> are supposed to do they also know and discover what they are "not"
>> supposed to do. Its the negative space knowledge that programs lack.
>> You even see that with programs now, ones that have better error
>> checking and detection have better running behaviour. That is a
>> simple example but things like "search" can be greatly improved by the
>> program being critical of its own operations and learning what not to
>> do.
>
> Interesting.
>
>
Marvin Minsky has a good draft chapter on this kind of
thing.
http://web.media.mit.edu/~minsky/E5/eb5.html
and another thesis, (which has some Lisp in it).
http://web.media.mit.edu/~push/push-thesis.pdf
Wade
Madhu <·······@meer.net> writes:
> (computers)
> %
> ... in three to eight years we will have a machine with the general
> intelligence of an average human being ... The machine will begin
> to educate itself with fantastic speed. In a few months it will be
> at genius level and a few months after that its powers will be
> incalculable ...
> -- Marvin Minsky, LIFE Magazine, November 20, 1970
It hurts to be right too soon...
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
I was angry when that article came out, because it was filled with
misquotations from an interview. I'm not sure where the interviewer
got this "quote"; perhaps I said '3 to 8 decades' or I was making a
joke, or I was describing the scenario from D.F.Jones's SF novel
entitled "Colossus." (It became the movie, The Forbin Project.)
Anyway, I sent an angry rebuttal to Life Magazine, but they declined
to publish it.
However, it does seem likely that a modern computer could develoe very
rapidly--once it has learns the right kinds of things to learn.
(That's the problem we call "credit assignment.") However, the
earlier versions will all have serious bugs, so we'll surely need to
reprogram them many times before they will work well on their own.
On Jul 4, 12:34 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Madhu <·······@meer.net> writes:
> > (computers)
> > %
> > ... in three to eight years we will have a machine with the general
> > intelligence of an average human being ... The machine will begin
> > to educate itself with fantastic speed. In a few months it will be
> > at genius level and a few months after that its powers will be
> > incalculable ...
> > -- MarvinMinsky, LIFE Magazine, November 20, 1970
>
> It hurts to be right too soon...
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NOTE: The most fundamental particles in this product are held
> together by a "gluing" force about which little is currently known
> and whose adhesive power can therefore not be permanently
> guaranteed.
·······@media.mit.edu" <······@media.mit.edu> writes:
> On Jul 4, 12:34 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>> Madhu <·······@meer.net> writes:
>> > (computers)
>> > %
>> > ... in three to eight years we will have a machine with the general
>> > intelligence of an average human being ... The machine will begin
>> > to educate itself with fantastic speed. In a few months it will be
>> > at genius level and a few months after that its powers will be
>> > incalculable ...
>> > -- MarvinMinsky, LIFE Magazine, November 20, 1970
>>
>> It hurts to be right too soon...
>
> I was angry when that article came out, because it was filled with
> misquotations from an interview. I'm not sure where the interviewer
> got this "quote"; perhaps I said '3 to 8 decades' or I was making a
> joke, or I was describing the scenario from D.F.Jones's SF novel
> entitled "Colossus." (It became the movie, The Forbin Project.)
> Anyway, I sent an angry rebuttal to Life Magazine, but they declined
> to publish it.
>
> However, it does seem likely that a modern computer could develoe very
> rapidly--once it has learns the right kinds of things to learn.
> (That's the problem we call "credit assignment.") However, the
> earlier versions will all have serious bugs, so we'll surely need to
> reprogram them many times before they will work well on their own.
Yes, I wanted to stress more the "right". Today, this quote doesn't
seem impossible anymore, with computer hardware predicted to become
as powerful as our brains soon.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal Bourguignon wrote:
> ·······@media.mit.edu" <······@media.mit.edu> writes:
>
>>On Jul 4, 12:34 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>>
>>>Madhu <·······@meer.net> writes:
>>>
>>>>(computers)
>>>>%
>>>>... in three to eight years we will have a machine with the general
>>>>intelligence of an average human being ... The machine will begin
>>>>to educate itself with fantastic speed. In a few months it will be
>>>>at genius level and a few months after that its powers will be
>>>>incalculable ...
>>>> -- MarvinMinsky, LIFE Magazine, November 20, 1970
>>>
>>>It hurts to be right too soon...
>>
>>I was angry when that article came out, because it was filled with
>>misquotations from an interview. I'm not sure where the interviewer
>>got this "quote"; perhaps I said '3 to 8 decades' or I was making a
>>joke, or I was describing the scenario from D.F.Jones's SF novel
>>entitled "Colossus." (It became the movie, The Forbin Project.)
>>Anyway, I sent an angry rebuttal to Life Magazine, but they declined
>>to publish it.
>>
>>However, it does seem likely that a modern computer could develoe very
>>rapidly--once it has learns the right kinds of things to learn.
>>(That's the problem we call "credit assignment.") However, the
>>earlier versions will all have serious bugs, so we'll surely need to
>>reprogram them many times before they will work well on their own.
>
>
> Yes, I wanted to stress more the "right". Today, this quote doesn't
> seem impossible anymore, with computer hardware predicted to become
> as powerful as our brains soon.
>
Nonsense. Computers are nothing like brains and advances are not making
them any more like brains. The only thing we can be sure of is that we
do not even know yet how brains work. This is like observing Deep Blue
beating Kasparov and claiming to have made the first step towards
matching human intelligence.
The original claims for AI arose from egocentric arrogance, with
extremely bright people snorting at the idea that the brain might be
cleverer than they. Brains have yet to see any interesting results out
of these geniuses.
They are, however, quietly concerned over Cells. :)
kt
On 5052 September 1993, Don Geddis wrote:
> OK, so now the question. Common Lisp was formalized quite some time ago;
> ANSI CL a bit later, but without many radical changes. Are there tools now
> known in the abstract space of programming language design that "ought" to be
> part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
> surely have been strongly suggested to get added to the language?
Don, a lot of people have pointed you in the direction why the
question to begin with is questionable. I'll won't do that but still I
won't answer your question, so this probably hints also that there is
something basic problem with your question.
> I'd like to distinguish this from libraries or specific applications, which
> are easy enough to layer on top of existing ANSI CL.
I believe that this restriction is too strong. A lot of stuff at least
started as a set of CL application or library.
> Things like "iteration" or "recursion" or "CLOS".
Well, iteration and recursion isn't really something to be taken from
the language specification. And CLOS is implemented/implementable in
CL.
> Regular expression matching, which is missing from the ANSI CL standard, is
> probably of this "edge" class and would have been included in a CL2. Maybe
> multiprocessing too.
But this is not a sharp boundary -- take PPCRE, which is a CL
library. Multiprocessing on the other hand is very likely not
implementable without considerable effort if the CL implementation
doesn't provide at least basic support.
> And the pattern-matching programming idea got me thinking of
> unification.
You do know that there are (I think several) libraries implementing
unification in CL?
> At one time, people touted Prolog as the future of programming
> languages. Very, very different from Lisp, and hugely useful when
> it applies. I think Prolog failed as a general purpose programming
> language, but should that technology be part of the bag of tricks
> available to every Lisp programmer? Unification and inference is
> probably a generalization of the pattern-matching idea.
JFTR, Mercury, which started out as a better Prolog, includes a lot of
features typically offered by functional languages. Still, it hasn't
really attracted a lot of new users. And for inference, there are
literally myriads of inferencing systems implemented in Lisp.
What I want to say is that this stuff is already available.
Holger
--
--- http://hillview.bugwriter.net/ ---
"Time flies Time crowls Like an insect Up and down the walls.
The conspiracy of silence ought to revolutionise My thought."
-- Magazine, "The light pours out of me"
Holger Schauer wrote:
> You do know that there are (I think several) libraries implementing
> unification in CL?
As are there libraries/preprocessors/other tools implementing GC for C,
AOP for Java, and so on. I think the more important question is not
whether you /can/ do $foo in Lisp, but whether the typical Lisp
programmer would want to/know when to.
-dan
Daniel Barlow wrote:
> Holger Schauer wrote:
>> You do know that there are (I think several) libraries implementing
>> unification in CL?
>
> As are there libraries/preprocessors/other tools implementing GC for C,
> AOP for Java, and so on. I think the more important question is not
> whether you /can/ do $foo in Lisp, but whether the typical Lisp
> programmer would want to/know when to.
Exactly.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
In article <···············@elendil.holgi.priv>,
Holger Schauer <··············@gmx.de> wrote:
> On 5052 September 1993, Don Geddis wrote:
> > OK, so now the question. Common Lisp was formalized quite some time ago;
> > ANSI CL a bit later, but without many radical changes. Are there tools now
> > known in the abstract space of programming language design that "ought" to be
> > part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
> > surely have been strongly suggested to get added to the language?
>
> Don, a lot of people have pointed you in the direction why the
> question to begin with is questionable. I'll won't do that but still I
> won't answer your question, so this probably hints also that there is
> something basic problem with your question.
>
> > I'd like to distinguish this from libraries or specific applications, which
> > are easy enough to layer on top of existing ANSI CL.
>
> I believe that this restriction is too strong. A lot of stuff at least
> started as a set of CL application or library.
>
> > Things like "iteration" or "recursion" or "CLOS".
>
> Well, iteration and recursion isn't really something to be taken from
> the language specification. And CLOS is implemented/implementable in
> CL.
Not without system dependent stuff.
--
http://lispm.dyndns.org
Don Geddis <···@geddis.org> writes:
> OK, so now the question. Common Lisp was formalized quite some time ago;
> ANSI CL a bit later, but without many radical changes. Are there tools now
> known in the abstract space of programming language design that "ought" to be
> part of Common Lisp? That, if there had been an ANSI CL 2 effort, would
> surely have been strongly suggested to get added to the language?
>
> Regular expression matching ...
>
> Static typing is another interesting corner case....
>
> And the pattern-matching programming idea got me thinking of unification...
>
> So I'm wondering about language expressions that are so fundamental to
> describing computation, that they "ought" to be part of the vocabulary of any
> advanced programmer.
>
The concept of a computer programming language is pretty
much played out. The progression through machine code,
assembly, C, Lisp has traversed a conceptual space all the
way to its boundary. It is time to strike out in a new
direction.
The two issues are
1)Programming is the boundary activity, separating the
manual from the automatic.
2)The conflict between writing clear, simple code and
writing efficient code.
Think of the document flow in an organisation. There are
discussions with customers. Requirements are
analysed. Software products are proposed and discussed. Lots
of documents are written and rewritten.
Think about a change to the requirements. The author of the
software product proposal responds to the the change by
thinking through its implications and manually amending his
proposal.
Constrast the relationship between source code and assembler
listing with the relationship between requirements and
proposal. When the source code changes the programmer
merely reruns the compiler. The production of documents
``below'' the level of the computer programming language has
been automated.
A computer programming language marks a boundary between the
manual and the automatic and the goal of ``improving'' a
computer programming language is to shift this boundary
higher up the business, automating what was previously
manual.
Let me make this more concrete with an admittedly
hypothetical example. A finance company must respond to tax
changes by changing the programs that calculate tax. It
wants to obtain the taxation statutes in machine readable
form and run a program that extracts the new rates and
updates the code. If the tax changes are just adjustments to
numerical parameters this is within the grasp of current
technology, but when for example, Gordon Brown splits the
tax on cars into bands according to fuel efficiency, the
code base much change more radically.
The finance company wants to "program" its computers in a tax
law programming language. Realistically I'm imagining an
extra level of complication. There is a hairy program,
perhaps in Common Lisp, that compiles TLPL (my hypothetical
Tax Law Programming Language) into Common Lisp. This is the
standard idea of a domain specific programming language and
Common Lisp, with its defmacro, is about as good as it gets.
Attempts to think about improving computer programming
languages falter because they conceive of the issue in terms
of writing programs, but the goal is the opposite of
this. The goal is to NOT write programs. Programming in the
conventional sense is to be automated away. To put it in
boring terms, programming's future is to split into three. One
part is writing compilers for languages closer to the
business needs of the customers who pay the bills. Another
part is using those languages. The third part is ``paddling
up waterfalls''. A waterfall model with the compiler writers
presenting the completed language to those who must program
in it is implausible.
So far I articulated my vision in familiar language. Instead
of application programmers writing applications we have
compiler writers writing compilers, application programmers
writing application in application specific languages, and
some guys paddling up waterfalls. My vision is vague.
It is also incoherent as written. The term "compiler writer"
still has its old meaning, writing programs that turn C or
CL into assembler. I should not be reusing it to mean
something else. Much the same problem applies to my use of
the phrase "application programmer". It is only the job
description "waterfall paddler" that is honest in its
novelty and vagueness.
To see the difficulties, think about Ruby on Rails. Is it
created by compiler writers? Not really. What do power users
do with it? I don't think it is being leveraged to build
more elaborate websites. I think that canny programmers are
using it to spend less time coding and more time thinking
about how to make money.
Lets call the three roles
1)Business programmer: he writes in the domain specific
language, but spends more time understanding customers
than he does understanding computers
2)Transformation programmer: Like a compiler writer except
that Common Lisp is the object language not the source
language
3)Waterfall paddler: My lack of explicitness here reveals a
major weakness in my thinking. This is a post to a
newsgroup, you haven't paid $100 for a book :-)
The Business Programmer is writing clear, simple code. Perhaps
the naive interpretation of the code is as an inefficient
algorithm that runs too slowly, but the business programmer
has no time to spend rewriting it to run faster. He is out
of the office talking to customers. When he comes back he
will change it to keep up with a fast changing world, not to
fix efficiency problems.
What about the Transformation Programmer? Does he rewrite
the code himself to make it run faster? Absolutely
not. ``Programming'' = ``writing code'' is what we are trying to
eliminate, or more precisely automate. Remember that
tomorrow the Business Programmer will change key Business
Declarations. All the effort put into manual tuning will be
lost. The Transformation Programmer aims to come up with a
transformation that turns today's Business Declarations into
efficient code, but is not so tightly tuned that the
transformation breaks tomorrow. The waterfall paddler tries
to optimise a tricky trade-off. The transformations must be
general enough to survive tomorrows changes, but if this
vision is to be practical them must be done in a way that
keeps well away from attempting to build a general artifical
intelligence. Some-one must distinguish the likely changes
from the unlikely changes in a way that permits a trade-off:
being less prepared for unlikely changes buys being more
prepared for likely changes.
Technology and Implementation
-----------------------------
I've recast the problem. It is no longer about creating
better, fixed languages for writing applications. It is
about better tools for writing optimising
compilers. Especially about having more flexible tools so
that an efficiency problem is not solved by changing the
source, but by adding extra transformations to the compiler
on an as needed basis.
How might this be possible. The work that stikes me as
exciting and mysterious is that of Futamura.
http://www.cubiclemuses.com/cm/blog/archives/000419.html
If the transformation programmer's tool chest includes a
reasonably powerful language (RPL) that comes with a partial
evaluator and a native code compiler, he uses it to write an
interpreter for the business language, then uses the first
futamura projection to get a native code compiler for free,
by partially evaluating the business declarations with the
interpreter to get RPL that can be compiled to native code.
I think that this kind of staged approach covers the issues
of pattern matching and static typing.
It is easy enough to write code that matches data structures
at run time. So you can write an interpreter for a pattern
matching language. You can even write macros that expand to
calls to a pattern matching routine, so you can add pattern
matching to a compiled language and only take the
interpretive performance hit in code that actually uses the
pattern matching. It you write the pattern matcher in a
language for which you have a partial evaluator, you can
partially evaluate the pattern matching code with the
pattern list at macro expansion time and get full
compilation.
I think that something similar happens with static
typing. Much of the type checking overhead is removed by
partial evaluation, because the types are independent of the
actual data. One can even regard the elimination of type
checks as the criteria for whether the code is well typed.
Notice that if the Business Programmer wants a more
expressive type system or more elaborate pattern matching,
the Transformation Programmer is in a position to offer this
because he is hacking an interpreter for which he has a
partial evaluator.
There are interesting issues with regular expressions. My
Perl book gives the example of matching
"aaaaab" against /a*a*a*a*a*[b]/
and warns that leaving of the "b" and just matching against
"aaaaa" will take too long to fail. This is the kind of
conflict between clarity and efficiency that makes
programming an all consuming technical activity. It does
strike me that there is something wrong here. Regular
expressions are a subset of context free languages and the
Earley algorithm parses context free grammars in at worst
cubic time, so I don't understand Larry Wall's hint these
kinds of expression take exponential time.
I've come across this issue before with a computer
programming language called REFAL. It is very attractive,
because the built-in pattern matching subsumes most
looping. Unfortunately it does not live up to its promise
because there are various ways that clear code can be unbearably
inefficient. The manual has to go into some detail of how
certain obvious ways of matching have quadratic performance
and how to write non-obvious code to get linear performance.
In future the Business Programmer will not obfuscate the
Business Declarations to obtain performance, he will get the
Transformation Programmer to fix the regular expression
matching engine (either with a better algorithm or by adding
special case code to handle common troublesome
situations). Transformations from quadratic to linear will
be done by adding transformations to the optimiser, not
obfuscating the source code. (The source code might well
need declarations saying that linear performance is needed in
one parameter of a function but not in another. It might
even need to include a hint about how the transformation is
to be done.)
The big obstacle to this vision is that deep within the
partial evaluator lurks a theorem prover, and it is the
strength of this theorem prover that determines whether the
partial evaluation of an interpreter with source is actually
compiling.
I'm intrigued by what I have read of ACL2. It seems that it
is not very smart "out of the box". You ask it to prove a
theorem and it cannot manage it. You ask it to prove a well
chosen lemma and it manages the lemma. Now the lemma is
added to its stock of theorems, and when you return to the
main theorem it is able to prove it automatically. One
feature of this kind of dialogue is that you cannot break it
by accidently teaching it a false lemma. You can only build
its stock of theorems incrementally by getting it prove them
for itself and working up.
What fascinates me is that I'm not looking for artificial
intelligence. I'm only expecting to automate processes that
are currently routinely done manually. I'm not expecting
automated tools to come up with a program transformation
that the Transformation Programmer would not have done
himself in the old days. I'm imagining that the
Transformation Programmer doesn't write transformations in
the style of defmacro function bodies. Instead he comes up
with a series of lemmas that get the ACL2 like theorem
prover inside the partial evaluator up to the point that it
can carry out the transformation. There is then a good
chance that when the Business Declarations change, the
theorem prover will be able to prove the trivial variant
needed to optimise the new code all on its own.
So here is a radical vision for what computer programming
looks like in 2027.
The Business Programmer writes clean, clear code. Probably
declarative code. It might look a lot like Prolog, but
actually it will be very different. Naively written Prolog
often triggers the backtracking search producing
exponentially awful programs. The Business Programmer will
not personally have to worry about this and will never
obfuscate his code for efficiency.
The necessary transformations are never done manually. The
Transformation Programmer engages in a Socratic dialog with
the theorem prover inside the partial evaluator, leading it
to see how to transform the code to make it efficient.
Source control means both the Business Declarations and the
Lemma List. Today creative engineers must consider the
software/hardware trade-off. In future the Waterfall Paddler
must design the domain specific language by trading off the
complexity of the Business Declarations against the length
of the Lemma List and the difficulty of constructing it.
Now I can explain why I am not very interested in improving
Common Lisp. It is not that I think that Common Lisp is the
last word in computer programming languages. Far from it. I
have the opposite concern. I look forward to radical
developments. The tool chain underpining future languages
might well be written first time around in Common Lisp, but
I look forward to those languages being very different
indeed. For example the semantics of partial evaluation
would be part of the specification. If the Lemma List is to
be part of the program source, then the specification of the
language would have to include minimum capabilities for the
theorem prover inside the partial evaluator and say how to
dialogue with it. That is not sounding like anything one can
reach by further development of Common Lisp.
Is Common Lisp a Blub? It will be.
Alan Crowe
Edinburgh
Scotland
On Tue, 03 Jul 2007 01:33:46 +0100, Alan Crowe wrote:
> The work that stikes me as exciting and mysterious is that of Futamura.
Whenever I see references to Futamura, I always have to read the
reference two or three times. This is because I invariably see the text
as a reference to the *Futurama* projection.
However, you can see why this mistake is an easy one to make: Futurama is
also prominent in programming language theory.
Matt
--
"You do not really understand something unless you
can explain it to your grandmother." - Albert Einstein.
Don Geddis wrote:
> Probably most of us are familiar with Paul Graham's hypothetical "Blub"
> language, as described in the section "The Blub Paradox" in the middle of
> http://paulgraham.com/avg.html
> It was a hypothetical example to show how some programmers, only used to
> languages less powerful than Lisp, might not appreciate the power of Lisp,
> simply because they don't understand those features of Lisp that their own
> favorite language lacks.
Blub doesn't exist. It is based upon the assumption that programming
language power is a one-dimensional function when it clearly is not.
Problem solving efficiency is the real holy grail. This is even more
complicated because it is also a function of what you are doing.
So people should ask "is Lisp the most efficient language to solve my
problems?".
I personally cannot think of a single application that Common Lisp is well
suited to. Indeed, I constantly post example programs written in various
languages that cannot be translated into Lisp without becoming long,
obfuscated and slow. I cannot remember ever having seen an example where a
problem can be solved more succinctly, elegantly and efficiently in Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
From: Dimiter "malkia" Stanev
Subject: Re: Is Lisp a Blub? (LZO Decompression In Common Lisp vs. the original C)
Date:
Message-ID: <468AD08D.9030903@mac.com>
This is a multi-part message in MIME format.
--------------020503040505040107050206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Somehow I don't agree with you. I'm still learning the language,
although I have 15+ years experience with the likes of C/C++, Basic and
Pascal.
I was able to translate the LZO (lzo1x to be more precise) decompression
algorithm to Common Lisp, and it was only 2.4 slower (lispworks
professional 5.02/x86 on HP xw8400 workstation running Windows XP). It
came down to finding (disassemble'ing much) what options are good, and
testing. I can imagine other lisp systems might do better (SBCL, CMUCL),
given more specifics (optimization flags, or other things). The
unoptimized version is 24 times slower.
Now it was slower, because in "C" on x86 you can cheat and copy 4 bytes
at a time, even when they are not aligned, and that's what the clever
lZO "C" code is doing (Markus Oberhumer [1] is really a kind of genius,
his code is one of the most effective I've ever saw). The lisp version
was copying byte by byte, as you can't lie to the system about it
(although vendor specific extensions might provide such tricks).
Now I've did some mistakes at the beginning for example, declaring the
type of the byte array to be "(simple-array (unsigned-byte 8))" instead
of "(simple-array (unsigned-byte 8) 1)" or "(simple-array (unsigned-byte
8) (*))" but this was due to my inexperience, now I know where that's
needed and when not (or I believe so).
I've attached the code for your refference. It's not finished, so you
won't be able to run it. It was based on the java version [2] of the
decompressor (the "C" one is full with C macros, and after preprocessing
on my machine it uses the 4 bytes unaligned copy trick which as I've
said works only on x86 machines, and only "correctly" in C).
[1]
http://www.oberhumer.com/opensource/lzo/
[2]
http://www.oberhumer.com/opensource/lzo/download/LZO-v1/java-lzo-1.00.tar.gz
Jon Harrop wrote:
> Don Geddis wrote:
>> Probably most of us are familiar with Paul Graham's hypothetical "Blub"
>> language, as described in the section "The Blub Paradox" in the middle of
>> http://paulgraham.com/avg.html
>> It was a hypothetical example to show how some programmers, only used to
>> languages less powerful than Lisp, might not appreciate the power of Lisp,
>> simply because they don't understand those features of Lisp that their own
>> favorite language lacks.
>
> Blub doesn't exist. It is based upon the assumption that programming
> language power is a one-dimensional function when it clearly is not.
>
> Problem solving efficiency is the real holy grail. This is even more
> complicated because it is also a function of what you are doing.
>
> So people should ask "is Lisp the most efficient language to solve my
> problems?".
>
> I personally cannot think of a single application that Common Lisp is well
> suited to. Indeed, I constantly post example programs written in various
> languages that cannot be translated into Lisp without becoming long,
> obfuscated and slow. I cannot remember ever having seen an example where a
> problem can be solved more succinctly, elegantly and efficiently in Lisp.
>
--------------020503040505040107050206
Content-Type: text/x-lisp-source;
name="lzo-decompress.lisp"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="lzo-decompress.lisp"
;;; lzo-decompress.lisp -- Based on
;;;
;;; Lzo1xDecompressor.java -- implementation of the LZO1X decompression algorithm
;;;
;;; This file is part of the LZO real-time data compression library.
;;;
;;; Copyright (C) 1999 Markus Franz Xaver Johannes Oberhumer
;;; Copyright (C) 1998 Markus Franz Xaver Johannes Oberhumer
;;; Copyright (C) 1997 Markus Franz Xaver Johannes Oberhumer
;;; Copyright (C) 1996 Markus Franz Xaver Johannes Oberhumer
;;;
;;; The LZO library is free software; you can redistribute it and/or
;;; modify it under the terms of the GNU General Public License as
;;; published by the Free Software Foundation; either version 2 of
;;; the License, or (at your option) any later version.
;;;
;;; The LZO library is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with the LZO library; see the file COPYING.
;;; If not, write to the Free Software Foundation, Inc.,
;;; 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
;;;
;;; Markus F.X.J. Oberhumer
;;; <················@jk.uni-linz.ac.at>
;;; http://wildsau.idv.uni-linz.ac.at/mfx/lzo.html
;;; ***********************************************************************
;;; * Implementation of the LZO1X decompression algorithm.
;;; *
;;; * @author Markus F.X.J. Oberhumer <················@jk.uni-linz.ac.at>
;;; ***********************************************************************|#
#+win32
(load "D:/MIRAGE/asdf.lisp")
#-win32
(load "/Users/malkia/LP/asdf.lisp")
(pushnew #P"D:/MIRAGE/cffi_0.9.2/" asdf:*central-registry*)
(pushnew #P"/Users/malkia/LP/" asdf:*central-registry*)
(progn
(require 'asdf)
(asdf:oos 'asdf:load-op :cffi)
(cffi:define-foreign-library liblzo
(t
(:default "D:/MIRAGE/lzo1")
#+nil (:default "/usr/local/lib/liblzo2")))
(cffi:use-foreign-library liblzo)
(cffi:defcfun ("lzo1x_999_compress" lzo1x-999-compress) :int
(src :pointer) (src-len :unsigned-int)
(dst :pointer) (dst-len :pointer)
(wrk :pointer))
(cffi:defcfun ("lzo1x_decompress" lzo1x-decompress) :int
(src :pointer) (src-len :unsigned-int)
(dst :pointer) (dst-len :pointer)))
(defun lzo-compress-test ()
(with-open-file (uncompressed-stream
;#+win32 "D:/MIRAGE/tempfile.org"
#+win32 "D:/MIRAGE/gpu-capture.pix2"
#-win32 "/Users/malkia/ht-data.fasl"
:direction :input :element-type '(unsigned-byte 8))
(let* ((uncompressed-length (file-length uncompressed-stream))
(uncompressed-data (make-array uncompressed-length :element-type '(unsigned-byte 8)))
(decompressed-data (make-array uncompressed-length :element-type '(unsigned-byte 8)))
( compressed-data (make-array (* 2 uncompressed-length) :element-type '(unsigned-byte 8))))
(time (read-sequence uncompressed-data uncompressed-stream))
(let ((uncompressed-buffer (cffi:foreign-alloc :unsigned-char :count uncompressed-length))
(decompressed-buffer (cffi:foreign-alloc :unsigned-char :count uncompressed-length))
( compressed-buffer (cffi:foreign-alloc :unsigned-char :count (* 2 uncompressed-length)))
( work-buffer (cffi:foreign-alloc :unsigned-char :count (* 1024 1024)))
( compressed-length (cffi:foreign-alloc :int))
(decompressed-length (cffi:foreign-alloc :int)))
(time
(dotimes (offset uncompressed-length)
(setf (cffi:mem-ref uncompressed-buffer :unsigned-char offset)
(aref uncompressed-data offset))))
(setf (cffi:mem-ref compressed-length :int) (* 2 uncompressed-length))
(setf (cffi:mem-ref decompressed-length :int) uncompressed-length)
(time (lzo1x-999-compress uncompressed-buffer
uncompressed-length
compressed-buffer
compressed-length
work-buffer))
(time
(dotimes (offset (cffi:mem-ref compressed-length :int))
(setf (aref compressed-data offset)
(cffi:mem-ref compressed-buffer :unsigned-char offset))))
(format t "uncompressed-length = ~A~&" (cffi:mem-ref compressed-length :int))
(format t "~&~&decompressing using the DLL lzo1x-decomppress~&")
(time (lzo1x-decompress compressed-buffer
(cffi:mem-ref compressed-length :int)
decompressed-buffer
decompressed-length))
(time (lzo1x-decompress compressed-buffer
(cffi:mem-ref compressed-length :int)
decompressed-buffer
decompressed-length))
(time (lzo1x-decompress compressed-buffer
(cffi:mem-ref compressed-length :int)
decompressed-buffer
decompressed-length))
(format t "~&~&decompressing using the LISP lzo1x-decompress~&")
(time (lzo-decompress compressed-data :src-start 0 :src-length (cffi:mem-ref compressed-length :int) :dst decompressed-data :dst-length uncompressed-length))
(time (lzo-decompress compressed-data :src-start 0 :src-length (cffi:mem-ref compressed-length :int) :dst decompressed-data :dst-length uncompressed-length))
(time (lzo-decompress compressed-data :src-start 0 :src-length (cffi:mem-ref compressed-length :int) :dst decompressed-data :dst-length uncompressed-length))
(format t " compressed-length = ~A~&" (cffi:mem-ref decompressed-length :int))
(prog1
nil
;(time (cffi:foreign-string-to-lisp compressed-buffer (cffi:mem-ref compressed-length :int) nil))
(cffi:foreign-free uncompressed-buffer)
(cffi:foreign-free decompressed-buffer)
(cffi:foreign-free compressed-buffer)
(cffi:foreign-free work-buffer)
(cffi:foreign-free decompressed-length)
(cffi:foreign-free compressed-length))))))
#+nil
(lzo-compress-test ()
(let ((wrkmem (cffi:foreign-alloc :uint32 (* 7 16384))))))
#|(defun lzo1x-999-compress (src)
(let ((wrkmem (cffi:foreign-alloc :uint32 (* 7 16384))))
())|#
(defmacro aref++ (array index)
"Does the same job aref does, but increases index after that"
`(aref ,array (prog1 ,index (incf ,index))))
(defun lzo1-max-compression-size (input-size)
(+ input-size (ceiling (/ 16 input-size)) 64 3))
(defun lzo2-max-compression-size (input-size)
(+ input-size (ceiling (/ 8 input-size) 128) 3))
(defmacro acpy++1 (dst dst-index src src-index)
`(setf (aref++ ,dst ,dst-index)
(aref++ ,src ,src-index)))
(defmacro acpy++ (dst dst-index src src-index times)
(if (constantp times)
(let ((code))
(dotimes (ignored times)
(push `(acpy++1 ,dst ,dst-index ,src ,src-index) code))
(push 'progn code)
code)
`(dotimes (ignored ,times)
(acpy++1 ,dst ,dst-index ,src ,src-index))))
; Stolen from somewhere (can't remmember now)
(defmacro mwhile1 (expression &body body)
`(tagbody
start
(if (not ,expression)
(go end))
,@body
(go start)
end))
(defmacro mwhile (expression &body body)
`(tagbody
start
(if ,expression
(progn ,@body
(go start))
(go end))
end))
(defun lzo-decompress (src &key
(src-start 0) (src-length (length src))
(dst-start 0) (dst-length (* 10 src-length))
(dst (make-array dst-length :element-type '(unsigned-byte 8))))
"Decompress src to dst, both must be (array (*) (unsigned-byte 8))
The arrays may overlap under certain conditions (see LZO.FAQ)
LZO Copyright (C) 1996-1999 Markus F.X.J. Oberhumer <················@jk.uni-linz.ac.at>
Common Lisp Version (C) 2007 Dimiter \"malkia\" Stanev <······@mac.com> <······@gmail.com>"
(declare (type (simple-array (unsigned-byte 8) (*)) src dst)
(type fixnum src-start src-length dst-start dst-length)
(optimize (speed 3) (debug 0) (safety 0) (compilation-speed 0) (space 0)
#+lispworks (fixnum-safety 0)))
(let ((tt 0) (mp 0) (ip src-start) (op dst-start))
(declare (type fixnum ip op mp tt))
(setf tt (aref++ src ip))
(when (> tt 17)
(acpy++ dst op src ip (- tt 17))
(setf tt (aref++ src ip))
(when (< tt 16)
(error "LZO-E-ERROR")))
(tagbody loop1
(when (< tt 16)
(when (= tt 0)
(mwhile (= (aref src ip) 0)
(incf ip)
(incf tt 255))
(incf tt (+ 15 (aref++ src ip))))
(acpy++ dst op src ip (+ tt 3))
(setf tt (aref++ src ip))
(when (< tt 16)
(setf mp (- op #x0801 (ash tt -2) (ash (aref++ src ip) 2)))
;(when (< mp dst-start)
; (error "LZO-E-LOOKBEHIND-OVERRUN mp=~A dst-start=~A" mp dst-start))
(acpy++ dst op dst mp 3)
(setf tt (logand 3 (aref src (- ip 2))))
(when (= tt 0)
(go continue1))
(acpy++ dst op src ip tt)
(setf tt (aref++ src ip))))
(loop (cond ((>= tt 64)
(setf mp (- op 1 (logand (ash tt -2) 7) (ash (aref++ src ip) 3)))
(setf tt (- (ash tt -5) 1)))
((>= tt 32)
(setf tt (logand tt 31))
(when (= tt 0)
(mwhile (= (aref src ip) 0)
(incf ip)
(incf tt 255))
(incf tt (+ 31 (aref++ src ip))))
(setf mp (- op 1 (ash (aref++ src ip) -2) (ash (aref++ src ip) +6))))
((>= tt 16)
(setf mp (- op (ash (logand tt 8) 11)))
(setf tt (logand tt 7))
(when (= tt 0)
(mwhile (= (aref src ip) 0)
(incf ip)
(incf tt 255))
(incf tt (+ 7 (aref++ src ip))))
(decf mp (+ (ash (aref++ src ip) -2) (ash (aref++ src ip) +6)))
(when (= mp op)
(go out1))
(decf mp #x4000))
(t (setf mp (- op 1 (ash tt -2) (ash (aref++ src ip) 2)))
(setf tt 0)))
;(when (< mp dst-start)
; (error "LZO-E-LOOKBEHIND-OVERRUN mp=~A dst-start=~A" mp dst-start))
(acpy++ dst op dst mp (+ 2 tt))
(setf tt (logand 3 (aref src (- ip 2))))
(if (= tt 0)
(go continue1))
(acpy++ dst op src ip tt)
(setf tt (aref++ src ip)))
continue1
(setf tt (aref++ src ip))
(go loop1)
out1)
(decf ip src-start)
(decf op dst-start)
(cond ((< tt 0) (values dst t))
((< ip src-length) (error "LZO INPUT NOT CONSUMED: IP=~A LENGTH=~A" ip src-length))
((> ip src-length) (error "LZO INPUT OVERRUN: IP=~A LENGTH=~P" ip src-length))
((/= tt 1) (error "LZO ERROR TT=~A" TT))
(t (values dst dst-length)))))
(defun load-file (filename)
(with-open-file (s filename :element-type '(unsigned-byte 8))
(let ((buffer (make-array (file-length s) :element-type '(unsigned-byte 8))))
(read-sequence buffer s)
buffer)))
(defun test ()
(let* ((buffer (load-file "/Users/malkia/Desktop/lzop-1.02rc1/readme.lzo"))
(data (logior (ash (aref buffer 0) 24)
(ash (aref buffer 1) 16)
(ash (aref buffer 2) 8)
(ash (aref buffer 3) 0)))
(ulen (logior (ash (aref buffer 4) 24)
(ash (aref buffer 5) 16)
(ash (aref buffer 6) 8)
(ash (aref buffer 7) 0)))
(clen (logior (ash (aref buffer 8) 24)
(ash (aref buffer 9) 16)
(ash (aref buffer 10) 8)
(ash (aref buffer 11) 0))))
(format t "~A ~A ~A~&" data ulen clen)
(lzo-decompress buffer :start 16)))
#| ;Work in progress
(defun lzo-compress (src
&option (dst2 nil) (dst2-start 0) (dst2-length nil)
&key (start 0) (length 0 length-supplied-p))
(let ((dict (make-array 65536 :element-type '(unsigned-byte 8)))
(ip 0)
(op 0)
(in-end (length))
(ip-end (- length 13))
(ii 0)
(dict 0)
(op 0)
(mp 0)
(mo 0)
(ml 0)
(di 0))
(incf ip 4)
(tagbody loop1
(setf di (logand #x3fff
(logior (* (ash (aref src (+ ip 3)) +6)
(ash (aref src (+ ip 2)) +5)
(ash (aref src (+ ip 1)) +5)
#x21)
(ash (aref src (+ ip 0)) -5)))
mp (aref dict di))
(when (or (< mp in)
(<= (setf mp (- ip mp)) 0)
(> mo #xBFFF))
(go literal))
(when (or (<= mo #x800)
(= (aref dict (+ 3 mp))
(aref src (+ 3 ip))))
(go try-match))
(setf di (logior (logand di #x7FF) #x201F))
(setf mp (aref dict di))
(when (or (< mp in)
(<= (setf mp (- ip mp)) 0)
(> mo #xBFFF))
(go literal))
(when (or (<= mo #x800)
(= (aref dict (+ 3 mp))
(aref src (+ 3 ip))))
(go try-match))
try-match
(when (and (= (aref dic (mp 0))
(aref src (ip 0)))
(= (aref dic (mp 1))
(aref src (ip 1)))
(= (aref dic (mp 2))
(aref src (mp 2))))
(go match))
literal
(setf (aref dic di) ip)
(incf ip)
(if (>= ip ip-end)
(go exit1)
(go loop1))
match
(setf (aref dic di) ip)
(when (> (- ip ii) 0)
(setf tt (- ip ii))
(cond ((<= tt +3) (setf (aref dst2 (- 2 op))
(logor (aref dst2 (- 2 op)) 255)))
((<= tt 18) (setf (aref++ dst2 op) (- t 3)))
(t (setf (aref++ dst2 op) 0)
(do (
|#
--------------020503040505040107050206--
Jon Harrop wrote:
> Don Geddis wrote:
>> Probably most of us are familiar with Paul Graham's hypothetical "Blub"
>> language, as described in the section "The Blub Paradox" in the middle of
>> http://paulgraham.com/avg.html
[...]
> So people should ask "is Lisp the most efficient language to solve my
> problems?".
>
> I personally cannot think of a single application that Common Lisp is well
> suited to. Indeed, I constantly post example programs written in various
> languages that cannot be translated into Lisp without becoming long,
> obfuscated and slow. I cannot remember ever having seen an example where a
> problem can be solved more succinctly, elegantly and efficiently in Lisp.
>
Looks like it's time for you to stop working on toy example programs.
Sacha
Jon Harrop schrieb:
> I personally cannot think of a single application that Common Lisp is well
> suited to. Indeed, I constantly post example programs written in various
> languages that cannot be translated into Lisp without becoming long,
> obfuscated and slow. I cannot remember ever having seen an example where a
> problem can be solved more succinctly, elegantly and efficiently in Lisp.
Try it the other way around.
Translate cl-ppcre to OCaml. Take the source code for AllegroServe and
translate it to F#.
Write an OCaml program that takes OCaml code during runtime and inserts
it into the middle of some other function f, compiles f and runs f without
restarting the program.
Andr� Thieme wrote:
> Translate cl-ppcre to OCaml.
<=> Str module or libpcre-ocaml
> Take the source code for AllegroServe
<=> Ocsigen
But translating a solution from the language it was designed for to another
language is not the same as solving a problem.
There are many such bad examples already out there so there is no need to
create more. Look at this translation of SICP into statically typed
languages, for example:
http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
(WARNING: totally impractical ML code!)
If you want a useful comparison, find a problem and get good coders to solve
it in each language. This is exactly what I did for the ray tracer but you
might like to find problems that Lisp is better suited to.
> Write an OCaml program that takes OCaml code during runtime and inserts
> it into the middle of some other function f, compiles f and runs f without
> restarting the program.
Higher-order function.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop schrieb:
> I personally cannot think of a single application that Common Lisp is well
> suited to. Indeed, I constantly post example programs written in various
> languages that cannot be translated into Lisp without becoming long,
> obfuscated and slow. I cannot remember ever having seen an example where a
> problem can be solved more succinctly, elegantly and efficiently in Lisp.
Oh, and Wade is still waiting for your F# version of the game
"Concentration".
Wade Humeniuk wrote on December 13 of last year:
>
http://groups.google.de/group/comp.lang.lisp/tree/browse_frm/thread/70e6afa9012cbd5c/0871cddcf502af47?rnum=231&hl=de&_done=%2Fgroup%2Fcomp.lang.lisp%2Fbrowse_frm%2Fthread%2F70e6afa9012cbd5c%2F4050caff2ebed840%3Ftvc%3D1%26hl%3Dde%26#doc_79d6592dbc65996d
And you answered to his question if you want to write a version in F#:
Absolutely. While you're at it, I'll try implementing it in F#... :-)
It took Wade around 8 hours.
Your counter is now at 4700 hours and you still are not done.
You realized that it can't be written as fast as in Lisp I suppose.
Andr� Thieme <······························@justmail.de> writes:
> Oh, and Wade is still waiting for your F# version of the game
> "Concentration".
> Wade Humeniuk wrote on December 13 of last year:
> >
> http://groups.google.de/group/comp.lang.lisp/tree/browse_frm/thread/70e6afa9012cbd5c/0871cddcf502af47?rnum=231&hl=de&_done=%2Fgroup%2Fcomp.lang.lisp%2Fbrowse_frm%2Fthread%2F70e6afa9012cbd5c%2F4050caff2ebed840%3Ftvc%3D1%26hl%3Dde%26#doc_79d6592dbc65996d
>
> And you answered to his question if you want to write a version in F#:
> Absolutely. While you're at it, I'll try implementing it in F#... :-)
>
> It took Wade around 8 hours.
> Your counter is now at 4700 hours and you still are not done.
> You realized that it can't be written as fast as in Lisp I suppose.
Yes. I remember that, too. Probably we have run into the problem that F#
and Ocaml are not Turing complete and concentration games simply cannot be
written :-)
Nicolas
--
- I've heard that Jon Harrop has written a new book.
- Oh? What title? Is it "The Final Countdown: F# against Ocaml"?
- No. It aspires to Knuth's seminal work and is called "The Art of
Usenet Spamming".
Nicolas Neuss wrote:
> Yes. I remember that, too. Probably we have run into the problem that F#
> and Ocaml are not Turing complete and concentration games simply cannot be
> written :-)
http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-08/msg01865.html
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Nicolas Neuss wrote:
> > Yes. I remember that, too. Probably we have run into the problem that F#
> > and Ocaml are not Turing complete and concentration games simply cannot be
> > written :-)
>
> http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-08/msg01865.html
I stand corrected.
Nicolas
Nicolas Neuss <········@mathematik.uni-karlsruhe.de> writes:
> > > Yes. I remember that, too. Probably we have run into the problem that F#
> > > and Ocaml are not Turing complete and concentration games simply cannot be
> > > written :-)
> >
> > http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-08/msg01865.html
>
> I stand corrected.
That is, at least OCaml is suited for writing a concentration game...
Nicolas
Nicolas Neuss wrote:
> That is, at least OCaml is suited for writing a concentration game...
Yes. I did say that I was going to write an F# implementation as well but I
haven't start it yet! :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet