What’s gone wrong with Scheme Macros? Why all the debate?
Adrian B.
noticed that there's always so much debate, confusion, and critiques
of the scheme macro system.
Is there something fundamentally broken with Scheme macros? Are they
badly designed? Or is all this discussion simply due to confusion?
Why the constant debate?
If the macro system is badly designed, are there any serious attempts
to improve it? Or is it cast in stone forever more due to appearing
in the R5RS? I've seen one alternative, syntax-case, but is it a
serious alternative for the standard, or is it just a slightly better
version of syntax rules?
Finally, is there a Scehme macros FAQ? I must admit I'm quite
confused by all this debate.
Thanks
Nils Goesche
> Is there something fundamentally broken with Scheme macros?
Yes, they're eugenic. However, I think there is no need to
discuss this in comp.lang.lisp. Follow-ups set.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Takehiko Abe
> Is there something fundamentally broken with Scheme macros?
Please do not cross post to comp.lang.lisp.
--
This message was not sent to you unsolicited.
cr88192
> As a casual user of scheme and reader of the related newsgroups, I've
> noticed that there's always so much debate, confusion, and critiques
> of the scheme macro system.
>
> Is there something fundamentally broken with Scheme macros? Are they
> badly designed? Or is all this discussion simply due to confusion?
>
I have my reasons for disliking scheme's macros, though I am no real
authority to make judgements. I just like procedural macros...
with procedural macros I am given the freedom to code up whatever code
generation I want, rather than being restricted to pattern matching and
substitution.
I am sorry, I don't have a good argument here...
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Adrian B.
> In article <7ed8f64d.02090...@posting.google.com>, bo...@swirve.com (Adrian B.) wrote:
>
> > Is there something fundamentally broken with Scheme macros?
>
> Please do not cross post to comp.lang.lisp.
And why exactly not? Lispers are strong users of macros and may have
some good experience on the design and use of macro systems. Its not
like the question was crossposted to a C++ or Java newsgroup.
Takehiko Abe
> > > Is there something fundamentally broken with Scheme macros?
> >
> > Please do not cross post to comp.lang.lisp.
>
> And why exactly not? Lispers are strong users of macros and may have
> some good experience on the design and use of macro systems.
First of all, you should realize that most Lispers do not care
whether Scheme macro is broken or not.
I am already sick and tired to see it discussed in c.l.l yet again.
And crossposting to c.l.l. and c.l.s. [especially with a subject
like 'what's gone wrong with scheme macros?'] sends a strong signal
to the troll detectors which sadly by now most of comp.lang.lisp
readers have been forced to be equipped with.
If you genuinely want to know some Lisper's opionions on the topic,
try Deja/Google with keywords: 'scheme', 'macro', 'hygienic',
and 'namespace'. You may want to add 'neurotic' or 'freaks' to
filter further.
Marco Antoniotti
bo...@swirve.com (Adrian B.) writes:
> As a casual user of scheme and reader of the related newsgroups, I've
> noticed that there's always so much debate, confusion, and critiques
> of the scheme macro system.
>
> Is there something fundamentally broken with Scheme macros? Are they
> badly designed? Or is all this discussion simply due to confusion?
>
> Why the constant debate?
>
> If the macro system is badly designed, are there any serious attempts
> to improve it? Or is it cast in stone forever more due to appearing
> in the R5RS? I've seen one alternative, syntax-case, but is it a
> serious alternative for the standard, or is it just a slightly better
> version of syntax rules?
There is no real debate. Scheme needs the macro system it has because
it is useful and because of the conflating of "variable" and
"function" namespaces. Not having a macro systme would impair Scheme
usefulness.
Another matter is the pointless debate about the "superiority" of
Scheme "pattern directed" macro system over the "structure handling"
macro system of Common Lisp. Even in this case the chase can be cut
short in many ways. It is simply a non problem.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Brian Harvey
>Is there something fundamentally broken with Scheme macros?
I suspect this may be analogous to the "brokenness" of the physical world
that leaves us with the unfortunate mess of quantum physics. Up to a point
the world behaves with great (Newtonian) elegance, but then the elegance
breaks down. God's fault, not Newton's or Heisenberg's.
In the case of Scheme, the language is based on (at least) two principles,
(1) power through simplicity and (2) referential transparency. Up to a point
these fit together remarkably well, with Scheme's serendipitous ability to do
OOP without any special OOP-specific design features as the apex of their
common elegance. But when it comes to macros, (1) leads to old-fashioned LISP
FEXPRs while (2) leads to R5RS macros.
Al Petrofsky
> As a casual user of scheme and reader of the related newsgroups, I've
> noticed that there's always so much debate, confusion, and critiques
> of the scheme macro system.
As even a casual reader of these newsgroups should know, cross-posting
between them just creates flames.
> Is there something fundamentally broken with Scheme macros?
For a long time, there was no standardized macro facility in scheme.
You can consider that to be "something fundamentally broken with" them
if you like. In that respect, there are many aspects of scheme that
have something fundamentally broken with them: modules, symbol
properties, roman numeral support, etc..
In r5rs, a high-level macro system was standardized. No low-level
macro system has been standardized. There are a few low-level macro
systems that are good complements to the high-level syntax-rules. The
most popular is syntax-case. There are also many simple defmacro-like
low-level macro systems that are not sufficiently powerful for
implementing syntax-rules and that do not interact well with
syntax-rules.
> Finally, is there a Scehme macros FAQ? I must admit I'm quite
> confused by all this debate.
There are some macro questions in the scheme faq at schemers.org. At
readscheme.org there are many papers on scheme macros that describe
their history, motivation, and use.
-al
Software Scavenger
> And why exactly not? Lispers are strong users of macros and may have
> some good experience on the design and use of macro systems. Its not
> like the question was crossposted to a C++ or Java newsgroup.
I agree that it's interesting to discuss differences in macros in
different languages. It seems easy enough for those who aren't
interested to just skip this whole thread. Especially with such an
easily plonkable thread name that won't even cause any hesitation.
As an example to compare Common Lisp macros with Scheme macros,
consider a macro named DO-COMBINATIONS, which works as follows:
(do-combinations (x1 x2 x3) '(1 2 3 4 5)
(print (list x1 x2 x3)))
===>
(1 2 3)
(1 2 4)
(1 2 5)
(1 3 4)
(1 3 5)
(1 4 5)
(2 3 4)
(2 3 5)
(2 4 5)
(3 4 5)
(do-combinations (a b)
'(heart spade diamond club)
(print (list a b)))
===>
(HEART SPADE)
(HEART DIAMOND)
(HEART CLUB)
(SPADE DIAMOND)
(SPADE CLUB)
(DIAMOND CLUB)
(defun combinations-of-3 (list)
(let (result)
(do-combinations (a b c) list
(push (list a b c) result))
(reverse result)))
(combinations-of-3 '(1 2 3 4 5))
===>
((1 2 3) (1 2 4) (1 2 5) (1 3 4) (1 3 5) (1 4 5) (2 3 4) (2 3 5) (2 4
5) (3 4 5))
The above three examples show three ways to use the example
DO-COMBINATIONS macro.
I don't actually know Scheme, but would like to see the implementation
of the above DO-COMBINATIONS macro in it. Then I or someone could
post a CL version of it to compare. Maybe several people could post
more than one way to implement it, to compare different ways in each
language. Then we could do the same thing for other kinds of macros.
Etc., till we get a better idea of the differences.
MJ Ray
> First of all, you should realize that most Lispers do not care
> whether Scheme macro is broken or not.
I would think that all of us lispers who scheme do. I sometimes wonder
about the relative popularity of CL, Elisp and Scheme, but it's an
imponderable. The relative ages do a lot to distort naive measurements.
> I am already sick and tired to see it discussed in c.l.l yet again.
Yes, this is probably a mistake, but c.l.l is not just for common lisp,
despite the wishes of some.
Thomas Bushnell, BSG
> I suspect this may be analogous to the "brokenness" of the physical world
> that leaves us with the unfortunate mess of quantum physics. Up to a point
> the world behaves with great (Newtonian) elegance, but then the elegance
> breaks down. God's fault, not Newton's or Heisenberg's.
Ah, and like Scheme, once you get your head inside QM you discover
that it is stunningly elegant indeed, moreso than the Newtonian world
by far.
ol...@pobox.com
> As an example to compare Common Lisp macros with Scheme macros,
> consider a macro named DO-COMBINATIONS, which works as follows:
>
> (do-combinations (x1 x2 x3) '(1 2 3 4 5)
> (print (list x1 x2 x3)))
> of the above DO-COMBINATIONS macro in it.
; The do-combinations macro
; (do-combinations (x1 x2 x3) (1 2 3 4 5)
; (print (list x1 x2 x3)))
; will print all combinations of three elements out of (1 2 3 4 5)
(define-syntax do-combinations
(syntax-rules ()
((_ (binder ...) elements body)
(for-each
(lambda (x) (apply (lambda (binder ...) body) x))
(subsets (length (quote (binder ...)))
(quote elements))))))
; create a list of all subsets from 'elements' of length 'how-many'
; The resulting list will have the size of
; (choose how-many (length elements))
; Recurrence relation:
; (subsets how-many (cons el elems)) =
; (append (subsets how-many elems)
; (map add-el (subsets (-- how-many) elems)))
; (subsets 0 elems) = '()
; (subsets 1 elems) = (map list elems) ; singleton subsets
; (subsets n elems) = '() whenever n > (length elems)
;
; The code is optimized for clarity rather than for speed
; See the thread
; http://groups.google.com/groups?threadm=7eb8ac3e.0201120056.3fc231c8%40posting.google.com
; for the fastest implementation of this function.
(define (subsets how-many elements)
(cond
((zero? how-many) '())
((null? elements) '())
((= 1 how-many) (map list elements))
((= how-many (length elements)) (list elements))
((> how-many (length elements)) '())
(else
(append (subsets how-many (cdr elements))
(map (lambda (x) (cons (car elements) x))
(subsets (- how-many 1) (cdr elements)))))))
; Test cases
(pp (subsets 0 '(heart spade diamond club)))
(pp (subsets 1 '(heart spade diamond club)))
(pp (subsets 2 '(heart spade diamond club)))
(pp (subsets 3 '(heart spade diamond club)))
(pp (subsets 4 '(heart spade diamond club)))
(pp (subsets 5 '(heart spade diamond club)))
; Examples
(do-combinations (a b)
(heart spade diamond club)
(begin
(display (list a b))
(newline)))
===>
(diamond club)
(spade diamond)
(spade club)
(heart spade)
(heart diamond)
(heart club)
(do-combinations (x1 x2 x3)
(1 2 3 4 5)
(begin
(display (list x1 x2 x3))
(newline)))
===>
(3 4 5)
(2 4 5)
(2 3 4)
(2 3 5)
(1 4 5)
Al Petrofsky
cubic...@mailandnews.com (Software Scavenger) writes:
> bo...@swirve.com (Adrian B.) wrote:
>
> > And why exactly not? Lispers are strong users of macros and may have
> > some good experience on the design and use of macro systems.
> I agree that it's interesting to discuss differences in macros in
> different languages.
There are certainly some readers of comp.lang.lisp who are interested
in comparing scheme and cl macros, but those people should all be
reading comp.lang.scheme as well. Scheme is not a recent offshoot of
lisp. Lisp followers have had plenty of time to consider whether or
not they are interested in the directions scheme has taken, and those
who are interested should look in comp.lang.scheme.
> As an example to compare Common Lisp macros with Scheme macros,
> consider a macro named DO-COMBINATIONS, which works as follows:
> (do-combinations (a b)
> '(heart spade diamond club)
> (print (list a b)))
> ===>
> (HEART SPADE)
> (HEART DIAMOND)
> (HEART CLUB)
> (SPADE DIAMOND)
> (SPADE CLUB)
> (DIAMOND CLUB)
> I don't actually know Scheme, but would like to see the implementation
> of the above DO-COMBINATIONS macro in it.
That example happens to be well-suited to syntax-rules, scheme's
pattern language for macros:
(define-syntax do-combinations
(syntax-rules ()
((do-combinations () list-expr expr)
expr)
((do-combinations (var . rest-of-vars) list-expr expr)
(let do-combos-using-all-vars ((vals list-expr))
(if (not (null? vals))
(let ((var (car vals))
(rest-of-vals (cdr vals)))
(do-combinations rest-of-vars rest-of-vals expr)
(do-combos-using-all-vars rest-of-vals)))))))
An alternative approach would be to keep the macro as simple as
possible and let a procedure do all the work:
(define-syntax do-combinations
(syntax-rules ()
((do-combinations vars list-expr expr)
(do-combos-proc 'vars list-expr (lambda vars expr)))))
(define (do-combos-proc vars vals proc)
(cond ((null? vars) (proc))
((not (null? vals))
(let ((first-val (car vals))
(rest-of-vals (cdr vals)))
(do-combos-proc (cdr vars) rest-of-vals
(lambda args (apply proc first-val args)))
(do-combos-proc vars rest-of-vals proc)))))
-al
MJ Ray
> [...] those people should all be reading comp.lang.scheme as well. Scheme
> is not a recent offshoot of lisp. [...]
In fact, it is not an offshoot at all. It is a lisp. May I assume that you
are in the "c.l.l is for CL only" brigade?
Al Petrofsky
I'm in the "c.l.l is for those variants/offshoots of lisp that don't
already have their own separate newsgroup" militia. I can also give
you my name, rank, and serial number if you want, but that's all I'm
allowed to say on the subject.
-al
Marco Antoniotti
Al Petrofsky <a...@petrofsky.org> writes:
> [Followups redirected to comp.lang.scheme]
>
> cubic...@mailandnews.com (Software Scavenger) writes:
> > bo...@swirve.com (Adrian B.) wrote:
> >
> > > And why exactly not? Lispers are strong users of macros and may have
> > > some good experience on the design and use of macro systems.
>
> > I agree that it's interesting to discuss differences in macros in
> > different languages.
>
> There are certainly some readers of comp.lang.lisp who are interested
> in comparing scheme and cl macros, but those people should all be
> reading comp.lang.scheme as well. Scheme is not a recent offshoot of
> lisp. Lisp followers have had plenty of time to consider whether or
> not they are interested in the directions scheme has taken, and those
> who are interested should look in comp.lang.scheme.
New directions in Scheme? Like "let's re-implement the CLHS"?
Sorry, I am a sucker. I cannot resist these flame baits :)
Fell frce to send replies to /dev/null :)
Kaz Kylheku
Actually it's exactly as if the question was crossposted to a C++
or Java newsgroup.
Feuer
Is it really a Lisp? Does it really retain anything significant from
Lisp other than parentheses and call-by-value semantics?
David
Feuer
>
> Takehiko Abe <ke...@ma.ccom> wrote:
> > First of all, you should realize that most Lispers do not care
> > whether Scheme macro is broken or not.
>
> I would think that all of us lispers who scheme do. I sometimes wonder
> about the relative popularity of CL, Elisp and Scheme, but it's an
> imponderable. The relative ages do a lot to distort naive measurements.
The only certainty is that Elisp has the most installations of the
three. Scheme came before CL (right?), but when was Elisp created?
David
Brian Harvey
>Is [Scheme] really a Lisp? Does it really retain anything significant from
>Lisp other than parentheses and call-by-value semantics?
Umm... lambda? Cons, car, cdr? Do those count?
Feuer
I meant distinguishing characteristics that would make it a Lisp in
particular and not just another functional language. The names of the
operators don't show anything but history. Call it lambda, \ ->, or
fn => I don't care. Call them cons,car,cdr, :,head,tail, ::,hd,tl
Doesn't matter.
The question is: what is a Lisp? Is it anything with sexprs?
Anything with sexprs and macros? sexprs, macros, and closures?
sexprs, macros, closures, and dynamically scoped variables?
All of the above and multiple namespaces? All of the above and
a powerful eval facility?
David
Perry E. Metzger
Feuer <fe...@his.com> writes:
> > In fact, it is not an offshoot at all. It is a lisp. May I
> > assume that you are in the "c.l.l is for CL only" brigade?
>
> Is it really a Lisp? Does it really retain anything significant from
> Lisp other than parentheses and call-by-value semantics?
It is hard to see why scheme would not be considered a lisp but emacs
lisp or interlisp or the lisp in the sawfish window manager or
whatever would not be. It is certainly not even an unusual dialect --
lisp 1 also had the unified function/variable namespace, the lexical
scoping is now the norm rather than unusual, etc. What makes scheme
the least bit unlispy, in fact?
--
Perry E. Metzger pe...@piermont.com
--
"Ask not what your country can force other people to do for you..."
Jens Axel Søgaard
> What makes scheme the least bit unlispy, in fact?
The community.
See the excellent article of Ken Pitman:
More than just words
- Lambda, the Ultimate Political Party
http://world.std.com/~pitman/PS/Lambda.html
--
Jens Axel Søgaard
Christopher Browne
> Feuer <fe...@his.com> writes:
>> > In fact, it is not an offshoot at all. It is a lisp. May I
>> > assume that you are in the "c.l.l is for CL only" brigade?
>>
>> Is it really a Lisp? Does it really retain anything significant from
>> Lisp other than parentheses and call-by-value semantics?
>
> It is hard to see why scheme would not be considered a lisp but emacs
> lisp or interlisp or the lisp in the sawfish window manager or
> whatever would not be. It is certainly not even an unusual dialect --
> lisp 1 also had the unified function/variable namespace, the lexical
> scoping is now the norm rather than unusual, etc. What makes scheme
> the least bit unlispy, in fact?
The fact that such questions lead to flame wars and division, along
quite clearly discernable lines that form on both sides.
There may be things worth discussing about the comparative
similarities and differences between Common Lisp and Scheme; there
might conceivably be some new things worth discussing, even concerning
the respective macro systems.
Unfortunately, past history shows that such discussions generally lead
to flames and acrimony.
The only way that you should _consider_ such a discussion is if you
are:
a) Well aware of the possibilities for flames, and
b) Really quite sure, based on reviewing past discussions, that you
aren't merely rehashing ancient history.
The fact that you aren't aware of the flameworthiness of the
discussion suggests that it is _highly_ unlikely that you have
reviewed past discussions, and that there is little reason to expect
the discussion to lead anywhere constructive.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/multiplexor.html
Signs of a Klingon Programmer - 2. "Specifications are for the weak
and timid!"
Perry E. Metzger
"Jens Axel Søgaard" <use...@soegaard.net> writes:
> Perry E. Metzger wrote:
>
> > What makes scheme the least bit unlispy, in fact?
>
> The community.
>
> See the excellent article of Ken Pitman:
Which mentions nothing about Scheme.
Not to mention, of course, that a lot of the same people are
responsible for both Scheme and Common Lisp, which leads one to
believe "the community" isn't a good reason to think of Scheme as a
non-lisp, unless Common Lisp is also a non-lisp.
Perry E. Metzger
Christopher Browne <cbbr...@acm.org> writes:
> > It is hard to see why scheme would not be considered a lisp but emacs
> > lisp or interlisp or the lisp in the sawfish window manager or
> > whatever would not be. It is certainly not even an unusual dialect --
> > lisp 1 also had the unified function/variable namespace, the lexical
> > scoping is now the norm rather than unusual, etc. What makes scheme
> > the least bit unlispy, in fact?
>
> The fact that such questions lead to flame wars and division, along
> quite clearly discernable lines that form on both sides.
I find something interesting about both comp.lang.lisp and
comp.lang.scheme. In other language newsgroups, like the the ruby
group or what have you, people spend most of their time asking
questions about how to solve particular problems they're having with
their production code using the language or what have you. This tends
to indicate the people involved are largely interested in programming
languages as a way of accomplishing their work. In the c.l.l and
c.l.s, however, we have groups of people who are concerned largely
about linguistic metaissues, that is, about their language as a
religion.
It would appear that, in their ability to confine themselves almost
entirely at the religious layer of the stack, the two communities are
obviously made up of people of nearly the same mentality. Whether this
is a productive mentality or not remains to be seen, but clearly if we
are to ask a question someone else mentioned today and ask if both
Common Lisp and the Scheme communities share an outlook, there is no
question that they do.
Perhaps to insiders there is a tremendous difference in world view
between the two groups, but to outsiders it looks ever so much like
two groups of Christians a few hundred years ago persecuting each
other over doctrinal minutia utterly unimportant to the overall
picture.
> The fact that you aren't aware of the flameworthiness of the
> discussion suggests that it is _highly_ unlikely that you have
> reviewed past discussions, and that there is little reason to expect
> the discussion to lead anywhere constructive.
Perhaps we could have a new discussion about why it is that people
think that religion is more interesting than writing programs.
Erik Naggum
| Perhaps we could have a new discussion about why it is that people
| think that religion is more interesting than writing programs.
Perhaps people who use Common Lisp and Scheme are already adept at writing
programs and no longer have the pathetic little problems that so plague the
newer languages and are interested in politics (not religion) just as people
who think there is a better way to make a living than wonder how to get a
job serving burgers get into law and politics and diplomacy and standards.
That you have no better grasp of the higher levels of society than to call
it "religion" unfortunately speaks volumes about your own outlook on that
which transcends petty problems expressing simple algorithms in languages
younger than their practitioners' computers.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Robert Uhl <ruhl@4dv.net>
>
> The community.
>
> See the excellent article of Ken Pitman:
>
> More than just words
> - Lambda, the Ultimate Political Party
>
> http://world.std.com/~pitman/PS/Lambda.html
That article implicitly assumes that Scheme is, in fact, a Lisp:
In some dialects of Scheme, COND takes the unusual but popular
``=>'' syntax.
Although, in the conclusion, it states that one might care to view
Scheme as not Lisp. I don't buy that, because in the same breath he
explains that it's in the same manner that Common Lisp & ILISP are not
the same language. IMHO they are--just different dialects.
--
Robert Uhl <ru...@4dv.net>
Virtues foster one another; so too, vices. Bad English kills trees,
consumes energy, and befouls the Earth. Good English renews it.
--The Underground Grammarian
Dennis Marti
> Brian Harvey wrote:
> >
> > Feuer <fe...@his.com> writes:
> > >Is [Scheme] really a Lisp? Does it really retain anything significant from
> > >Lisp other than parentheses and call-by-value semantics?
> >
> > Umm... lambda? Cons, car, cdr? Do those count?
>
> I meant distinguishing characteristics that would make it a Lisp in
> particular and not just another functional language. The names of the
> operators don't show anything but history. Call it lambda, \ ->, or
> fn => I don't care. Call them cons,car,cdr, :,head,tail, ::,hd,tl
> Doesn't matter.
>
> The question is: what is a Lisp?
I like Paul Graham's answer in his article "Revenge of the Nerds"
(http://www.paulgraham.com/icad.html). If you don't want to read the
whole thing, look for the section titled "What Made Lisp different".
Dennis
Jens Axel Søgaard
> Although, in the conclusion, it states that one might
> care to view Scheme as not Lisp.
Depending on the political context:
Sometimes it's best for us all to act as a single body--when we
have a common need or when we can help each other on our
separate needs by acting as one body. On those occasions, it
might be to the advantage of some or all of us to view Scheme and
Dylan as members of the Lisp family. At other times, it's best for
us to act independently, to avoid stepping on each other's toes.
On those occasions, not only might Scheme and Dylan not be Lisps,
but it might be important even to say that Common Lisp and ISLISP are
sufficiently distinct that it is better to treat them as non-overlapping languages.
--
Jens Axel Søgaard
![Michael Sperber [Mr. Preprocessor]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW1Ug-7D5rvPAe0Dy8QWlBwdoMp8sHWFACGdNTzwJ9mF7CkTQ=s40-c)
Michael Sperber [Mr. Preprocessor]
Perry> Feuer <fe...@his.com> writes:
>> > In fact, it is not an offshoot at all. It is a lisp. May I
>> > assume that you are in the "c.l.l is for CL only" brigade?
>>
>> Is it really a Lisp? Does it really retain anything significant from
>> Lisp other than parentheses and call-by-value semantics?
Perry> It is hard to see why scheme would not be considered a lisp but emacs
Perry> lisp or interlisp or the lisp in the sawfish window manager or
Perry> whatever would not be. It is certainly not even an unusual dialect --
Perry> lisp 1 also had the unified function/variable namespace, the lexical
Perry> scoping is now the norm rather than unusual, etc. What makes scheme
Perry> the least bit unlispy, in fact?
The fact that code and data are not the same.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Hrvoje Blazevic
> Perhaps people who use Common Lisp and Scheme are already adept at writing
> programs and no longer have the pathetic little problems that so plague the
> newer languages and are interested in politics (not religion) just as people
> who think there is a better way to make a living than wonder how to get a
> job serving burgers get into law and politics and diplomacy and standards.
Umm... That is an interesting view. I would rather say that people who think
there is a better way to make a living then wonder how to get a job serving
burgers get into LAW and POLITICS and DIPLOMACY ... are people who are not
interested in working at all.
As for politics not being religion ... I was "fortunate" enough to have been
born in a communist run country, and know very well that communism (probably
most of the other "politics" as well) is very much a religion at its best --
cause if you speak up; they will burn you!
Hrvoje
Sander Vesik
Does it matter? After all, there is no point in conuting installations
wher nobody ever wrote a line of code in it. Its also easily changed by
getting any other of the two into a consumer device - where it, of course,
would not have any new lines of code written in it either.
>
> David
--
Sander
+++ Out of cheese error +++
Sander Vesik
> Brian Harvey wrote:
>>
>> Feuer <fe...@his.com> writes:
>> >Is [Scheme] really a Lisp? Does it really retain anything significant from
>> >Lisp other than parentheses and call-by-value semantics?
>>
>> Umm... lambda? Cons, car, cdr? Do those count?
>
> I meant distinguishing characteristics that would make it a Lisp in
> particular and not just another functional language. The names of the
> operators don't show anything but history. Call it lambda, \ ->, or
> fn => I don't care. Call them cons,car,cdr, :,head,tail, ::,hd,tl
> Doesn't matter.
Well, it has the same unhealthy facination with lists that are really
chains of glued together pairs.
Pascal Costanza
>
> I find something interesting about both comp.lang.lisp and
> comp.lang.scheme. In other language newsgroups, like the the ruby
> group or what have you, people spend most of their time asking
> questions about how to solve particular problems they're having with
> their production code using the language or what have you. This tends
> to indicate the people involved are largely interested in programming
> languages as a way of accomplishing their work. In the c.l.l and
> c.l.s, however, we have groups of people who are concerned largely
> about linguistic metaissues, that is, about their language as a
> religion.
Your comparisons are not fair, for the following reasons.
(1) Programming languages like Ruby are deliberately restricted to a
particular programming paradigm, in that case object-oriented
programming. If you are willing to restrict yourself to a particular
language you have already made several choices, consciously or
subconsciously, and when you discuss things with your peers you won't
get into these kinds of discusssions because you already agree on some
fundamentals.
Lisp is different in this respect because it has a long history of
experimenting with several programming paradigms. Of course you will get
discussions about language features, sometimes heated discussions, if
that's your topic of interest. No surprises there.
(2) Common Lisp and Scheme reveal different design decisions. This is
most likely because their designers had different goals, sometimes
fundamentally different goals. Sometimes people forget that design
issues are never decided upon in a vacuum, but always with certain
concrete and/or abstract goals in mind. More often than not they are
based on hidden assumptions and discussions get heated because the
participators are not aware of their own respective assumptions.
Now assume you had a newsgroup where people of different object-oriented
programming languages would meet. Soon you would get similar heated
discussions. See http://c2.com/cgi/wiki?LanguagePissingMatch for some
examples.
(3) comp.lang.lisp is about several Lisp dialects. Imagine a kind of
comp.lang.commonlisp - I assume that in such a newsgroup the outcome
would be different. What I want to say here is that comp.lang.lisp is
not about _one_ language but about a family of languages. Again, it's
not surprising that you get discussions about the differences between
the several dialects.
These newsgroups just play in a different league.
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Kenny Tilton
Perry E. Metzger wrote:
> I find something interesting about both comp.lang.lisp and
> comp.lang.scheme. In other language newsgroups, like the the ruby
> group or what have you, people spend most of their time asking
> questions about how to solve particular problems they're having with
> their production code using the language or what have you. This tends
> to indicate the people involved are largely interested in programming
> languages as a way of accomplishing their work. In the c.l.l and
> c.l.s, however, we have groups of people who are concerned largely
> about linguistic metaissues...
The same faulty conclusion could be drawn from observing the traffic in
comp.instrument.guitar.rock and c.i.g.classical.
:)
kenny
Brian Harvey
>
>The community.
>See the excellent article of Ken Pitman:
I can't believe that people are arguing about whether Scheme is a Lisp!
And especially I can't believe that someone could read Pitman's article,
which takes pains to explain why Dylan is a Lisp even though its goals
are really quite different from the historical Lisp goals and its leaders
come from a different community. Scheme comes from Steele and Sussman
saying "let's see if we can build a Lisp machine on a chip"!
And I can't even believe I'm bothering to respond... :-(
Feuer
> > I meant distinguishing characteristics that would make it a Lisp in
> > particular and not just another functional language. The names of the
> > operators don't show anything but history. Call it lambda, \ ->, or
> > fn => I don't care. Call them cons,car,cdr, :,head,tail, ::,hd,tl
> > Doesn't matter.
>
> Well, it has the same unhealthy facination with lists that are really
> chains of glued together pairs.
This is true. For now. It seems to be changing though.
David
Robert Uhl <ruhl@4dv.net>
>
> > > I meant distinguishing characteristics that would make it a Lisp
> > > in particular and not just another functional language.
> >
> > really chains of glued together pairs.
>
> This is true. For now. It seems to be changing though.
'Cause we all know that Scheme is headed to representing every as
strings? I'm afraid I don't follow.
--
Robert Uhl <ru...@4dv.net>
`How do you explain bikini underwear and chocolate
sprinkles pressed between pages 102 and 103 of the
Canterbury Tales? It must have been quite an evening.'
Jens Axel Søgaard
> "Jens Axel Søgaard" <use...@soegaard.net> writes:
>>> What makes scheme the least bit unlispy, in fact?
>>
>> The community.
>> See the excellent article of Ken Pitman:
>
> I can't believe that people are arguing about whether
> Scheme is a Lisp!
The original question prompted for technical answers.
The Pitman article goes to lengths to emphasize that
that question doesn't make sense.
If the question had been "What makes scheme a bit lispy, in fact?",
I would have responded:
The community.
See the excellent article of Ken Pitman:
...
;-)
--
Jens Axel Søgaard
Ray Dillinger
Feuer wrote:
> The question is: what is a Lisp? Is it anything with sexprs?
> Anything with sexprs and macros? sexprs, macros, and closures?
> sexprs, macros, closures, and dynamically scoped variables?
> All of the above and multiple namespaces? All of the above and
> a powerful eval facility?
To me, the distinguishing features of a lisp are:
Fully parenthesized prefix notation
(Dylan is lisp-inspired and lisp-equivalent, but not a lisp)
Dynamic Typing
(Type is an attribute of a value, not an attribute of a
variable)
First class procedures
(a procedure is just another kind of value, and can be stored
in any variable, returned from functions, passed to functions,
etc)
Lambda (an expression that can be evaluated at runtime to produce a
new procedure depending on its arguments. Sometimes done
with other names, but who cares).
No particular macrology or scoping rules qualify or disqualify a
language from being a lisp. All lisps have to have scoping rules,
but the rules are not the same. All serious lisps have a macrology,
and implementing a lisp without macros would seem pretty pointless,
but I think a lisp without macros would still be a lisp. Just a
mildly braindamaged dialect of lisp.
Other opinions may vary without offending me.
Bear
Brian Harvey
>Fully parenthesized prefix notation
>Dynamic Typing
>First class procedures
>Lambda
It's time to talk about Wittgenstein's insight that words rarely have
sharp boundaries.
Logo lacks all of these except Dynamic Typing. And yet its design
was explicitly based on Lisp, and it clearly belongs in the extended
Lisp family (which also includes Dylan, I guess).
I wouldn't feel guilty about posting a Logo-related question in c.l.l,
although I wouldn't suggest Logo as the dialect of choice to someone
who asked "which version of Lisp should I use?"
Erik Naggum
| Umm... That is an interesting view. I would rather say that people who think
| there is a better way to make a living then wonder how to get a job serving
| burgers get into LAW and POLITICS and DIPLOMACY ... are people who are not
| interested in working at all.
What was the significance of the "then" that replaced my "than"? Presuming
it has meaning, I am unable to understand what you mean fully. I also
wonder what kind of misguided notions "work" that make up the substance of
your opinion. May I offer a counter-view that muscle-time is irrelevant and
the only measure of the amount of work involved is the brain-time needed.
| As for politics not being religion ... I was "fortunate" enough to have been
| born in a communist run country, and know very well that communism (probably
| most of the other "politics" as well) is very much a religion at its best --
| cause if you speak up; they will burn you!
It is religion that has elements of politics, not the other way around.
Perry E. Metzger
Erik Naggum <er...@naggum.no> writes:
> * "Perry E. Metzger" <pe...@piermont.com>
> | Perhaps we could have a new discussion about why it is that people
> | think that religion is more interesting than writing programs.
>
> Perhaps people who use Common Lisp and Scheme are already adept at
> writing programs and no longer have the pathetic little problems
> that so plague the newer languages
Perhaps, but I doubt it. I've been writing software in a variety of
languages for... well, I don't want to think about it but I started on
PDP-8s a long time ago. I still learn new things all the time. Hell, I
even learn whole new paradigms.
What I've noticed in a lot of people in this community (and it really
is just one community) is a lot of arrogance. Being a very arrogant
person at times, I can perhaps recognize the symptom a bit better than
most. I have often made the mistake of thinking I knew more than I
really did, but I've been working pretty hard on keeping my mind open
instead, and it often brings results.
> and are interested in politics (not religion) just as people
> who think there is a better way to make a living than wonder how to get a
> job serving burgers get into law and politics and diplomacy and standards.
I don't know about that. I'd expect that if the community was truly
vibrant we'd be seeing things like equivalents to CPAN and such. It is
not disgraceful to say "I'm writing an application that needs to
interface with database X, anyone have a binding written already" or
what have you. Perhaps the Lisp community is beyond actually having to
use its language day to day but I doubt that.
> That you have no better grasp of the higher levels of society than to call
> it "religion" unfortunately speaks volumes about your own outlook on that
> which transcends petty problems expressing simple algorithms in languages
> younger than their practitioners' computers.
I've been programming long enough to know that when you're more
concerned about what the right comment character is than about writing
good comments you're not on the level of the important any longer. I
also know that the nuts and bolts of getting work done is the petty
problem of expressing algorithms for execution by machine, not the
discussion of whether the guys who use language-flavor Y are apostates
who must be banned from the church.
Software, unlike theoretical mathematics, is largely about
accomplishing things. That leads people to unfortunate mundane
concerns like finding a module that builds web pages for you or
finding a module that interfaces to Oracle or finding a module that
does statistical analysis for you. When a language's devotees no
longer discuss such pragmatic matters and instead spend all their
energy on religion, it implies they are not writing code.
Perry E. Metzger
>
> > Although, in the conclusion, it states that one might
> > care to view Scheme as not Lisp.
>
> Depending on the political context:
Politics is the death of engineering. Engineering is about getting
things built. Computer languages are a tool for doing that, with
better languages being (hopefully) a better tool. When one spends
one's energy on politics rather than progress towards the goal,
though, one takes a serious turn off of the road and into the weeds.
I'm here because there are programs I want to see written, not because
I believe that my political party is better than another or what have
you. If Lisp is a political party and not a programming language, then
let the death of Lisp come quickly -- it will have outlived its
usefulness for mankind.
Perry E. Metzger
spe...@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
> Perry> It is hard to see why scheme would not be considered a lisp but emacs
> Perry> lisp or interlisp or the lisp in the sawfish window manager or
> Perry> whatever would not be. It is certainly not even an unusual dialect --
> Perry> lisp 1 also had the unified function/variable namespace, the lexical
> Perry> scoping is now the norm rather than unusual, etc. What makes scheme
> Perry> the least bit unlispy, in fact?
>
> The fact that code and data are not the same.
R5RS seems to define an "eval" which appears to take an sexpr and
treat it like code. Is there something more subtle that Scheme has
here that no other lisp has ever had?
Perry E. Metzger
Common Lisp is no different in that respect -- all modern lisps seem
to have vectors, hashes, structures, etc.
Barry Margolin
Brian Harvey <b...@cs.berkeley.edu> wrote:
>Ray Dillinger <be...@sonic.net> writes:
>>Fully parenthesized prefix notation
>>Dynamic Typing
>>First class procedures
>>Lambda
>
>It's time to talk about Wittgenstein's insight that words rarely have
>sharp boundaries.
>
>Logo lacks all of these except Dynamic Typing. And yet its design
>was explicitly based on Lisp, and it clearly belongs in the extended
>Lisp family (which also includes Dylan, I guess).
It may have been inspired by Lisp, but it sounds like they discarded most
of Lisp's distinguishing features. Except for dynamic typing, what's left
that keeps it in the Lisp family? I suppose there's also the interactive
listener, which supports one of Lisp's popular uses: exploratory
programming. Perhaps the read-eval-print loop should be added as a common
feature of Lisps (even if an implementation provides a way to compile into
standalone executables, it usually also provides a listener).
>I wouldn't feel guilty about posting a Logo-related question in c.l.l,
>although I wouldn't suggest Logo as the dialect of choice to someone
>who asked "which version of Lisp should I use?"
As a Lisper, I expect that I would have a fairly easy time learning Logo,
because it was inspired by Lisp (not to mention that it was designed to be
easy to learn, since it's targeted at young children). But I wouldn't
expect most c.l.l participants to be able to answer Logo questions just
because they know Lisp. Some of them might also have experience with Logo,
but I would consider it almost coicidental. If I were to post a Logo
question there, I'd probably preface it with something like "I know this is
off-topic, but I figured I'd find more Logo enthusiasts here than in
comp.lang.misc." I.e. I *would* feel a little guilty, but choose it as a
lesser of evils.
Perl has dynamic typing (although it's a little weird, because sometimes
objects morph from one type to another, depending on how they're being
used), first class procedures, and lambda. It also has automatic memory
management, another earmark of Lisps. So the only thing it's presumably
missing to be a Lisp is the parenthesized prefix notation (i.e. it seems to
be almost as close to Lisp as Dylan is). It doesn't have the interactive
listener I mentioned above, but since it has "eval" it would be pretty easy
to add (and you can get a little bit of it using the Perl debugger or "perl
-e '<commands>'").
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Hrvoje Blazevic
> What was the significance of the "then" that replaced my "than"? Presuming
> it has meaning, I am unable to understand what you mean fully.
Just a typo!
> I also
> wonder what kind of misguided notions "work" that make up the substance of
> your opinion. May I offer a counter-view that muscle-time is irrelevant and
> the only measure of the amount of work involved is the brain-time needed.
I also wonder what led you to believe that I would value selling burgers more
than the brain-time. Is it because you believe that it is only lawyers,
politicians and diplomats that do use brain-power?
Brian Harvey
>As a Lisper, I expect that I would have a fairly easy time learning Logo,
>because it was inspired by Lisp (not to mention that it was designed to be
>easy to learn, since it's targeted at young children). But I wouldn't
>expect most c.l.l participants to be able to answer Logo questions just
>because they know Lisp.
Oops, sorry, I misspoke. I didn't mean that I'd post "how do you do
such-and-such in Logo?" in c.l.l; what I had in mind was more like
"I'm trying to implement a garbage collector for my Logo interpreter
and..." For the former question category there's a comp.lang.logo,
but I wouldn't expect to find much deep technical expertise there -- and
the deep questions would scare away the teachers anyway. :-)
Erik Naggum
| I also wonder what led you to believe that I would value selling burgers
| more than the brain-time. Is it because you believe that it is only lawyers,
| politicians and diplomats that do use brain-power?
No. I consider this "discussion" to have ended some time ago.
Jens Axel Søgaard
> -- and the deep questions would scare
> away the teachers anyway. :-)
"Hey, Kid leave those teachers alone!"
--
Jens Axel Søgaard
Sander Vesik
> Feuer <fe...@his.com> writes:
>>
>> > > I meant distinguishing characteristics that would make it a Lisp
>> > > in particular and not just another functional language.
>> >
>> > Well, it has the same unhealthy facination with lists that are
>> > really chains of glued together pairs.
>>
>> This is true. For now. It seems to be changing though.
>
> 'Cause we all know that Scheme is headed to representing every as
> strings? I'm afraid I don't follow.
>
It could keep lists in something else than a chain of pairs format...
Thomas Bushnell, BSG
> I've been programming long enough to know that when you're more
> concerned about what the right comment character is than about writing
> good comments you're not on the level of the important any longer. I
> also know that the nuts and bolts of getting work done is the petty
> problem of expressing algorithms for execution by machine, not the
> discussion of whether the guys who use language-flavor Y are apostates
> who must be banned from the church.
I think the point is that an important goal for Scheme is to do it
right, dammit, or not at all. This would be horrible if Scheme were
the only choice, but it's not. Since there are a jillion decent
programming languages with the attitude "who cares what the comment
character is", what's wrong with there being *one* that wants to get
it right, dammit.
Software Scavenger
in Common Lisp, Scheme, and other languages".
William D Clinger
> Perhaps people who use Common Lisp and Scheme are already adept at writing
> programs and no longer have the pathetic little problems that so plague the
Isn't it pretty to think so?
Ernest Hemingway
Craig Brozefsky
> "Jens Axel Søgaard" <use...@soegaard.net> writes:
> > ru...@4dv.net wrote:
> >
> > > Although, in the conclusion, it states that one might
> > > care to view Scheme as not Lisp.
> >
> > Depending on the political context:
>
> Politics is the death of engineering. Engineering is about getting
> things built. Computer languages are a tool for doing that, with
> better languages being (hopefully) a better tool. When one spends
> one's energy on politics rather than progress towards the goal,
> though, one takes a serious turn off of the road and into the weeds.
I'm inclined to think this is an expression of a naive and secluded
notion of engineering and what it means to "get things built",
particularly when the things being built require the cooperation and
resources of dozens, perhaps hundreds, and in some cases entire
nations. Your statement may hold true for personal projects, or ones
where you already have control over the needed resources, but those
are really simple and small problems and certainly do not justify a
blanket statement about engineering.
Bruno LaTour's "Aramis, or The Love of Technology" is an interesting
book that I think is relevant to this issue of politics and
engineering.
--
Sincerely,
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
Erik Naggum
| What I've noticed in a lot of people in this community (and it really
| is just one community) is a lot of arrogance.
Funny, that, I see a lot of humility and respect for the opinions and
thoughts of those older and wiser than oneself. There is virtually no
arrogance among the cognoscenti. My experience has been one of great
patience and willingness to help those who wish to learn. However, when
some arrogant little snot of a newbie walks into the forum only to spout his
own arrogant views without listening to anybody else, the /newbie/ will
think this is arrogance. If you are an arrogant newbie, people around you
will generally return the favor. If you are interested in learning things
from those who know, the Lisp communities are better than most. Well, at
least comp.lang.lisp. The comp.lang.scheme people have generally been on
the defensive even when they are not attacked in any way, which I can only
interpret as symptoms of a very /protective/ crowd. However, it has never
been /arrogance/ that I have found even in the hostility towards comments on
the severely limited Scheme model.
| Being a very arrogant person at times, I can perhaps recognize the symptom a
| bit better than most.
Perhaps you do much too well? Arrogant people tend to trigger arrogant
responses from others, too. It is a stupid human tendency that is only
changed by limiting or removing one's own arrogance.
| I have often made the mistake of thinking I knew more than I really did, but
| I've been working pretty hard on keeping my mind open instead, and it often
| brings results.
Most of the people I have found in the Common Lisp community have been well
aware, not only of how much they know, but of where it came from and how
they arrived at the conclusions they hold, so that they can communicate this
to others when they need to defend their opinions. Rapid internalization of
new knowledge and the ability to integrate it with other information make it
possible to produce intelligent observations and connections. All of these
attributes indicate both "intelligent" and "observant" to me, and not the
dumb and judgmental attributes that correlate with arrogance.
| I don't know about that. I'd expect that if the community was truly vibrant
| we'd be seeing things like equivalents to CPAN and such.
I think this shows your arrogance more than anything else. You are obviously
not willing to consider the fact that CPAN and the like depend on much more
than "vibrant communities" to exist. In particular, they depend on the
comparative worthlessness of the time spent on making software for their
languages. When the time you spend writing software is both worth paying
for and it is worth paying others for their time, you get a vibrant /market/,
not a vibrant library of free software. You also do not solve problems that
people are willing to solve for free.
| I've been programming long enough to know that when you're more concerned
| about what the right comment character is than about writing good comments
| you're not on the level of the important any longer.
Just so we have this clear: You think somebody is arguing over the right
comment character? Where did this happen? And moreover, why is this so
important to you that you think it reflects on the whole community?
| I also know that the nuts and bolts of getting work done is the petty
| problem of expressing algorithms for execution by machine, not the
| discussion of whether the guys who use language-flavor Y are apostates who
| must be banned from the church.
And just so we have this clear, too: This happened where? And it was
important to you why? Perhaps I do not understand your problems, like I do
not understand the most recent troll in comp.lang.lisp who whines about the
syntax. Trolls are not representative of the community in any way. You
should know this, I think.
| Software, unlike theoretical mathematics, is largely about accomplishing
| things. That leads people to unfortunate mundane concerns like finding a
| module that builds web pages for you or finding a module that interfaces to
| Oracle or finding a module that does statistical analysis for you. When a
| language's devotees no longer discuss such pragmatic matters and instead
| spend all their energy on religion, it implies they are not writing code.
I would like you to think about and enumerate the many other assumptions
that went into this rather strange conclusion. The most important (at least
to refute your conclusion) assumption is why these things are important to
you. You are undoutedly right that these things happen, just as we find the
most brilliant mind sometimes uttering stupid comments unwittingly, but does
that prove anything? I do not in any way wish to deny that these things are
sometimes discussed and are consuming the time of many people when they do,
but I wonder why you select these events and similarly ignore the events when
people discuss application-oriented aspects equally consumingly. I tend to
think of the former as supporting the notion that people want to think in
their languages an therefore need syntax that fits their thinking. It is only
to the very shallow that syntax does not matter.
Erik Naggum
| Isn't it pretty to think so?
|
| Ernest Hemingway
Nice quotation. Sometimes, I think people think ugly because they do not
want pretty to be an option in the real world. There is a implicit accusation
in this quotation that if it is pretty, it cannot be true, and if you believe
the pretty option, you are naïve. This attitude is unfortunately very hard
to combat, since those who believe in such things are amazingly unwilling to
accept that the world can have pretty parts when their whole life experience
has been that none of it is.
Perry E. Metzger
Erik Naggum <er...@naggum.no> writes:
> * Perry E. Metzger
> | What I've noticed in a lot of people in this community (and it really
> | is just one community) is a lot of arrogance.
>
> Funny, that, I see a lot of humility and respect for the opinions and
> thoughts of those older and wiser than oneself. There is virtually no
> arrogance among the cognoscenti.
When I asked one of the high cognoscs about the absence of an i/o
multiplexing primitive in his dialect because I needed one for doing
some event driven programming, I was regaled with why event driven
programming is stupid and ugly and I should be using threads
instead. I've had a dozen such experiences of late.
> My experience has been one of great patience and willingness to
> help those who wish to learn. However, when some arrogant little
> snot of a newbie walks into the forum only to spout his own
> arrogant views without listening to anybody else, the /newbie/
> will think this is arrogance.
I think calling anyone an "arrogant little snot" tends to lessen the
power of one's claim to humility, don't you?
> | I don't know about that. I'd expect that if the community was
> | truly vibrant we'd be seeing things like equivalents to CPAN and such.
>
> I think this shows your arrogance more than anything else. You
> are obviously not willing to consider the fact that CPAN and the
> like depend on much more than "vibrant communities" to exist. In
> particular, they depend on the comparative worthlessness of the
> time spent on making software for their languages.
Ah, that explains it. Thank you for enlightening me.
Stephen J. Bevan
> vibrant we'd be seeing things like equivalents to CPAN and such.
By this measure, which languages are truly vibrant? I'm particularly
interested in any that have multiple (say >= 3) implementations.
Thomas Bushnell, BSG
> When I asked one of the high cognoscs about the absence of an i/o
> multiplexing primitive in his dialect because I needed one for doing
> some event driven programming, I was regaled with why event driven
> programming is stupid and ugly and I should be using threads
> instead. I've had a dozen such experiences of late.
I think the cognoscs are right here. Threads and multiplexing
primitives are duals of each other anyway, so if you are given
threads, you can easily create the multiplexing primitive you want.
But organizing design around non-blocking I/O primitives (from an OS
design standpoint) turns out to be much more complex and error prone
than having straightforward subroutine blocking primitives, and
telling users to use threads if they want multiplexing.
So that's why you get told that: it's actually the right thing. If
the best way to represent your computation is with a non-blocking or a
multiplexing interface, then it's very easy to implement that using
the threads you've been given.
Perry E. Metzger
ste...@dino.dnsalias.com (Stephen J. Bevan) writes:
> "Perry E. Metzger" <pe...@piermont.com> writes:
> > I don't know about that. I'd expect that if the community was truly
> > vibrant we'd be seeing things like equivalents to CPAN and such.
>
> By this measure, which languages are truly vibrant?
Vibrant might be the wrong term. Lets just say "being so actively used
by large communities that lots of tools and libraries are available on
the net".
By that measure, we're talking about C, C++, Java, Perl, Ruby, Tcl/Tk
(Tcl makes my teeth itch but never mind that), Python, and doubtless a
few others I'm forgetting or unaware of.
I'm not passing any moral judgments here, by the way. Just noting
what has become popular enough that you can go out and at will find
yourself books like "Programming the Perl DBI" or libraries to
generate web log templates or what have you. People might discount the
importance of such things, but they're a pretty big part of the way
modern people put together apps. It is a lot easier to steal someone's
RFC822 parser that they've put up on the net than to write one,
regardless of the language, and when there is a critical mass of such
stuff available it makes a difference in your life.
Peter Keller
: Erik Naggum <er...@naggum.no> writes:
:> * Perry E. Metzger
:> | I don't know about that. I'd expect that if the community was
:> | truly vibrant we'd be seeing things like equivalents to CPAN and such.
:>
:> I think this shows your arrogance more than anything else. You
:> are obviously not willing to consider the fact that CPAN and the
:> like depend on much more than "vibrant communities" to exist. In
:> particular, they depend on the comparative worthlessness of the
:> time spent on making software for their languages.
It is statements like these that cause me to pick another popular C
library to write an FFI interface for in the scheme implementation
I've chosen.
I'm beginning to believe that the reason scheme isn't as popular as the
rest of the languages isn't so much as there are many implementations, but
more so that no-one understands how to market it worth a damn.
Seen any oreilly books on scheme, or scheme interfaces to SQL or anything like
that? My point exactly.
--
-pete
E-mail address corrupted to stop spam.
Reply mail: psilord at cs dot wisc dot edu
I am responsible for what I say, noone else.
Erik Naggum
| When I asked one of the high cognoscs about the absence of an i/o
| multiplexing primitive in his dialect because I needed one for doing some
| event driven programming, I was regaled with why event driven programming is
| stupid and ugly and I should be using threads instead. I've had a dozen
| such experiences of late.
And this is an argument for what, precisely? Like, /whose/ arrogance?
| I think calling anyone an "arrogant little snot" tends to lessen the power
| of one's claim to humility, don't you?
No, of course not. I am humble in the face of the field of mathematics, in
awe of the great number of geniuses before me, greatly inspired by the works
of many brilliant minds that could both conceive of the most elegant
concepts and their intricate interrelationships and formulate them so
cleanly and briefly in books that I could read and grasp their ideas in but
a minute fraction of the time it took them to develop them, and yet I am
disgusted to the deepness of my soul by the lack of even the most basic
arithmetical skills and the rampant innumeracy of many journalists and
politicians, because those are people who are so unequivocally /not/ humble
in the face of mathematics, lacking any and all appreciation of the field,
yet have the gall to abuse simple results in the field in a way that shows
an utter disrespect for all the great minds that made it possible for them
to have a chance to grasp mathematical ideas in their compulsory education,
but discarded that chance and instead spit in the face of every mathematical
thinker with their every breath.
| Ah, that explains it. Thank you for enlightening me.
You're welcome. I note that the intelligent /exchange/ of ideas has ceased.
Christopher Browne
> I don't know about that. I'd expect that if the community was truly
> vibrant we'd be seeing things like equivalents to CPAN and such. It is
> not disgraceful to say "I'm writing an application that needs to
> interface with database X, anyone have a binding written already" or
> what have you. Perhaps the Lisp community is beyond actually having to
> use its language day to day but I doubt that.
I think we _are_ seeing something like CPAN in the form of CCLAN.
The efforts are somewhat less integrated and less coherent than is the
case for Perl (or Python, or Ruby, with their respective communities),
but that isn't _too_ surprising what with there being an actually
diverse set of Common Lisp implementations.
There is _somewhat_ less demand for CPAN-like stuff for Common Lisp
since the base language has a bit more in it.
It is _somewhat_ more difficult to construct CPAN-like stuff because
there are a multiplicity of CL implementations.
On the Scheme side of the fence, it's _much_ more difficult to see
common code get deployed for a multiplicity of Scheme implementations
because the base language is so much smaller. The SRFI process is
nonetheless supplying at least _some_ of this. And we periodically
hear more about things designed for scsh getting ported more widely
:-).
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/lisp.html
"High-level languages are a pretty good indicator that all else is
seldom equal." - Tim Bradshaw, comp.lang.lisp
Erik Naggum
| It is statements like these that cause me to pick another popular C library
| to write an FFI interface for in the scheme implementation I've chosen.
No, it is not. If you had understood the word "comparative", you would not
have been able to use my statements to support your preconceived notions.
Kenny Tilton
Perry E. Metzger wrote:
> I'm not passing any moral judgments here, by the way. Just noting
> what has become popular enough that you can go out and at will find
> yourself books like ...
Then let's not leave COBOL and Pascal off the "vibrant" list. Remember
those popular languages?
kenny
Christopher Browne
> I'm beginning to believe that the reason scheme isn't as popular as
> the rest of the languages isn't so much as there are many
> implementations, but more so that no-one understands how to market
> it worth a damn.
> Seen any oreilly books on scheme, or scheme interfaces to SQL or
> anything like that? My point exactly.
O'Reilly also doesn't have books on Common Lisp, and aren't accepting
new titles on TeX or _any_ form of Lisp, so I'd not count that as
being of much interest.
And the following bit of Guile code does _exactly_ what it would be
expected to do, namely interface with PostgreSQL, and pull a set of
entries.
(use-modules (database postgres))
(define test (pg-connectdb "dbname=sqlledger"))
(define result (pg-exec test "select * from zipcode"))
(let loop ((index 0))
(if (< index (pg-ntuples result))
(begin
(display (pg-getvalue result index 0))
(display (pg-getvalue result index 1))
(display (pg-getvalue result index 2))
(display (pg-getvalue result index 3))
(display (pg-getvalue result index 4))
(newline)
(loop (+ index 1)))))
The PG binding is a little more "primitive" than you'd usually use in
CL, basically eschewing all use of macros, and not really providing
any help with transactions/cursors (both being places where some
well-place macros would be _really_ useful).
But it exists, and it works, and I just used it to blow up an Emacs
buffer by showing 80,000-odd zipcodes.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://cbbrowne.com/info/oses.html
Coming Soon to a Mainframe Near You! MICROS~1 Windows NT 6.0,
complete with VISUAL JCL...
Perry E. Metzger
Kenny Tilton <kti...@nyc.rr.com> writes:
> Perry E. Metzger wrote:
> > I'm not passing any moral judgments here, by the way. Just noting
> > what has become popular enough that you can go out and at will find
> > yourself books like ...
>
> Then let's not leave COBOL and Pascal off the "vibrant" list.
I'm afraid I must. I can't find large COBOL libraries anywhere on the
net, and there isn't any place to find large Pascal libraries,
either. The same can't be said about C or Python.
Peter Keller
: * Peter Keller <psi...@data.upl.cs.wisc.edu>
: | It is statements like these that cause me to pick another popular C library
: | to write an FFI interface for in the scheme implementation I've chosen.
: No, it is not. If you had understood the word "comparative", you would not
: have been able to use my statements to support your preconceived notions.
SunOS buzzard > webster comparative
1 com.par.a.tive adj \k*m-'par-*t-iv\
1 : of, relating to, or constituting the degree of comparison in
a language that denotes increase in the quality, quantity, or
relation expressed by an adjective or adverb
2 : considered as if in comparison to something else as a
standard not quite attained : RELATIVE [~
stranger]
3 : studied systematically by comparison of phenomena [~
literature]
com.par.a.tive.ly adv
com.par.a.tive.ness n
2 comparative n
1 : one that compares with another esp. on equal footing
: RIVAL; specif : one that makes witty
or mocking comparisons
2 : the comparative degree or form in a language
I'm sorry, but I guess I just don't understand how you wanted to use it in
the context with "worthless".
Perry E. Metzger
I promised someone that I was off this thread, but I will answer this
one last message on it.
tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> "Perry E. Metzger" <pe...@piermont.com> writes:
> > When I asked one of the high cognoscs about the absence of an i/o
> > multiplexing primitive in his dialect because I needed one for doing
> > some event driven programming, I was regaled with why event driven
> > programming is stupid and ugly and I should be using threads
> > instead. I've had a dozen such experiences of late.
>
> I think the cognoscs are right here. Threads and multiplexing
> primitives are duals of each other anyway,
Actually, they aren't in practice -- there's a huge performance
difference. I could go into a long argument on why it is that event
driven programs are actually quite straightforward to write (they are
no more alien than functional programming is -- it is just a different
style), why they are much easier to write than thread driven programs
for certain applications (among other things, you end up with much
more elegant designs), and why in general the performance on real
hardware of event driven code is going to always be better than that
of thread driven code. I think this is all a digression though. We
aren't talking about threads vs. events. We're talking about an
attitude in the community.
The annoyance here is people assuming they know "the right thing" and
attempting to impose it, assuming they know more than the person
inquiring about his problem space. Maybe someone for whatever reason
needs to do something you don't particularly like -- work in an object
oriented style or a logic programming style or whatever style you
happen not to agree with this week. You aren't likely to be "right"
when you tell them "no that's stupid", you're just likely to be
expressing taste rather than "The Truth".
The Truth is that there isn't always a The Truth. Just because there
are problems with object systems doesn't mean objects are always
stupid. Just because you don't like someone writing a network protocol
that uses XML instead of sexprs doesn't mean that they don't have to
interface with something someone else built regardless of your
taste. Just because you might think there are no conditions in which
it might be better to do non-compacting garbage collection doesn't
mean someone might not have a condition in which he needs a
non-compacting collector, etc.
At best you can say "my experience is that it would be better for you
to use a hash table for this instead of a PATRICIA tree, but you can
implement the PATRICIA tree using structures this way..." and hell,
maybe it even turns out that the guy knows more about routing than you
do because he's a routing guy and you aren't and PATRICIA trees are
optimal for that problem.
> So that's why you get told that: it's actually the right thing.
I find in general that The Right Thing is hard to impose. I was
running a NetBSD related company for a couple of years. I found that
people want threads for some apps, and even though I didn't like
threads, I paid someone to work on a better performing threads
mechanism because some people find they're more convenient some of the
time than the techniques I prefer.
I could have told those people that they were idiots but they weren't
idiots -- they had reasons for wanting to use a technique other than
the one I found ideal and I couldn't really claim to understand their
problem domain as well as they did, so I shut up and worked on giving
them what they needed rather than what I felt The Right Thing was. I
had no idea if my notion of The Right Thing was right anyway. I am not
omniscient, and this is engineering, not mathematics.
In general, the languages and systems that win are the ones with the
least ideological axe to grind. I find that's true with people, too.
Feuer
"Robert Uhl " wrote:
> > > Well, it has the same unhealthy facination with lists that are
> > > really chains of glued together pairs.
> >
> > This is true. For now. It seems to be changing though.
>
> 'Cause we all know that Scheme is headed to representing every as
> strings? I'm afraid I don't follow.
Because many Schemes now support structures/records and there is an
SRFI describing them. So less things will be done with pairs when
they really shouldn't be.
David
Ray Blaak
> The Truth is that there isn't always a The Truth.
Amen brother!
Seriously, hanging out on both c.l.l and c.l.s will quickly demonstrate that
the viritol level in the former is much much higher. Whether it is political
or religious is rather irrelevant, c.l.l is simply more intolerant.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.
Peter Keller
: In the last exciting episode, Peter Keller <psi...@data.upl.cs.wisc.edu> wrote::
:> I'm beginning to believe that the reason scheme isn't as popular as
:> the rest of the languages isn't so much as there are many
:> implementations, but more so that no-one understands how to market
:> it worth a damn.
:> Seen any oreilly books on scheme, or scheme interfaces to SQL or
:> anything like that? My point exactly.
: O'Reilly also doesn't have books on Common Lisp, and aren't accepting
: new titles on TeX or _any_ form of Lisp, so I'd not count that as
: being of much interest.
Well, I can buy an oreilly book on "mastering regular expressions" but not
"mastering macros". Why? Why doesn't oreilly accept books for lisp-like
lanauges, and why isn't there a book out there like a "macro cookbook"
which talks about the various forms of macro representation and what
you can do with them with good *and relevant* examples by any publisher
at all? The regex book pulled it off and there are a BUNCH of regular
expression styles out there that are incompatible.
: And the following bit of Guile code does _exactly_ what it would be
: expected to do, namely interface with PostgreSQL, and pull a set of
: entries.
I wasn't talking about implementations. I was talking about why I can
wander to a book store and see shelf upon shelf of ASP/JAVA/PERL/C++/SQL
books and then find exactly one grungy SICP book mislocated into the
COBOL section--the only scheme book to be found.
<rant>
You want religion? I'll give you religion:
So, I'm sitting at work and my office mate says he wants to learn scheme
to implement a project that scheme would be a perfect match for. So,
I get to helping him learn it, but he is obviously shy about it. So,
I ask him about it and do you know what he says?
"Scheme and Lisp, in general, are pretentious. It tries to be a magic
bullet which attempts to solve all problems but the solutions it comes
up with (everything is a heterogeneous list, strange typechecking, wierd
development environment, strange/bad error reporting) just get in the
way of doing "real work". Also, they think their way is the "right and
only way" and that just bothers me."
I didn't know how to answer him other than some fast excuse that scheme is
just like any other language, you just have to think a little differently
to use its full potential. To which he scowled at me, as if I had made
true his thoughts about the subject, but continued to learn it because
scheme really WAS the best solution for his problem.
</rant>
It is this kind of stigma that is the reason scheme isn't popular. I don't
know how to stop it or break it, other than to continue to implement
tools and libraries for a *single* implementation--and make them widely
known, so more people get exposed to it. The more people that get exposed
to something that works, meaning _useful_ and _public_ tools get written in it,
the more people will start to use it and not care about "religion".
As for me? I don't give a rats ass about religion, flamewars, or the
"right way" to do things or any of that shit. I just care if it works,
it is a "reasonable" implementation, and is understandable by the next
person when I leave.
That is all.
Stephen J. Bevan
> Vibrant might be the wrong term. Lets just say "being so actively used
> by large communities that lots of tools and libraries are available on
> the net".
>
> By that measure, we're talking about C, C++, Java, Perl, Ruby, Tcl/Tk
> (Tcl makes my teeth itch but never mind that), Python, and doubtless a
> few others I'm forgetting or unaware of.
Of these only C, C++ and Java pass my arbitrary "more than 3
implementations" requirement. Even there Java stands out from the
other two in that while there are multiple implementations, Sun pretty
much dictates the direction of Java in the same way that the authors
of the single implementation languages do.
That leaves C and C++, neither of which have anything like CPAN.
Instead you can find various libraries in many places, which vary from
working on almost all implementations to those which work only on
specific platforms or even specific compilers (e.g. Linux kernel isn't
going to compile with anything but gcc anytime soon).
So two possible broad categories of vibrant languages :-
1. Languages in which a single person/company controls the language.
2. C/C++
or another possible split is :-
a. "scripting" language with one (or two) implementation(s)
b. C/C++/Java
None of the following fit into any category: Ada, APL, Common Lisp,
Forth, Haskell, Scheme, SML and Smalltalk. All have some archives,
but nothing that approaches CPAN. There are also some languages that
do fit in category 1 such as Clean, Erlang and O'Caml which also don't
have anything that approaches CPAN (though Caml Hump is pretty
impressive).
The point being that compared to C/C++/Java and a handful of scripting
languages it seems that no languages are vibrant.
Friedrich Dominicus
> In comp.lang.scheme Christopher Browne <cbbr...@acm.org> wrote:
> : In the last exciting episode, Peter Keller <psi...@data.upl.cs.wisc.edu> wrote::
> :> I'm beginning to believe that the reason scheme isn't as popular as
> :> the rest of the languages isn't so much as there are many
> :> implementations, but more so that no-one understands how to market
> :> it worth a damn.
>
> :> Seen any oreilly books on scheme, or scheme interfaces to SQL or
> :> anything like that? My point exactly.
>
> : O'Reilly also doesn't have books on Common Lisp, and aren't accepting
> : new titles on TeX or _any_ form of Lisp, so I'd not count that as
> : being of much interest.
>
> Well, I can buy an oreilly book on "mastering regular expressions" but not
> "mastering macros". Why? Why doesn't oreilly accept books for lisp-like
> lanauges, and why isn't there a book out there like a "macro cookbook"
> which talks about the various forms of macro representation and what
> you can do with them with good *and relevant* examples by any publisher
> at all?
what's wrong with OnLisp?
http://www.paulgraham.com/onlisptext.html
It does exactly what you ask for explaining Macros.
Regards
Friedrich
Stephen J. Bevan
> primitives are duals of each other anyway, so if you are given
> threads, you can easily create the multiplexing primitive you want.
In theory. In practice I can't get a small Solaris, Linux, FreeBSD,
OpenBSD ... etc. box to run very well with 10,000 threads (one per
connection) but I can get it to run quite well with 10,000 connections
all being served by a single /dev/poll, kqueue or poll (ugh). If
someone can make 10,000 threads run well on these platforms I'll give
up event driven approach in a flash. I'm not holding my breath
though.
Michael Sperber [Mr. Preprocessor]
Perry> spe...@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Perry> It is hard to see why scheme would not be considered a lisp but emacs
Perry> lisp or interlisp or the lisp in the sawfish window manager or
Perry> whatever would not be. It is certainly not even an unusual dialect --
Perry> lisp 1 also had the unified function/variable namespace, the lexical
Perry> scoping is now the norm rather than unusual, etc. What makes scheme
Perry> the least bit unlispy, in fact?
>>
>> The fact that code and data are not the same.
Perry> R5RS seems to define an "eval" which appears to take an sexpr and
Perry> treat it like code. Is there something more subtle that Scheme has
Perry> here that no other lisp has ever had?
Yes. EVAL just means you can convert data to code, it doesn't mean
they're the same. (EVAL also is a quite recent re-addition to the
standard.) In Lisp, you can usually do things like
(funcall '+ 1 2)
or
(funcall '(lambda (x) (+ x 1)) 5)
which you can't do in Scheme.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Erik Naggum
| Seriously, hanging out on both c.l.l and c.l.s will quickly demonstrate that
| the viritol level in the former is much much higher. Whether it is political
| or religious is rather irrelevant, c.l.l is simply more intolerant.
Towards what? We have more people in comp.lang.lisp who spend all their
time complaining vociferously about how intolerant the newsgroup is, yet
they have nothing whatsoever to communicate to anybody. If you have any
brilliant ideas for how to make sure that /nobody/ will respond to these
cretins, please share your insight with you. If, however, all you wish to
do is complain, too, consider yourself part of the problem. Sheesh.
Thien-Thi Nguyen
> As for me? I don't give a rats ass about religion, flamewars, or the
> "right way" to do things or any of that shit. I just care if it works,
> it is a "reasonable" implementation, and is understandable by the next
> person when I leave.
sounds like you should switch to computer engineering. the life of a computer
scientist is full of all of the above (one would gather from observing these
groups). on second thought, engineering is the same... never mind, you're
screwed. (might as well lose your mind now and get it over with. ;-)
what you'll probably come to see and possibly come to appreciate is that to
find the "reasonable" one has to do all sorts of unreasonable things/thinking.
unless, of course, you have the luxury of being a machine to be programmed by
these pesky humans... then you can rightly blame them for the mess!
ok, time to step up the medication...
thi
Thomas Bushnell, BSG
> Yes. EVAL just means you can convert data to code, it doesn't mean
> they're the same. (EVAL also is a quite recent re-addition to the
> standard.) In Lisp, you can usually do things like
>
> (funcall '+ 1 2)
>
> or
>
> (funcall '(lambda (x) (+ x 1)) 5)
>
> which you can't do in Scheme.
What? No you can't.
(funcall '+ 1 2)
gets you an error. You mean
(funcall #'+ 1 2).
The Common Lisp:
(funcall #'A B C ...)
is equivalent to Scheme's:
(A B C ...)
Jon Kåre Hellan
Michael Sperber [Mr. Preprocessor]
Thomas> spe...@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
>> Yes. EVAL just means you can convert data to code, it doesn't mean
>> they're the same. (EVAL also is a quite recent re-addition to the
>> standard.) In Lisp, you can usually do things like
>>
>> (funcall '+ 1 2)
>>
>> or
>>
>> (funcall '(lambda (x) (+ x 1)) 5)
>>
>> which you can't do in Scheme.
Thomas> What? No you can't.
I actually just copied this from my Emacs Lisp interaction buffer, so
I'm pretty sure I can.
Thomas> You mean
Thomas> (funcall #'+ 1 2).
So that would be *Common* Lisp, I guess. So I guess Common Lisp is
not a Lisp either. But then again:
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I I I I I I I 8 8 8 8 8 8
I I I I I I I 8 8 8 ooooo 8oooo
I \ `+' / I 8 8 8 8 8
\ `-+-' / 8 o 8 8 o 8 8
`-__|__-' ooooo 8oooooo ooo8ooo ooooo 8
|
------+------ Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> (funcall '+ 1 2)
3
CLtL2 has this wording:
> funcall fn &rest arguments [Function]
> [...] fn to be only of type symbol or function [...]
You're right in that
(funcall '(lambda (x) (+ x 1)) 5)
isn't allowed in Common Lisp (even though CLisp accepts it), but it
seems that
(apply '(lambda (x) (+ x 1)) '(5))
is legitimate:
> apply function arg &rest more-args [Function]
> [...] The function may be compiled-code object, or a
> lambda-expression, or a symol; [...]
(For a heart-stopping moment, I thought that, by my reasoning, Common
Lisp is not a Lisp either, and that I would have to destroy the Erik
Naggum statuette sitting on the mantelpiece.)
MJ Ray
> [...] Why doesn't oreilly accept books for lisp-like lanauges [...]?
The cynic would say that the amount of money that O'Reilly have sunk into
less powerful languages means that they are maximising the return now. If
they educated people effectively about the more powerful languages, their
back catalogue sales would go through the floor, wouldn't they?
MJ Ray
Tim Bradshaw
> When I asked one of the high cognoscs about the absence of an i/o
> multiplexing primitive in his dialect because I needed one for doing
> some event driven programming, I was regaled with why event driven
> programming is stupid and ugly and I should be using threads
> instead. I've had a dozen such experiences of late.
Isn't this exactly the attitude that Java has (or had, has it changed
now?)
--tim
Erik Naggum
| The cynic would say that the amount of money that O'Reilly have sunk into
| less powerful languages means that they are maximising the return now. If
| they educated people effectively about the more powerful languages, their
| back catalogue sales would go through the floor, wouldn't they?
Before the opinionated speculation takes over completely, go look at this:
http://www.oreilly.com/oreilly/author/writeforus_1101.html
and notice where the word LISP occurs. Become enlightened.
Michael Sperber [Mr. Preprocessor]
Perry> Erik Naggum <er...@naggum.no> writes:
>> * Perry E. Metzger
>> | What I've noticed in a lot of people in this community (and it really
>> | is just one community) is a lot of arrogance.
>>
>> Funny, that, I see a lot of humility and respect for the opinions and
>> thoughts of those older and wiser than oneself. There is virtually no
>> arrogance among the cognoscenti.
Perry> When I asked one of the high cognoscs about the absence of an i/o
Perry> multiplexing primitive in his dialect because I needed one for doing
Perry> some event driven programming, I was regaled with why event driven
Perry> programming is stupid and ugly and I should be using threads
Perry> instead. I've had a dozen such experiences of late.
That would be me (on comp.lang.scheme.scsh), and, until now, I thought
we were having a fruitful exchange on that matter. I guess I was
mistaken, and I apologize if was "regaling" you in any way. It
certainly didn't feel that way to me.
You did forget to mention that the same "high cognosc" (I guess that's
a compliment) promised to implement said multiplexing primitive
exactly to accomodate people like you. In fact, I've actually done
the work by now.
Sander Vesik
> In comp.lang.scheme Christopher Browne <cbbr...@acm.org> wrote:
> : In the last exciting episode, Peter Keller <psi...@data.upl.cs.wisc.edu> wrote::
> :> I'm beginning to believe that the reason scheme isn't as popular as
> :> the rest of the languages isn't so much as there are many
> :> implementations, but more so that no-one understands how to market
> :> it worth a damn.
>
> :> Seen any oreilly books on scheme, or scheme interfaces to SQL or
> :> anything like that? My point exactly.
>
> : O'Reilly also doesn't have books on Common Lisp, and aren't accepting
> : new titles on TeX or _any_ form of Lisp, so I'd not count that as
> : being of much interest.
>
> Well, I can buy an oreilly book on "mastering regular expressions" but not
> "mastering macros". Why? Why doesn't oreilly accept books for lisp-like
> lanauges, and why isn't there a book out there like a "macro cookbook"
> which talks about the various forms of macro representation and what
> you can do with them with good *and relevant* examples by any publisher
> at all? The regex book pulled it off and there are a BUNCH of regular
> expression styles out there that are incompatible.
O'Reilly is a for-profit comapny last I checked so whetever or not they
will acceptys omething will very probably depend on whetever they see a
market for it. If I was them, I would not accept a scheme or lisp book
either.
>
> : And the following bit of Guile code does _exactly_ what it would be
> : expected to do, namely interface with PostgreSQL, and pull a set of
> : entries.
>
> I wasn't talking about implementations. I was talking about why I can
> wander to a book store and see shelf upon shelf of ASP/JAVA/PERL/C++/SQL
> books and then find exactly one grungy SICP book mislocated into the
> COBOL section--the only scheme book to be found.
>
Because the number of at large scheme developers strating new projects
or releasing new versions of existing ones is terribly slow if you are
interested in the 'per day' amounts. Which also means per-day number
of peopel thinking of participating in such (or starting their own) is
also terribly slow => no books.
>
> That is all.
>
--
Sander
+++ Out of cheese error +++
Sander Vesik
Surely they would just make the money from books talking about all the
middleware and exceiting libraries that you can use in the scheme
and lisp environments? You know, all the ones which names I can't quite
recall at the moment for various obscure reasons (like not existing).
Friedrich Dominicus
> * MJ Ray <markj...@cloaked.freeserve.co.uk>
> | The cynic would say that the amount of money that O'Reilly have sunk into
> | less powerful languages means that they are maximising the return now. If
> | they educated people effectively about the more powerful languages, their
> | back catalogue sales would go through the floor, wouldn't they?
>
> Before the opinionated speculation takes over completely, go look at this:
>
> http://www.oreilly.com/oreilly/author/writeforus_1101.html
>
> and notice where the word LISP occurs. Become enlightened.
This is ridicolous. I can't see any reason for seeing it there. And
fair enough the have books about TeX but refuse some about LaTeX. This
is so idiotic.
Friedrich
Marco Antoniotti
ste...@dino.dnsalias.com (Stephen J. Bevan) writes:
> "Perry E. Metzger" <pe...@piermont.com> writes:
> > I don't know about that. I'd expect that if the community was truly
> > vibrant we'd be seeing things like equivalents to CPAN and such.
>
> By this measure, which languages are truly vibrant? I'm particularly
> interested in any that have multiple (say >= 3) implementations.
You realize that you are essentially disqualifying things like Python
and Perl, don't you?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Bruce Lewis
> What I've noticed in a lot of people in this community (and it really
> is just one community) is a lot of arrogance.
Yes, this is an acknowledged problem. There's a popular Jesse Bowman
quote, "The problem with Lisp is it makes you so damn smug."
Perhaps you can help. If there are these other newsgroups where people
are constantly posting with real-world problems that would be hard to
solve in CL or Scheme, it shouldn't be too much trouble to post one or
two such problems here. Then we would all see how isolated our little
academic exercises are from the real world.
> I've been programming long enough to know that when you're more
> concerned about what the right comment character is than about writing
> good comments you're not on the level of the important any longer.
If you're a language implementor you're talking about something
important. Most newsgroups don't include discussions among different
implementors of the same language.
> Software, unlike theoretical mathematics, is largely about
> accomplishing things. That leads people to unfortunate mundane
> concerns like finding a module that builds web pages for you or
> finding a module that interfaces to Oracle or finding a module that
> does statistical analysis for you. When a language's devotees no
> longer discuss such pragmatic matters and instead spend all their
> energy on religion, it implies they are not writing code.
It may imply they aren't getting a lot of new blood. I'm still writing
code, but I already have a module that builds web pages for me and an
interface to my databases.
--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.codesimply.net/
"alum.mit.edu")]>
Marco Antoniotti
Peter Keller <psi...@data.upl.cs.wisc.edu> writes:
...
>
> I'm beginning to believe that the reason scheme isn't as popular as the
> rest of the languages isn't so much as there are many implementations, but
> more so that no-one understands how to market it worth a damn.
When the spec is small, whipping up another implementation is (too)
easy.
> Seen any oreilly books on scheme, or scheme interfaces to SQL or anything like
> that? My point exactly.
You have not seen a book on Common Lisp (or Scheme) in the O'Reilly
lineup because the have a ban on "Lisp" and "LaTeX".
http://www.oreilly.com/oreilly/author/writeforus_1101.html
Daniel Barlow
> more elegant designs), and why in general the performance on real
> hardware of event driven code is going to always be better than that
For a minute there I thought we were into a potentially interesting
discussion of the different technical approaches to serving multiple
clients
> of thread driven code. I think this is all a digression though. We
> aren't talking about threads vs. events. We're talking about an
> attitude in the community.
But no, you have to drag the conversation back to _religion_. Thank
you for your contribution to the c.l.l signal-to-noise ratio.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Fred Gilham
Erik Naggum <er...@naggum.no> writes:
> Before the opinionated speculation takes over completely, go look at this:
>
> http://www.oreilly.com/oreilly/author/writeforus_1101.html
>
> and notice where the word LISP occurs. Become enlightened.
Well, we can at least be thankful that they didn't put LISP
*immediately* above "pet theories of wombat intercourse".
Though they did put it above "books on topics that have dismal
sales...."
--
Fred Gilham gil...@csl.sri.com || His word is a creative word, and
when he speaks the good exists as good. God is neither arbitrary nor
tyrannical. He is love, and when he expresses his will it is a will
of love. Hence the good given by God is good for us.-- Jacques Ellul
Peter Keller
: Peter Keller <psi...@data.upl.cs.wisc.edu> writes:
: You have not seen a book on Common Lisp (or Scheme) in the O'Reilly
: lineup because the have a ban on "Lisp" and "LaTeX".
: http://www.oreilly.com/oreilly/author/writeforus_1101.html
Huh. I didn't know that....
Nils Goesche
> spe...@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
>
> > Yes. EVAL just means you can convert data to code, it doesn't mean
> > they're the same. (EVAL also is a quite recent re-addition to the
> > standard.) In Lisp, you can usually do things like
> >
> > (funcall '+ 1 2)
> >
> > or
> >
> > (funcall '(lambda (x) (+ x 1)) 5)
> >
> > which you can't do in Scheme.
>
> What? No you can't.
>
> (funcall '+ 1 2)
>
> gets you an error. You mean
>
> (funcall #'+ 1 2).
What are you talking about? Look up ``function designator'' in the
HyperSpec.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0