Joel writes in a new article in Joel on Software about closures in
layman programmer's language.
http://www.joelonsoftware.com/items/2006/08/01.html Although he does
not explicitly say that he is talking about Lisp, in fact he even
delays mentioning Lisp until the end. All his example code is
javascript, and the focus of his article is to drive people away from
"Kingdom of Nouns" Java. But the article sounds very much like a
tribute to Lisp.
Why, does he not explicitly say so?
Alok wrote:
> Joel writes in a new article in Joel on Software about closures in
> layman programmer's language.
> http://www.joelonsoftware.com/items/2006/08/01.html Although he does
> not explicitly say that he is talking about Lisp, in fact he even
> delays mentioning Lisp until the end. All his example code is
> javascript, and the focus of his article is to drive people away from
> "Kingdom of Nouns" Java. But the article sounds very much like a
> tribute to Lisp.
>
> Why, does he not explicitly say so?
Because he doesn't want to look like an old man saying "it really was
much better before"?
.. Well I dunno; maybe ask him? ..
--
mvh, Lars Rune Nøstdal
http://lars.nostdal.org/
Lars Rune Nøstdal wrote:
> Because he doesn't want to look like an old man saying "it really was
> much better before"?
>
> .. Well I dunno; maybe ask him? ..
>
I am not as interested in what Joel says about Lisp, as I am about
Lisp. And I figure, that if he really was talking about Lisp then maybe
he would read the question here someday and respond.
"Alok" <···········@gmail.com> wrote in message
·····························@h48g2000cwc.googlegroups.com...
> Joel writes in a new article in Joel on Software about closures in
> layman programmer's language.
> http://www.joelonsoftware.com/items/2006/08/01.html Although he does
> not explicitly say that he is talking about Lisp, in fact he even
> delays mentioning Lisp until the end. All his example code is
> javascript, and the focus of his article is to drive people away from
> "Kingdom of Nouns" Java. But the article sounds very much like a
> tribute to Lisp.
>
> Why, does he not explicitly say so?
>
It's more about first class functions than closures.
He's talking about javascript which has first class functions (and i beleive
closures as well).
Lisp and javascript are not the only languages with such a concepts.
Nice article anyways =P
Sacha
Sacha wrote:
>
> He's talking about javascript which has first class functions (and i beleive
> closures as well).
> Lisp and javascript are not the only languages with such a concepts.
>
Perl, e.g.
Jurgen
Alok wrote:
> Why, does he not explicitly say so?
Tcl and C# both do what he's talking about also. And I'm guess that
Google's MapReduce (which is what he's talking about) isn't in LISP
either. More likely C, if I recall the paper right.
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.
According to wikipedia, Google's MapReduce is written in *shudder* C++,
with Python and *shudder* Java support through interfaces. See
http://en.wikipedia.org/wiki/MapReduce
I don't think he's talking about a specific language, per se. I think
he's just pointing out how useful functional programming techniques can
be. But, he's unfortunately using JavaScript to make the point,
presumably because it's easy for a *shudder* Java programmer to follow
the JavaScript code than it would be for them to follow the equivalent
Lisp code (or even Ruby code, though that would be somewhat less
foreign).
Darren New wrote:
> Alok wrote:
> > Why, does he not explicitly say so?
>
> Tcl and C# both do what he's talking about also. And I'm guess that
> Google's MapReduce (which is what he's talking about) isn't in LISP
> either. More likely C, if I recall the paper right.
>
> --
> Darren New / San Diego, CA, USA (PST)
> This octopus isn't tasty. Too many
> tentacles, not enough chops.
On Wed, 2 Aug 2006, Alok wrote:
> Joel writes in a new article in Joel on Software about closures in
> layman programmer's language.
> http://www.joelonsoftware.com/items/2006/08/01.html Although he does not
> explicitly say that he is talking about Lisp, in fact he even delays
> mentioning Lisp until the end. All his example code is javascript, and
> the focus of his article is to drive people away from "Kingdom of Nouns"
> Java. But the article sounds very much like a tribute to Lisp.
>
> Why, does he not explicitly say so?
Because it ain't.
It's a tribute to a programming style which Lisp supports, but then so do
a lot of other programming languages (such as Javascript).
Having said that, I'd say it's less of a tribute to functional languages
and more of an insult to Java, and other stupid languages that don't
believe functions are real.
More generally, it's a insult to all bondage-and-discipline languages
which are too stuck up on dogma to let you get stuff done in the easiest
way.
Naturally, I don't mean that the functional style is The Easiest Way, but
rather that the functional style is the easiest way for certain
programmers writing certain programs, and that a good programming language
aught to allow those programmers to write those programs in that way.
Incidentally, the argument applies just as well to languages which lack
non-functional features. Haskell, for example, is just fine until you want
to do I/O, whereupon you have to grok monads to continue. (I am reliably
informed that only an entity with Divine Rank +20 can actually understand
monads.)
I think what he mentions most is that the mainstream language gradually
learns from the advantage of functional language or lisp.
You can take a look at the Javascript 1.7
http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
on the other hand, lisp doesn't learn from other languages much. I
don't think common lisp is perfect...
On Thu, 2 Aug 2006, ············@gmail.com wrote:
> I think what he mentions most is that the mainstream language gradually
> learns from the advantage of functional language or lisp.
>
> You can take a look at the Javascript 1.7
> http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
>
> on the other hand, lisp doesn't learn from other languages much. I don't
> think common lisp is perfect...
I think this is, to some extent, because Lisp doesn't need to learn from
other languages. Lisp *programmers* can learn from other languages and
augment Lisp to fit their fancy.
For example, I've stolen from Ruby and use @ as a macro-character for slot
access:
(defvar *self*)
(set-macro-character ··@
#'(lambda (stream char)
`(slot-value *self* ',(read stream nil nil t))))
Using it is as simple as ensuring whatever parameter is to be considered
the topic is bound to *self*...
(defmethod my-method ((*self* my-class))
(print @foo))
Eventually, I mean to wrap this up in a Ruby-esque class syntax optimised
for single-dispatch. Not because I don't like multiple-dispatch, but just
because I find I most often use single-dispatch, and think I might benefit
from a compact syntax for it.
Also I'm vaguely thinking about using the Parrot virtual machine (partly
for fun, partly because, when it's finished, it'll give me a whole bunch
of libraries designed for dynamic languages essentially for free), which
has a single-dispatch object system.
And I can do all that without requiring changes to Common Lisp itself. (Or
somebody can, at least. Whether *I* can is something I'll find out later.
It'll fun to try, either way.)
On 9555 day of my life Nathan Baum wrote:
> (defvar *self*)
>
> (set-macro-character ··@
> #'(lambda (stream char)
> `(slot-value *self* ',(read stream nil nil t))))
>
> Using it is as simple as ensuring whatever parameter is to be
> considered the topic is bound to *self*...
>
> (defmethod my-method ((*self* my-class))
> (print @foo))
Just a sidenote question: do you really need (defvar *self*)?
--
Ivan Boldyrev
Is 'evening' a gerund?
On Sat, 5 Aug 2006, Ivan Boldyrev wrote:
> On 9555 day of my life Nathan Baum wrote:
>> (defvar *self*)
>>
>> (set-macro-character ··@
>> #'(lambda (stream char)
>> `(slot-value *self* ',(read stream nil nil t))))
>>
>> Using it is as simple as ensuring whatever parameter is to be
>> considered the topic is bound to *self*...
>>
>> (defmethod my-method ((*self* my-class))
>> (print @foo))
>
> Just a sidenote question: do you really need (defvar *self*)?
Not in the example I gave. However, I like defvar because:
1. It gives me a place to document the special behaviour of the variable
named *self*.
2. It makes *self* dynamic rather than lexical, which means I can refer to
slots in contexts which don't have a *self* variable.
I think (1) is always a win, although I'm of two minds about (2). Further
experimentation is required to come to a conclusion.
> --
> Ivan Boldyrev
>
> Is 'evening' a gerund?
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 9555 day of my life Nathan Baum wrote:
>> (defvar *self*)
>>
>> (set-macro-character ··@
>> #'(lambda (stream char)
>> `(slot-value *self* ',(read stream nil nil t))))
>>
>> Using it is as simple as ensuring whatever parameter is to be
>> considered the topic is bound to *self*...
>>
>> (defmethod my-method ((*self* my-class))
>> (print @foo))
>
> Just a sidenote question: do you really need (defvar *self*)?
Why don't you ask your favorite REPL?
SIDESHOW-MEL[5]> (set-macro-character
··@
(lambda (stream char)
`(slot-value self ',(read stream nil nil t))))
T
SIDESHOW-MEL[6]> ·@foo
(SLOT-VALUE SELF 'FOO)
SIDESHOW-MEL[7]> (defclass my-class () ((foo :initarg :foo)))
#1=#<STANDARD-CLASS MY-CLASS>
SIDESHOW-MEL[8]> (defmethod my-method ((self my-class))
(print @foo))
#1=#<STANDARD-METHOD (#2=#<STANDARD-CLASS MY-CLASS>)>
SIDESHOW-MEL[9]> (my-method (make-instance 'my-class :foo 'what-about-bob?))
WHAT-ABOUT-BOB?
WHAT-ABOUT-BOB?
SIDESHOW-MEL[10]>
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
············@gmail.com wrote:
> I think what he mentions most is that the mainstream language gradually
> learns from the advantage of functional language or lisp.
>
> You can take a look at the Javascript 1.7
> http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
>
> on the other hand, lisp doesn't learn from other languages much. I
> don't think common lisp is perfect...
Can you mention a few salient "language features" where common lisp
needs to change to easily do things that other languages, can do?
Also, from Nathan's response and from what I have read elsewhere, it is
possible and easy to extend Lisp programs to accommodate functionality
that other languages can be used to express.
Alok
Alok wrote:
> ············@gmail.com wrote:
> > I think what he mentions most is that the mainstream language gradually
> > learns from the advantage of functional language or lisp.
> >
> > You can take a look at the Javascript 1.7
> > http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
> >
> > on the other hand, lisp doesn't learn from other languages much. I
> > don't think common lisp is perfect...
>
> Can you mention a few salient "language features" where common lisp
> needs to change to easily do things that other languages, can do?
>
> Also, from Nathan's response and from what I have read elsewhere, it is
> possible and easy to extend Lisp programs to accommodate functionality
> that other languages can be used to express.
>
> Alok
I don't think it is about each programmer learning lisp his own way. I
think it is about common knowledge.
Common Lisp standard has not been updated to contain new concept found
by others language.
For example:
* collection class: no tree, hash-table that can customize 'equality
and 'key order. This has been in Java/C++ for years. Almost every
programmer has use some kind of sorted collection so it should be
included.
* More use of generic function. we don't have generic LENGTH, EQUAL,
COMPARE, LOOP, FOR-EACH.
* Real case sensitive, case sensitivity in Common Lisp is confusing,
you can write 'aaa, 'AAA, 'aAaA 'AaaA and they are all the same symbol
with name "AAAA". To most programmer, that is not what case sensitivity
means. Requiring "|aaaa|" for escaping is not easy to get.
* Convention based naming, may be this one is just my opinion, but many
language has started to make naming convention result in semantic, for
example in Ruby/Haskell, any variable starting with a Capital letter is
a constant. In Ruby any variable prefixing with ·@" is an instance
variable. If we could force, or at least communicate out intention with
a compiler, that any function ending with "?" must be predicate
function, any variable surrounded by "*...*" must be special variable,
it could be nice. If you are going to follow the standard convention of
language, why not have your compiler know about it too?
* There is not yet a standard on socket or threading, if you think this
should not be in standard because it might not exist in the future,
look at pathname. Are you sure pathname will be able to map to File
System in the next 20 years? There is no guarantee either that we will
be using POSIX in the next 30 years, but the standard should not make
too ambitious goal about wanting to remains useful for hundred years by
sacrificing the work that needs to be done today.
If you think there is no need for such thing to be in a standard. Then
why a heck do we need FORMAT, MAPCAR, LOOP, keyword etc. in the
standard? Anyone can implement it, too.
The reason we put something in standard because it is frequently used,
and you want to build enough common ground between each implementation
and/or developer.
For example, imagine how hard would it be if someone ask in a news
groups and your answer cannot contains format, loop, map, assoc,
destructring-bind, etc. because it does not exist as a standard and the
de facto version has some variance in it between each implementation.
At least some de facto standard could emerge as a concensus by a
community that say "From now on, every Common Lisp implementation will
also ships with the following package: CONTAINER, SOCKET, ... and the
the interfaces for functions in those packages are ...". At least all
those open source project could start such movement. I believe there's
a different between a compatibility layer library in common-lisp.net
that works with all open source lisp implementations and package
interface that are the same and shipped with all open source lisp
implementation. Internally they could delegate the work of maintaining
to a common-lisp.net project.
From: Christopher C. Stacy
Subject: Re: Can Your Programming Language Do This?
Date:
Message-ID: <yzlac6klgj5.fsf@OSX663.local>
"Pisin Bootvong" <··········@gmail.com> writes:
> Common Lisp standard has not been updated to contain new
> concept found by others language.
These are not "new concepts".
> * collection class: no tree, hash-table that can customize 'equality
> and 'key order. This has been in Java/C++ for years.
Common Lisp is, mainly, a subset of an older Lisp dialect which had
those features (ca 1984). They didn't make it into the standard.
There are libraries you can use which will do those things.
> * More use of generic function. we don't have generic LENGTH, EQUAL,
> COMPARE, LOOP, FOR-EACH.
You are lumping several things together here which are not the same.
EQUAL, in particular, is not like those other operators, and should
not be a generic function. Some people advocated for removing it
from the language standard altogether. If you read the archives of
this newsgroup you can find extensive explanations and discussion of this.
> * Real case sensitive, case sensitivity in Common Lisp is confusing,
I find that mixed case is horribly confusing and leads to bugs.
You know, we had lowercase letters back then, too.
> If you think there is no need for such thing to be in a standard. Then
> why a heck do we need FORMAT, MAPCAR, LOOP, keyword etc. in the
> standard?
Some people argued for making those things libraries, but since the
point was to come up with a language that would not break all the
existing code people had written, it contains the functions that
everyone was already using.
> For example, imagine how hard would it be if someone ask in a news
> groups and your answer cannot contains format, loop, map, assoc,
> destructring-bind, etc. because it does not exist as a standard and the
> de facto version has some variance in it between each implementation.
Do you have a specific question?
Christopher C. Stacy wrote:
> "Pisin Bootvong" <··········@gmail.com> writes:
> > Common Lisp standard has not been updated to contain new
> > concept found by others language.
>
> These are not "new concepts".
>
Fine, my bad wording. They are not new, nevertheless, Common Lisp does
not include them.
> > * collection class: no tree, hash-table that can customize 'equality
> > and 'key order. This has been in Java/C++ for years.
>
> Common Lisp is, mainly, a subset of an older Lisp dialect which had
> those features (ca 1984). They didn't make it into the standard.
> There are libraries you can use which will do those things.
>
I don't care whether they made it into the standard or not, I asked
whether it *should* make it into the standard.
There are library for anything, the point is why should not it be in
standard library.
> > * More use of generic function. we don't have generic LENGTH, EQUAL,
> > COMPARE, LOOP, FOR-EACH.
>
> You are lumping several things together here which are not the same.
> EQUAL, in particular, is not like those other operators, and should
> not be a generic function. Some people advocated for removing it
> from the language standard altogether. If you read the archives of
> this newsgroup you can find extensive explanations and discussion of this.
>
What about LENGTH, COMPARE, generic LOOP?
By the way, other widely used language today, be it mainstream like
Java/C# or dynamic like Ruby/Python works just fine with equal being
define in the language. EQUAL may not be mathematically well defined,
but I see it practical based on experience in any other programming
language. What property of Common Lisp makes EQUAL less useful than
that implemented in other language?
> > * Real case sensitive, case sensitivity in Common Lisp is confusing,
>
> I find that mixed case is horribly confusing and leads to bugs.
> You know, we had lowercase letters back then, too.
>
The thing is Common Lisp is actually case sensitive, but the reader is
case insensitive unless you escaped your symbol !!!
(eq 'foo 'FOO) ==> t
(find-symbol "FOO") ==> 'foo
(find-symbol "foo") ==> nil
(string= "FOO" (string 'FOO)) ==> t
(string= "FOO" (string 'foo)) ==> t
(string= "foo" (string 'foo)) ==> nil
It's the principal of least surprise, if a symbol could be referered to
as either 'foo or 'FOO then why can't I find a symbol with either "foo"
or "FOO"?
It is ok if you are either entirely case sensitive or entirely case
insensitive, but Common Lisp is half case insensitive and half case
sensitive which is even more confusing.
> > If you think there is no need for such thing to be in a standard. Then
> > why a heck do we need FORMAT, MAPCAR, LOOP, keyword etc. in the
> > standard?
>
> Some people argued for making those things libraries, but since the
> point was to come up with a language that would not break all the
> existing code people had written, it contains the functions that
> everyone was already using.
>
Everybody was also using CLOS and condition system and loop macro? Well
I really don't know and I would not be surprise if the answer is yes.
See there is a different purpose.You were saying that Common Lisp was
design to not break existing code, which is fine, but if we design
something just for backward compatibility and exclude something of best
practice guide, then I think that's what stale Common Lisp.
I agree that it is acceptable for what Common Lisp standard was aimed
for, to get one single dialect. But to be able to move forward, I think
we have to think about what is the concept that should be included in
order to faciliate best pratice, not just what should be included
because that was all we used to do.
> > For example, imagine how hard would it be if someone ask in a news
> > groups and your answer cannot contains format, loop, map, assoc,
> > destructring-bind, etc. because it does not exist as a standard and the
> > de facto version has some variance in it between each implementation.
>
> Do you have a specific question?
Given list of student name, their score and a grading crieteria, find
average score of the class and also each person's grade in tabular
format, sorted by person's name.
By the way, no REDUCE, COND, ASSOC, DO-XXX. Be honest and use your own
judgement on what could be trivially implemented as a pure Common Lisp
library, those are not included in these imagined standard (STRING= and
STRING COMPARE is probably not in the standard).
"Pisin Bootvong" <··········@gmail.com> writes:
> The thing is Common Lisp is actually case sensitive, but the reader is
> case insensitive unless you escaped your symbol !!!
>
> (eq 'foo 'FOO) ==> t
> (find-symbol "FOO") ==> 'foo
> (find-symbol "foo") ==> nil
> (string= "FOO" (string 'FOO)) ==> t
> (string= "FOO" (string 'foo)) ==> t
> (string= "foo" (string 'foo)) ==> nil
>
> It's the principal of least surprise, if a symbol could be referered to
> as either 'foo or 'FOO then why can't I find a symbol with either "foo"
> or "FOO"?
Because you're being silly?
(eq 'foo 'FOO) ==> T
(find-symbol "FOO") ==> FOO
(find-symbol "foo") ==> NIL
(string-equal "FOO" (string 'FOO)) ==> T
(string-equal "FOO" (string 'foo)) ==> T
(string-equal "foo" (string 'foo)) ==> T
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
Pisin Bootvong wrote:
> > Do you have a specific question?
>
> Given list of student name, their score and a grading crieteria, find
> average score of the class and also each person's grade in tabular
> format, sorted by person's name.
>
> By the way, no REDUCE, COND, ASSOC, DO-XXX. Be honest and use your own
> judgement on what could be trivially implemented as a pure Common Lisp
> library, those are not included in these imagined standard (STRING= and
> STRING COMPARE is probably not in the standard).
These are things that should be stored in a relational database, and
that should be solved through a SQL query.
I wouldn't do this in Perl or Python, because I would use mySQL or
postgreSQL, I might need to do that in COBOL, but every COBOL should be
able to use indexed-sequential files, which store these results
externally.
Jurgen
Pisin Bootvong wrote:
> Alok wrote:
> > ············@gmail.com wrote:
> > > I think what he mentions most is that the mainstream language gradually
> > > learns from the advantage of functional language or lisp.
> > >
> > > You can take a look at the Javascript 1.7
> > > http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
> > >
> > > on the other hand, lisp doesn't learn from other languages much. I
> > > don't think common lisp is perfect...
> >
> > Can you mention a few salient "language features" where common lisp
> > needs to change to easily do things that other languages, can do?
> >
> > Also, from Nathan's response and from what I have read elsewhere, it is
> > possible and easy to extend Lisp programs to accommodate functionality
> > that other languages can be used to express.
> >
> > Alok
>
> I don't think it is about each programmer learning lisp his own way. I
> think it is about common knowledge.
>
> Common Lisp standard has not been updated to contain new concept found
> by others language.
Mostly it does not need to. You can update Common Lisp yourself.
Common Lisp is a programmable programming language.
You need a new feature? Add it.
> For example:
>
> * collection class: no tree, hash-table that can customize 'equality
> and 'key order. This has been in Java/C++ for years. Almost every
> programmer has use some kind of sorted collection so it should be
> included.
Publish your version or use a version that has been published.
> * More use of generic function. we don't have generic LENGTH, EQUAL,
> COMPARE, LOOP, FOR-EACH.
I wouldn't like to see Generic Functions used for the 'low-level'
functions.
LOOP. There are user-extensible LOOP implementations.
I would remove LOOP from the language and replace it with simpler
constructs or better designed constructs (ITERATE).
> * Real case sensitive, case sensitivity in Common Lisp is confusing,
> you can write 'aaa, 'AAA, 'aAaA 'AaaA and they are all the same symbol
> with name "AAAA". To most programmer, that is not what case sensitivity
> means. Requiring "|aaaa|" for escaping is not easy to get.
You write |symbol| and not "|symbol|".
Most programming languages don't have symbols like Lisp, so their
naming
mechanisms are of not much value to understand Lisp symbols anyway.
This is a place where programmers new to Lisp actively need to learn
something new.
> * Convention based naming, may be this one is just my opinion, but many
> language has started to make naming convention result in semantic, for
> example in Ruby/Haskell, any variable starting with a Capital letter is
> a constant. In Ruby any variable prefixing with ·@" is an instance
> variable. If we could force, or at least communicate out intention with
> a compiler, that any function ending with "?" must be predicate
> function, any variable surrounded by "*...*" must be special variable,
> it could be nice. If you are going to follow the standard convention of
> language, why not have your compiler know about it too?
Because it would limit you in naming. Common Lisp does not limit you.
Especially you can embed different languages with different
naming standards in Lisp easily.
> * There is not yet a standard on socket or threading,
Is there a useful standard that applies over Windows, Unix, ...
for those anyway? If you can come up with a good proposal
(not just some of the average quality we have already)
that might be helpful.
> if you think this
> should not be in standard because it might not exist in the future,
> look at pathname. Are you sure pathname will be able to map to File
> System in the next 20 years? There is no guarantee either that we will
> be using POSIX in the next 30 years, but the standard should not make
> too ambitious goal about wanting to remains useful for hundred years by
> sacrificing the work that needs to be done today.
Pathnames in Common Lisp are just a hack.
> If you think there is no need for such thing to be in a standard. Then
> why a heck do we need FORMAT, MAPCAR, LOOP, keyword etc. in the
> standard? Anyone can implement it, too.
These were popular Lisp functionality, so it got included.
> The reason we put something in standard because it is frequently used,
> and you want to build enough common ground between each implementation
> and/or developer.
There are many more reasons and restrictions on what to put
in a standard. See also the goals that people wanted to achieve
with Common Lisp and see also the interests of the various
involved groups (users, implementors, vendors, developers, ...).
> For example, imagine how hard would it be if someone ask in a news
> groups and your answer cannot contains format, loop, map, assoc,
> destructring-bind, etc. because it does not exist as a standard and the
> de facto version has some variance in it between each implementation.
Yes, so we have some version of these functionalities. They may
not show the best design, but the best we got standardized.
> At least some de facto standard could emerge as a concensus by a
> community that say "From now on, every Common Lisp implementation will
> also ships with the following package: CONTAINER, SOCKET, ... and the
> the interfaces for functions in those packages are ...". At least all
> those open source project could start such movement. I believe there's
> a different between a compatibility layer library in common-lisp.net
> that works with all open source lisp implementations and package
> interface that are the same and shipped with all open source lisp
> implementation. Internally they could delegate the work of maintaining
> to a common-lisp.net project.
So, you volunteered?
······@corporate-world.lisp.de wrote:
> Pisin Bootvong wrote:
> > Alok wrote:
> > > ············@gmail.com wrote:
> > > > I think what he mentions most is that the mainstream language gradually
> > > > learns from the advantage of functional language or lisp.
> > > >
> > > > You can take a look at the Javascript 1.7
> > > > http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
> > > >
> > > > on the other hand, lisp doesn't learn from other languages much. I
> > > > don't think common lisp is perfect...
> > >
> > > Can you mention a few salient "language features" where common lisp
> > > needs to change to easily do things that other languages, can do?
> > >
> > > Also, from Nathan's response and from what I have read elsewhere, it is
> > > possible and easy to extend Lisp programs to accommodate functionality
> > > that other languages can be used to express.
> > >
> > > Alok
> >
> > I don't think it is about each programmer learning lisp his own way. I
> > think it is about common knowledge.
> >
> > Common Lisp standard has not been updated to contain new concept found
> > by others language.
>
> Mostly it does not need to. You can update Common Lisp yourself.
> Common Lisp is a programmable programming language.
> You need a new feature? Add it.
>
I userstand that it does not need to, nothing it ever need to be done
in this world. Common Lisp was not even NEEDED to standardize -- Every
dialect of Lisp at that time coujld have just grow their own lisp to
the function they want. Nobody was going to die if Common Lisp were not
standardized, change, or even exist. So it is never needed to do
anything.
Why don't we use Scheme, it is smaller, more clean, and what it doesn't
have you can still grow it, correct? Why do we need everyone to grow
their own language if thay are going to grow the same feature over and
over.
> > For example:
> >
> > * collection class: no tree, hash-table that can customize 'equality
> > and 'key order. This has been in Java/C++ for years. Almost every
> > programmer has use some kind of sorted collection so it should be
> > included.
>
> Publish your version or use a version that has been published.
>
Please, I'm talking about common knowledge. Common feature is one of
the purpose of standardization. One college could teach map/reduce, and
another could call it foo-bar, with a little variance in constraint and
alogrithm, and another college can call it bar-foo with some little
changes. But what's the point?
I could use my own version of collection, just like you use your, and
newgrads from college used their, but what's the point in having to
understand each other's variance in this structure when we could have
communicate on more higher level.
> > * More use of generic function. we don't have generic LENGTH, EQUAL,
> > COMPARE, LOOP, FOR-EACH.
>
> I wouldn't like to see Generic Functions used for the 'low-level'
> functions.
>
LENGTH/SIZE is low-level? Any collection has size. If you are talking
about performance, then shouldn't another specific function or
implementation dependent?
For example, it could be that SIZE is the generic function that returns
size of a collection. And if you want performance you could use a
simple function for each case, i.e, HASH-TABLE-SIZE. What do we lose in
having generic SIZE? It delivers the same clarity, and you can still
fallback to performance AFTER you profile your application.
> LOOP. There are user-extensible LOOP implementations.
> I would remove LOOP from the language and replace it with simpler
> constructs or better designed constructs (ITERATE).
>
My bad wording, I meant generic looping construct. You don't need LOOP,
DOLIST, DOTIMES. to loop over different kind of collection. Most modern
language I know use generic iteration protocol for you can call
(for-each x
(lambda (...) ))
With out having to know whether x is a list, hash-table, range,
package, or only limited to standard class.
If generic were more utilized, many macro would not need to exist.
why would you want to have both LOOP... OVER and LOOP ACROSS. keyword
if both container support a generic function to iterate.
For more example, why in the world do we need all those WITH-XXX macro
for resource clean up. C# capture this concept into their type system
with IDisposable interface. Every class that need to be clean up after
some scope implements IDisposable interface.
This interface has a single method "cleanUp" which is usually override
to do meaningful clean up for each resource. And C# provide a construct
that automatically clean the resource after the scope is over.
This could be traivially implemented in Common Lisp to look like.
(with-resource ((file (make-file-input-stream "...")
(socket (make-socket "...."))
(... use file and socket))
;; it gets clean up at the end.
No need for hundreds copy of WITH-XXX. And you can teah this concept
once to every Common Lisp programmer.
Macro should be used when you absolutely need to, polymophism combine
with macro reduce the need to write unneccessary macro.
> > * Real case sensitive, case sensitivity in Common Lisp is confusing,
> > you can write 'aaa, 'AAA, 'aAaA 'AaaA and they are all the same symbol
> > with name "AAAA". To most programmer, that is not what case sensitivity
> > means. Requiring "|aaaa|" for escaping is not easy to get.
>
> You write |symbol| and not "|symbol|".
>
I knew, I quoted the code.
> Most programming languages don't have symbols like Lisp, so their
> naming
> mechanisms are of not much value to understand Lisp symbols anyway.
Why is it needed to be difference? what gain do you get from being
semi-case-sensitive?
> This is a place where programmers new to Lisp actively need to learn
> something new.
>
> > * Convention based naming, may be this one is just my opinion, but many
> > language has started to make naming convention result in semantic, for
> > example in Ruby/Haskell, any variable starting with a Capital letter is
> > a constant. In Ruby any variable prefixing with ·@" is an instance
> > variable. If we could force, or at least communicate out intention with
> > a compiler, that any function ending with "?" must be predicate
> > function, any variable surrounded by "*...*" must be special variable,
> > it could be nice. If you are going to follow the standard convention of
> > language, why not have your compiler know about it too?
>
> Because it would limit you in naming. Common Lisp does not limit you.
> Especially you can embed different languages with different
> naming standards in Lisp easily.
>
Fine with that. But ability for compiler to suggest in most case (like
what Lint does) still seems desirable in most case.
> > * There is not yet a standard on socket or threading,
>
> Is there a useful standard that applies over Windows, Unix, ...
> for those anyway? If you can come up with a good proposal
> (not just some of the average quality we have already)
> that might be helpful.
>
Every scripting language I know of use same code to at least send
TCP/IP and UDP package on both linux and Windows. I can write Java to
open TCP/IP(UDP) socket on both Windows/Linux with same code.
What's wrong with those average quality proposal?
> > if you think this
> > should not be in standard because it might not exist in the future,
> > look at pathname. Are you sure pathname will be able to map to File
> > System in the next 20 years? There is no guarantee either that we will
> > be using POSIX in the next 30 years, but the standard should not make
> > too ambitious goal about wanting to remains useful for hundred years by
> > sacrificing the work that needs to be done today.
>
> Pathnames in Common Lisp are just a hack.
>
Why was a hack getting put in standard?
And there is no need to fix a hack?
> > If you think there is no need for such thing to be in a standard. Then
> > why a heck do we need FORMAT, MAPCAR, LOOP, keyword etc. in the
> > standard? Anyone can implement it, too.
>
> These were popular Lisp functionality, so it got included.
>
And Socket and FFI is now popular AND essential in almost every
language.
> > The reason we put something in standard because it is frequently used,
> > and you want to build enough common ground between each implementation
> > and/or developer.
>
> There are many more reasons and restrictions on what to put
> in a standard. See also the goals that people wanted to achieve
> with Common Lisp and see also the interests of the various
> involved groups (users, implementors, vendors, developers, ...).
>
> > For example, imagine how hard would it be if someone ask in a news
> > groups and your answer cannot contains format, loop, map, assoc,
> > destructring-bind, etc. because it does not exist as a standard and the
> > de facto version has some variance in it between each implementation.
>
> Yes, so we have some version of these functionalities. They may
> not show the best design, but the best we got standardized.
>
Exactly my point, why not include socket, threading, ffi, in future
standard, they may be variance, but at least we got one standardize.
> > At least some de facto standard could emerge as a concensus by a
> > community that say "From now on, every Common Lisp implementation will
> > also ships with the following package: CONTAINER, SOCKET, ... and the
> > the interfaces for functions in those packages are ...". At least all
> > those open source project could start such movement. I believe there's
> > a different between a compatibility layer library in common-lisp.net
> > that works with all open source lisp implementations and package
> > interface that are the same and shipped with all open source lisp
> > implementation. Internally they could delegate the work of maintaining
> > to a common-lisp.net project.
>
> So, you volunteered?
To make a concensus of between each implementation you would need those
project to talk to each other, not to me. If I start yet another CLRFI
web site to day, are you going to listen to me? You would need groups
of creditable people in the community to make it count.
--------------
Language is a tool, it is cool that your tool can grow to fit new
requirement, but I would rather want the tool that can grow PLUS it
comes with some part ALREADY grown.
From: Holger Schauer
Subject: Re: Can Your Programming Language Do This?
Date:
Message-ID: <yxzhd0nmk74.fsf@gmx.de>
On 4722 September 1993, ······@corporate-world.lisp.de wrote:
>> Common Lisp standard has not been updated to contain new concept found
>> by others language.
> Mostly it does not need to. You can update Common Lisp yourself.
> Common Lisp is a programmable programming language.
> You need a new feature? Add it.
I think this argument is not a good one at all, at least if you
consider that CLers have routinely pointed out that one of the major
gains of the large CL standard over the smaller Scheme standard was
that the most commonly used functionality does not need to be
implemented times and times again and incompatible to each other.
>> it could be nice. If you are going to follow the standard convention of
>> language, why not have your compiler know about it too?
> Because it would limit you in naming. Common Lisp does not limit you.
> Especially you can embed different languages with different
> naming standards in Lisp easily.
So what? I really don't see the problem here. I find the idea of
warning wrt. naming conventions quite appealing. That one might want
user-level customizability of what to warn about seems like an
additional level of complexity but not impossible to me.
> [LOOP] [...]
> Pathnames in Common Lisp are just a hack.
I think some of the functionality of CL could be removed from some
"kernel" standard and moved to some "standard library" part. Note that
not having some standard (libraries) for some task implies not having
standard solutions for some tasks that *are* standard problems (like
interfacing to C-code, database access etc.). There has been much
debate on cll on the question if libraries do need to be standarized
or not, with somebody (Kent I think) pointing out that maybe de facto
standards by popularity might be all there needs to be. But ...
> There are many more reasons and restrictions on what to put
> in a standard. See also the goals that people wanted to achieve
> with Common Lisp and see also the interests of the various
> involved groups (users, implementors, vendors, developers, ...).
>> For example, imagine how hard would it be if someone ask in a news
>> groups and your answer cannot contains format, loop, map, assoc,
>> destructring-bind, etc. because it does not exist as a standard and the
>> de facto version has some variance in it between each implementation.
> Yes, so we have some version of these functionalities. They may
> not show the best design, but the best we got standardized.
I wouldn't take that lightly as it implies that a quite large group of
people actually *did* compromise on something that both seemed
worthwile and possible to everybody in this large group.[1] This is
quite a different situation from the one in which everybody uses one
particular library because its the only functioning *implemented*
solution around. I.e., having one popular de facto library around does
not imply it is really the "best" (on whatever matrix) for the task at
hand.
But perhaps I'm just to rash and should rather wait another five
years. CL has gone quite a bit of way in the last five years and it
doesn't seem to have stopped recently.
Holger
Footnotes:
[1] Perhaps it's just my impression from reading too much cll, but
for some of the more popular libraries on the net, I would grant the
label "wide-spread reception" only to CL-PPCRE. For CLSQL, I think
that there are too much quirks in its API (there is either to few or
too much functionality) and for FFI, well there are at least to
competing libraries. Not to mention the horrendous set of "solutions"
for web programming.
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Gut, da� es �ffentlich-rechtliche Software gibt, die nach 20.00 Uhr
keine Werbung mehr anzeigt."
-- Matthias Warkus in de.comp.os.unix.linux.misc
Holger Schauer wrote:
> On 4722 September 1993, ······@corporate-world.lisp.de wrote:
> >> Common Lisp standard has not been updated to contain new concept found
> >> by others language.
>
> > Mostly it does not need to. You can update Common Lisp yourself.
> > Common Lisp is a programmable programming language.
> > You need a new feature? Add it.
>
> I think this argument is not a good one at all, at least if you
> consider that CLers have routinely pointed out that one of the major
> gains of the large CL standard over the smaller Scheme standard was
> that the most commonly used functionality does not need to be
> implemented times and times again and incompatible to each other.
It allows you to experiment with language extensions easily. You
want a different CASE statement? Add one. No need to
wait for some guy controlling the language design.
> >> it could be nice. If you are going to follow the standard convention of
> >> language, why not have your compiler know about it too?
>
> > Because it would limit you in naming. Common Lisp does not limit you.
> > Especially you can embed different languages with different
> > naming standards in Lisp easily.
>
> So what? I really don't see the problem here. I find the idea of
> warning wrt. naming conventions quite appealing. That one might want
> user-level customizability of what to warn about seems like an
> additional level of complexity but not impossible to me.
I don't see much benefit in it. If you really want to do it, you can do
it now.
> > [LOOP] [...]
> > Pathnames in Common Lisp are just a hack.
>
> I think some of the functionality of CL could be removed from some
> "kernel" standard and moved to some "standard library" part. Note that
> not having some standard (libraries) for some task implies not having
> standard solutions for some tasks that *are* standard problems (like
> interfacing to C-code, database access etc.). There has been much
> debate on cll on the question if libraries do need to be standarized
> or not, with somebody (Kent I think) pointing out that maybe de facto
> standards by popularity might be all there needs to be. But ...
We can think about all kinds of changes to CL. But none will
happen soon. My advice: learn to live with what is there.
> > There are many more reasons and restrictions on what to put
> > in a standard. See also the goals that people wanted to achieve
> > with Common Lisp and see also the interests of the various
> > involved groups (users, implementors, vendors, developers, ...).
>
> >> For example, imagine how hard would it be if someone ask in a news
> >> groups and your answer cannot contains format, loop, map, assoc,
> >> destructring-bind, etc. because it does not exist as a standard and the
> >> de facto version has some variance in it between each implementation.
>
> > Yes, so we have some version of these functionalities. They may
> > not show the best design, but the best we got standardized.
>
> I wouldn't take that lightly as it implies that a quite large group of
> people actually *did* compromise on something that both seemed
> worthwile and possible to everybody in this large group.[1] This is
> quite a different situation from the one in which everybody uses one
> particular library because its the only functioning *implemented*
> solution around. I.e., having one popular de facto library around does
> not imply it is really the "best" (on whatever matrix) for the task at
> hand.
CL is a compromise. Even ugly. Each large language is a compromise.
I can live with compromises. I don't need the the best designs
for ALL langauge features/components right NOW. I'm happy if the sum
is good enough to do the job -> be able to write working and
maintainable
software.
>
> But perhaps I'm just to rash and should rather wait another five
> years. CL has gone quite a bit of way in the last five years and it
> doesn't seem to have stopped recently.
>
> Holger
>
>
> Footnotes:
> [1] Perhaps it's just my impression from reading too much cll, but
> for some of the more popular libraries on the net, I would grant the
> label "wide-spread reception" only to CL-PPCRE. For CLSQL, I think
> that there are too much quirks in its API (there is either to few or
> too much functionality) and for FFI, well there are at least to
> competing libraries. Not to mention the horrendous set of "solutions"
> for web programming.
>
>
> --
> --- http://www.coling.uni-freiburg.de/~schauer/ ---
> "Gut, daß es öffentlich-rechtliche Software gibt, die nach 20.00 Uhr
> keine Werbung mehr anzeigt."
> -- Matthias Warkus in de.comp.os.unix.linux.misc
From: Holger Schauer
Subject: Re: Can Your Programming Language Do This?
Date:
Message-ID: <yxzejvrm4ft.fsf@gmx.de>
On 4724 September 1993, ······@corporate-world.lisp.de wrote:
> Holger Schauer wrote:
[...]
> It allows you to experiment with language extensions easily. You
> want a different CASE statement? Add one. No need to
> wait for some guy controlling the language design.
That's beside the point. I'm not arguing against rolling your own
language extensions in general, I'm just arguing against applying one
particular useful CL feature as a killer argument against extensions
to the language standard in general.
> We can think about all kinds of changes to CL. But none will
> happen soon. My advice: learn to live with what is there.
I do (not the learning, but the living). I'm not whining about
missing features in CL. Yet I recognize that people are puzzled why
this and that is missing in the standard. Of course, past decisions
can be explained. The question is however, if there are not some
points which weren't decided upon because that particular feature just
wasn't or couldn't be discussed at the time or if some decisions made
would be revised today. Probably you're right that none of this will
happen soon, but I don't think that this insight should result in
disapproval of discussions of modifications to the standard.
> CL is a compromise. Even ugly. Each large language is a compromise.
> I can live with compromises. I don't need the the best designs
> for ALL langauge features/components right NOW. I'm happy if the sum
> is good enough to do the job -> be able to write working and
> maintainable software.
I am somehow hoping that some extensions to the standard would benefit
the community just like the advent of CL did, i.e. overcoming
some of the same observed problems in the previous situation. I.e.
providing one with a reliable set of interfaces (not necessarily
implementations) on which to base maintainable software.
Time for an example: say, I develop an application based on CLSQL
today. Two years from now, a new database might rule the market to
which I need to migrate, which also might happen to be supported by
the then current version of CLSQL. But today, nothing guarantees me
(like e.g. the pathname section of the standard does) that my
applications will work with that version of CLSQL due to *interface*
incompatibilites. Hey, with UCW, I am not even guaranteed that my
current application will compile tomorrow (and no, I haven't even
looked at Cells :-). I'm not particular happy with that situation,
although I admit that this is of course not a problem of the CL
standard (quite to the contrary, I happen to run into exactly that
problem on a much larger scale with ever changing versions of those
one-implementation-is-the-language-specification languages).
Now, I'm not really arguing that an SQL interface should be part of
the CL language standard. I am not even particular interested in what
way the standard could or should be extended. But I think that
standards in general are a good thing for software development and the
CL standard is, in my opinion, a success story. I am hence wondering
why every time when somebody issues a wish about the standard, all
grandpas of cll [1]just say "Hush, shy away, young boy". I'm not
convinced it wouldn't be worth it.
Holger
Footnotes:
[1] No offense intended.
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Gut, da� es �ffentlich-rechtliche Software gibt, die nach 20.00 Uhr
keine Werbung mehr anzeigt."
-- Matthias Warkus in de.comp.os.unix.linux.misc
Holger Schauer wrote:
> Now, I'm not really arguing that an SQL interface should be part of
> the CL language standard. I am not even particular interested in what
> way the standard could or should be extended. But I think that
> standards in general are a good thing for software development and the
> CL standard is, in my opinion, a success story. I am hence wondering
> why every time when somebody issues a wish about the standard, all
> grandpas of cll [1]just say "Hush, shy away, young boy". I'm not
> convinced it wouldn't be worth it.
No, I'm very convinced that REALLY WORKING on standardizing
more Lisp features would be worth it. But realistically I don't see
it happen any time soon. The CL standard was developed when there
was lots of money in the market (mostly from military and government)
and lots of experts working on CL. There is much less money in the CL
market, less interest of a single big customer (US military) and
most experts have moved on to newer hypes. The old standard (ANSI) is
mostly dead and one may not want to revive it (again IMHO) -> costs,
ownership, ... .
The only way IMHO to get some more stuff 'standardized' is something
like
the SRFI process. Unfortunately there seems to be little interest in
the CL
community to work on these proposals - the latest attempt got little
support.
See here: http://clrfi.alu.org/
So, again, I think it can be useful (if enough people from the various
Lisp
sub-communities were working on it) - but I would not hold my breath.
Instead, realistically I'm interested in ways to live with the
situation
of not getting things standardized and those standards supported by
vendors, by working on cross-platform layers for the code that I
need/have.
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> The only way IMHO to get some more stuff 'standardized' is something
> like the SRFI process. Unfortunately there seems to be little
> interest in the CL community to work on these proposals
My impression (add salt to taste) is that there is quite some
interest. Perhaps few people have the right combination of community
recognition, experience, resources, and confidence to create a
successful (de facto, layered, etc) standardization effort.
> the latest attempt got little support. See here: http://clrfi.alu.org/
My impression (again) is not that CLRFI didn't get any support, but
rather that the ALU realized that there was a risk that they could
become the target of lawsuits, so they decided to tone down their
effort.
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> Holger Schauer wrote:
> > On 4722 September 1993, ······@corporate-world.lisp.de wrote:
> > > Because it would limit you in naming. Common Lisp does not limit you.
> > > Especially you can embed different languages with different
> > > naming standards in Lisp easily.
> >
> > So what? I really don't see the problem here. I find the idea of
> > warning wrt. naming conventions quite appealing. That one might want
> > user-level customizability of what to warn about seems like an
> > additional level of complexity but not impossible to me.
>
> I don't see much benefit in it. If you really want to do it, you can do
> it now.
In general, I would find such a compiler unappealing, but there is one
case where SBCL warns you for being at odds with a naming convention,
and I find it very helpful on those occasions where I get it:
CL-USER> (lambda (*x*) *x*)
; in: LAMBDA NIL
; (LAMBDA (*X*) *X*)
; ==>
; #'(LAMBDA (*X*) *X*)
;
; caught STYLE-WARNING:
; using the lexical binding of the symbol *X*, not the
; dynamic binding, even though the symbol name follows the usual naming
; convention (names like *FOO*) for special variables
;
; compilation unit finished
; caught 1 STYLE-WARNING condition
#<FUNCTION (LAMBDA (*X*)) {3087D625}>
"Alok" <···········@gmail.com> writes:
> Joel writes in a new article in Joel on Software about closures in
> layman programmer's language.
> http://www.joelonsoftware.com/items/2006/08/01.html Although he does
> not explicitly say that he is talking about Lisp, in fact he even
> delays mentioning Lisp until the end. All his example code is
> javascript, and the focus of his article is to drive people away from
> "Kingdom of Nouns" Java. But the article sounds very much like a
> tribute to Lisp.
>
> Why, does he not explicitly say so?
Because when some people see the magical word: "lisp", or (parentheses
surrounding code), the shut out and stop reading/listening.
Just substitute or avoid the word, and use {} or <> instead of (), and
you may be able to convince them that what you're explaining them is
better than what they have. After all, (to them) it just looks like a
better C or XML. When they're hooked, you can tell them that it's
called Lisp and actually uses ().
In two word: pure psychology.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
From: Ken Tilton
Subject: Re: Can Your Programming Language Do This?
Date:
Message-ID: <sYgAg.7724$6g2.140@fe12.lga>
Alok wrote:
> Joel writes in a new article in Joel on Software about closures in
> layman programmer's language.
> http://www.joelonsoftware.com/items/2006/08/01.html Although he does
> not explicitly say that he is talking about Lisp, in fact he even
> delays mentioning Lisp until the end. All his example code is
> javascript, and the focus of his article is to drive people away from
> "Kingdom of Nouns" Java. But the article sounds very much like a
> tribute to Lisp.
>
> Why, does he not explicitly say so?
>
The hook must be fully set before one can pull in the fish.
hth, ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon