The discussion over at news.groups quickly lost me, but I was interested by your (Benjamin/dekuduplex) comment here:Quote from: "cormullion"[...] I had still been thinking about whether toQuote
continue with this RFC because of inconsistencies in statements by the
creator of newLISP in admitting whether a bug (now fixed) really was a
bug. When I proposed the first RFC, this issue had not yet existed.
Such inconsistencies can possibly change the value of the programming
language to USENET in my opinion. If the creator of a programming
language says that a bug is not really a bug, and then turns around
and fixes the "bug," is that creator trustworthy?
You seem to be saying here that you don't or didn't think there should be a comp.lang.lisp.newlisp group because Lutz is either untrustworthy or can sometimes change his mind? This I don't understand at all.
I'll think I'll stick to my cloisters...
While I applaud Lutz's fixing of the bug, it struck me as rather surprising that he
In the newLISP-GS Java front-end the bottom monitor is only a minimal terminal implementation in a Java Swing text area. Only designed for simple one-liners and not designed to be as comfortable as a shell window (which on Mac OS X and other Unix also does tab-expansion to built-in functions).Quote from: "Lutz"
When I
There must be a fatal flaw in this system, if you have to tag yourQuote from: "Pascal J. Bourguignon"
multiline expressions with an horror such as [cmd][/cmd].
The algorithms to read expressions, whatever the number of lines, have
been know and implemented in Lisp for 50 years. Perhaps you should
try a Lisp that includes the teachings of history?
This made me feel like an idiot, so I was just about to conclude that I should withdraw my RFD, when suddenly Lutz added a
The problem with [cmd][/cmd] tags in the newLISP-GS Java front-end has been fixed. Download a new guiserver.jar from:Quote from: "Lutz"http://www.newlisp.org/downloads/development/guiserver.jar"> http://www.newlisp.org/downloads/develo ... server.jar">http://www.newlisp.org/downloads/development/guiserver.jar
and install on Win32 as: $PROGRAMFILES/newlisp/guiserver.jar
or install on Mac OS X and other Unix as: /usr/share/newlisp/guiserver.jar
While I very much appreciate Lutz's fixing the bug, what bugged (pardon the pun) me was the fact that he implied that it wasn't a bug at first, and then as soon as I tried to come up with a satisfactory response to Bourguignon's claim that there "must be a fatal flaw in this system" on comp.lang.lisp, he claimed that it was in fact a "problem" (i.e., a "bug").
This made my intended position on comp.lang.lisp untenable, and forced me completely to rethink my response to Bourguignon's claim. It also made me feel very embarrassed in front of Bourguignon.
What was I to respond then to Bourguignon? These users are Lisp geeks who just love to make others look silly at the slightest logical inconsistency, but they also often have many insightful things to say, so I want to continue participating on comp.lang.lisp, but without putting myself in an awkward position vis–à–vis the other participants.
If I replied,
"Yes, you're right, it was a flaw in this system, and although Lutz first said that it wasn't a bug, he then changed his mind and fixed it."Quote from: "DekuDekuplex on comp.lang.lisp hypothetically"
then Bourguignon would probably have replied,
"Well, it's good that it was fixed, but why did he change his mind? Why don't you avoid a language where the designer first argues that a bug isn't a bug and then changes his mind and says that it is indeed a bug, and try a Lisp that includes the teachings of history?"Quote from: "Bourguignon on comp.lang.lisp hypothetically"
thus making my position very awkward.
On the other hand, if I replied,
"No, you're wrong, there never was any fatal flaw in this system in the first place, as Lutz has already explained, but the problem has been fixed."Quote from: "DekuDekuplex on comp.lang.lisp hypothetically"
then Bourguignon would probably have replied,
"Well, if there never was any flaw to begin with, then why was it fixed? Either there wasn't a bug, in which case nothing needed to have been fixed in the first place, or there was one, in which case there was a logical inconsistency involved. As I said, the algorithms to read expressions, whatever the number of lines, have been know and implemented in Lisp for 50 years. Why don't you avoid this kind of problem and try a Lisp that includes the teachings of history?"Quote from: "Bourguignon on comp.lang.lisp hypothetically"
thus again making my position very awkward.
Therefore, in order to avoid handing additional
In fact, as a sequel, something right now is happening in another
Here are some observations of both newLISP and Clojure, based uponQuote from: "Benjamin L. Russell in comp.lang.lisp"
features listed on their sites, together with some questions on
Clojure:
1. newLISP comes with a DrScheme-style GUI-based IDE complete with
definitions and interactions panels, whereas apparently Clojure does
not. Does Clojure have a superior editing environment?
2. Clojure does not have first-class continuations. Unfortunately, I
discovered recently that neither does newLISP. I wish to study
continuations in PLAI (seehttp://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/"> ),http://www.cs.brown.edu/~sk/Publication ... 007-04-26/">http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/
as well as to continue studying SICP (seehttp://mitpress.mit.edu/sicp/">http://mitpress.mit.edu/sicp/ ). Is this feasible using Clojure?
3. newLISP has ORO (One Reference Only) automatic memory management
(seehttp://www.newlisp.org/MemoryManagement.html">http://www.newlisp.org/MemoryManagement.html ), in which "Memory
is not marked or reference-counted. Instead, a decision whether to
delete a newly created memory object is made right after the memory
object is created." Does Clojure have a superior garbage collection
mechanism?
4. I wish to study tail call optimization in SICP. Since Clojure
"uses the Java calling conventions, it cannot, and does not, make
[...] tail call optimization guarantees" (seehttp://clojure.org/functional_programming">http://clojure.org/functional_programming , under "Recursive Looping").
I am not sure about newLISP in this regard (the newLISP Manual and
Reference (seehttp://www.newlisp.org/downloads/manual_frame.html">http://www.newlisp.org/downloads/manual_frame.html ))
does not discuss tail call optimization. Is there a way to study tail
call optimization, as discussed in SICP, using Clojure?
5. Since I live in Japan, where the dominant language is Japanese, I
wish to be able to use Japanese characters in my programs, thus
necessitating Unicode support. newLISP supports Unicode (see "newLISP
- Features" athttp://www.newlisp.org/index.cgi?Features">http://www.newlisp.org/index.cgi?Features , under
"International"). I could not find any references to Unicode support
for Clojure. Does Clojure support Unicode?
Sure enough, another comp.lang.lisp participant, this time Tamas K Papp,
On Thu, 26 Mar 2009 20:07:10 +0900, Benjamin L. Russell wrote:Quote from: "Tamas K Papp on comp.lang.lisp"
> There seems to be more discussion of Clojure than newLISP on USENET
> these days, even though both are minor Lisp dialects with similar goals,
Similar goals? The creators of Clojure constructed a decent* language,
the same cannot be said of newLisp.
(* I don't want to get into a CL vs Clojure debate here. Arguing
about the relative merits of vanilla and chocolate ice cream is
pointless when the third alternative is batshit).
[...]
> programmers. Alternatively, perhaps Clojure has certain advantages over
> newLISP that I am unaware of.
Eg closures? Lexical scope?
So Tamas K Papp was claiming that he because he thought that newLISP did not have closures or lexical scope, comparing CL and Clojure with newLISP was like comparing "vanilla and chocolate ice cream" with "batshit."
Apparently, one participant, Kazimir Majorinc, thought this to be too much, so he actually tried to
On Thu, 26 Mar 2009 20:24:48 +0100,Quote from: "Kazimir Majorinc on comp.lang.lisp"
namekuseijin <namekusei> wrote:
> newLisp is yet another scripting language with lots of wrappers around
> common programming APIs. Clojure is a full-fledged language and
> implementation, also benefiting from Java frameworks and tools.
> newLisp doesn't even have lexical scope, thus their list of features
> is more interested in showing immediate practical stuff, like IDEs and
> library-support, that will cater to pragmatic programmers but won't
> impress folks interested in new language design ideas. Besides, I
> don't like the authoritative tone in the choice of name.
I have to disagree with that. I started using Newlisp after I
used other Lisp dialects few years, mostly because of few
code=data related features not availiable in other languages:
* Unrestricted eval that works for local and global variables and
doesn't require addional running time.
(In almost all Lisp implementation, code containing eval is many
times (up to 1500+ times) slower than same code out of eval)
* Dynamic scope. Because of that, in Newlisp one can define
functions equally powerful as macros - for example, I defined
function IF - standard example why one need macros in some
Lisp dialects.
Newlisp supports lexical scope in the form of contexts.
* Newlisp macros are actually fexprs, i.e. fexprs are not expanded
during compile time, but evaluated during during runtime. Fexprs
are simpler, and slower in normal code, but faster if used inside
of eval (macroexpansion inside of eval is very slow).
Additionally, Newlisp macros are the first class citizens, so
one can use these as values, apply or map during runtime.
Macros can be anonymous.
* Functions and macros evaluate to their own definitions,
so one can not only use, apply and map functions (and macros)
during runtime, but he can also analyze and mutate functions
(and macros) during runtime.
These are not just any improvements, but improvements in
metaprogramming, code=data paradigm, and that paradigm is
specificity of Lisp. These features are not emphasized in
the introductory materials, but it is decision of the author
to present the language primarily as simple and practical,
suitable and interesting for wide number of programmers.
The majority of potential users are not primarily interested
in fexpr vs macros issue, but in practical side.
There are many other innovations, like FOOP - functional
object oriented programming, unification with occur check,
regular expressions, basic statistical functions ...
I agree that name is not the most fortunate, but it is not
that important. Generally, author of Newlisp is very helpful
person, and frequently accept requests for features.
Unfortunately, then he got
On Thu, 26 Mar 2009 22:54:57 +0100, Kazimir Majorinc wrote:Quote from: "Tamas K Papp on comp.lang.lisp"
> I have to disagree with that. I started using Newlisp after I used other
> Lisp dialects few years, mostly because of few code=data related
> features not availiable in other languages:
> * Unrestricted eval that works for local and global variables and
> doesn't require addional running time.
> (In almost all Lisp implementation, code containing eval is many
> times (up to 1500+ times) slower than same code out of eval)
That may be because newLisp is interpreted and everything must be slow
as hell. I doubt that eval is slower in modern CL implementations
compared to newLisp, it is just that compiled code is so much faster
than the latter.
Next time you need to go somewhere, just crawl on your belly. That
way you will not lose a lot of speed when you have to stop at a
traffic light.
> [ ... other similarly idiotic statements snipped ... ]
> These are not just any improvements, but improvements in
> metaprogramming, code=data paradigm, and that paradigm is specificity of
> Lisp. These features are not emphasized in the introductory materials,
Whenever you don't have a clue, just say the magic word "paradigm",
possibly multiple times. newLisp paradigmatically integrates the
code-data meta-paradigm paradigmatic sub-paradigm paradigm, etc.
> but it is decision of the author to present the language primarily as
> simple and practical, suitable and interesting for wide number of
> programmers. The majority of potential users are not primarily
> interested in fexpr vs macros issue, but in practical side.
The author(s) of newLisp obviously didn't have a clue about language
design, and could not implement a compiler, closures, and a zillion
other things. Trying to sell these as a "features" is rather weak.
I hope that you realize that your attempts to push newLisp are rather
pathetic.
Additionally, Raffael Cavallaro
On Mar 26, 7:48 am, Tamas K Papp <tkp> wrote:Quote from: "Raffael Cavallaro on comp.lang.lisp"
> (* I don't want to get into a CL vs Clojure debate here. Arguing
> about the relative merits of vanilla and chocolate ice cream is
> pointless when the third alternative is batshit).
You insensitive clod! batshit ^h^h^h^h newlisp is Benjamin's favorite
flavor!
Faced with many arguments arguing that newLISP wasn't worth a newsgroup, and no support from the newLISP Fan Club members in response, I then had to issue a disclaimer against Cavallaro's statement:
On Thu, 26 Mar 2009 10:34:57 -0700 (PDT), Raffael CavallaroQuote from: "Benjamin L. Russell on comp.lang.lisp"
<raffaelcavall> wrote:
>On Mar 26, 7:48?am, Tamas K Papp <tkp> wrote:
>> (* I don't want to get into a CL vs Clojure debate here. ?Arguing
>> about the relative merits of vanilla and chocolate ice cream is
>> pointless when the third alternative is batshit).
>You insensitive clod! batshit ^h^h^h^h newlisp is Benjamin's favorite
>flavor!
Whatever gave you that idea? I was trying to have a newLISP newsgroup
created initially because I had discovered a bug (now fixed) in its
evaluation of multi-line statements in its GUI REPL, and just wanted a
dialect-specific newsgroup where I could discuss the issue and have a
high probability of getting feedback specifically from newLISP users.
I hadn't wanted to try this newsgroup at first because this newsgroup
hadn't seemed frequented by newLISP users; most of the discussion
seemed to focus on Common Lisp. I also hadn't wanted to post that
topic on the newLISP Web board because I didn't like that kind of
interface and wanted to write using my newsreader.
Then it seemed that in order to have the newsgroup created, I needed
to promote discussion, which required promoting the topic, which
required promoting the language, so I wound up promoting what I could
about the language. Little did I realize what I was getting myself
into at first....
Of course, Tamas K Papp then
On Fri, 27 Mar 2009 16:25:41 +0900, Benjamin L. Russell wrote:Quote from: "Tamas K Papp on comp.lang.lisp"
> Then it seemed that in order to have the newsgroup created, I needed to
> promote discussion, which required promoting the topic, which required
> promoting the language, so I wound up promoting what I could about the
> language. Little did I realize what I was getting myself into at
> first....
Thanks for admitting that you are only trying to generate discussion
to have a newLisp ng created, not because you had something to
discuss. I have bookmarked this article, and will be happy to refer
to it when the issue of a newLisp ng is raised again (if ever).
I hope that you realize that all your attempts to generate gratuitous
"discussion" about newLisp will be recognized as an abuse of Usenet,
and your proposals to create a newLisp ng will be judged accordingly.
Well, maybe Papp thinks that he has won, but this is not the final straw. I have
On 27 Mar 2009 08:51:39 GMT, Tamas K Papp <tkp> wrote:Quote from: "Benjamin L. Russell on comp.lang.lisp"
>[...]
"Abuse of Usenet?" Riiight. When I posted a message to
news.groups.proposals urging creation of a comp.lang.lisp.newlisp
newsgroup, one respondent wrote back that "guiding the discussion" was
one of my "duties of a proponent," as follows:
> > > I also haven't checked the lisp newsgroup to know what sort
> > > of stumping/PR you've done there.
> > I haven't done much there lately.
> Maybe you don't understand the duties of a proponent. Follow the discussion
> on appropriate groups. Guide the discussion. Do supporting PR for the group.
> All during the RFD process. After the vote then look for at least one user on
> each of the major NSPs and get them to request the group be added. Be a
> user on at least one NSP and make the request yourself. Make sure the group
> gets some traffic in the first year by posting on topic at least monthly.
So by following the advice of one of the respondents on new.groups.proposals for "guiding the discussion" in fulfilling my "duties of a proponent," I was committing "an abuse of Usenet, and [my] proposals to create a newLisp ng will be judged accordingly."
Riiight. If I don't "guid[e] the discussion," then I get a private e-mail message from a member of news.groups.proposals accusing me of not "fulfilling my duties as a proponent," and if I do, then I get a response on this newsgroup that that constitutes "an abuse of Usenet."
I have bookmarked this article, and will be happy to refer to it if any issue of your ever creating any newsgroup is raised (if ever).
-- Benjamin L. Russell