An early release of NiCLOS is now available at http://www.niclos.com
It would be most helpful to get some feedback from the Lisp
Community on the system before it gets released to non-Lisp users.
The documentation continues to be written.
The NiCORE persistent object system is essentially a subset of CLOS,
and may be of interest for non-web applications.
It can be used independent of the web server as it is
distributed/packaged in the engineering release.
-Kelly Murray ···@niclos.com
What is NiCLOS?
NiCLOS is a new platform for quickly developing, deploying, and
evolving powerful and scalable web applications. Using a single
high-level dynamic persistent object language, the full range of
server-based web applications can be
developed and evolved quickly and easily.
The key advantage of NiCLOS is the dynamic persistent object system,
which
supports major changes in the application object structure after the
application has
been deployed.
NiCLOS has three tightly integrated components, the Charlotte web
server, the
SilkScript object language, and the NiCORE object database.
Kelly Murray <···@IntelliMarket.Com> writes:
> An early release of NiCLOS is now available at http://www.niclos.com
> It would be most helpful to get some feedback from the Lisp
> Community on the system before it gets released to non-Lisp users.
> The documentation continues to be written.
Looks intriguing... The only comment I have so far is that the calendar did
not work right for me when I clicked on a date.
Sunil
From: Fernando Mato Mira
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <372963C5.853515AE@iname.com>
Kelly Murray wrote:
> An early release of NiCLOS is now available at http://www.niclos.com
> It would be most helpful to get some feedback from the Lisp
> Community on the system before it gets released to non-Lisp users.
> The documentation continues to be written.
NOOO! This has the potential to become very popular, and
then we will be stuck developing NiCLOS-compatible stuff
with all those `elseif', `then', `do', `=', etc.
As I think you'll go anyway with this, you should put a big sign saying
`THIS IS NOT LISP', otherwise we'll have to deal with more people saying
that Lisp has a confusing (and now verbose) syntax.
Regards,
Fernando Mato Mira <········@iname.com> writes:
> As I think you'll go anyway with this, you should put a big sign saying
> `THIS IS NOT LISP', otherwise we'll have to deal with more people saying
> that Lisp has a confusing (and now verbose) syntax.
Hmmm, I haven't seen "Lisp" mentioned on the site anywhere. In fact I
rather think that KEM has learned the lesson of not calling things
Lisp, yet still providing Lisp in disguise. See Dylan, or IIRC
Franz's adverts which called the technology Dynamic Objects, etc.
If we aren't going to go around accusing Dylan of confusing people
about the "true nature" of Lisp, we shouldn't be doing this with
NiCLOS either, IMHO.
(Not that I particularly like NiCLOS's syntax, although I find it
easier on the mind than e.g. Dylan's new syntax. And I still think
that those who blame Lisp's syntax for it's non-acceptance are
essentially misguided, in that e.g. AutoLisp is probably more widely
used by non-hardcore-lispers than many other dialects, yet still has
the "horrible" Lisp syntax, and it even has a lot of other defects.)
BTW: The technology itself seems fairly interesting, and nice work.
And since the author of CL-HTTP seemingly isn't interested in wider
distribution of his work, maybe Lisp can make further impact in a sexy
application area...
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Fernando Mato Mira
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <372D5EAB.BA93E097@iname.com>
"Pierre R. Mai" wrote:
> Fernando Mato Mira <········@iname.com> writes:
>
> > As I think you'll go anyway with this, you should put a big sign saying
> > `THIS IS NOT LISP', otherwise we'll have to deal with more people saying
> > that Lisp has a confusing (and now verbose) syntax.
>
> Hmmm, I haven't seen "Lisp" mentioned on the site anywhere. In fact I
> rather think that KEM has learned the lesson of not calling things
> Lisp, yet still providing Lisp in disguise. See Dylan, or IIRC
> Franz's adverts which called the technology Dynamic Objects, etc.
I know he never refers to it at Lisp. The problem is people who have
some vague notion of what Lisp looks like and will start spreading
misinformation.
Dylan is OK. The dropped syntax was indeed Lisp, and the one for dummies does
not look like Lisp at all.
Franz might call ACL whatever they want, but when it comes to the syntax, it's
for real.
In article <·················@iname.com>,
Fernando Mato Mira <········@iname.com> wrote:
>
>
> "Pierre R. Mai" wrote:
>
> > Fernando Mato Mira <········@iname.com> writes:
> >
> > > As I think you'll go anyway with this, you should put a big sign saying
> > > `THIS IS NOT LISP', otherwise we'll have to deal with more people saying
> > > that Lisp has a confusing (and now verbose) syntax.
> >
> > Hmmm, I haven't seen "Lisp" mentioned on the site anywhere. In fact I
> > rather think that KEM has learned the lesson of not calling things
> > Lisp, yet still providing Lisp in disguise. See Dylan, or IIRC
> > Franz's adverts which called the technology Dynamic Objects, etc.
>
> I know he never refers to it at Lisp. The problem is people who have
> some vague notion of what Lisp looks like and will start spreading
> misinformation.
(...)
I guess it needs to be repeated once again that Lisp is not a language,
it is a family of languages. Common Lisp is one of those (in fact,
it has three varieties now: 1st and 2nd edition CL, and ANSI CL).
Others include (in no particular order) Scheme, Emacs Lisp, Autolisp;
Lisp 1.5, Maclisp, Interlisp, Zetalisp, *Lisp, Franz Lisp, Portable Lisp,
etc.
--
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <············@nnrp1.dejanews.com>,
Vassil Nikolov <········@poboxes.com> wrote:
>I guess it needs to be repeated once again that Lisp is not a language,
>it is a family of languages. Common Lisp is one of those (in fact,
>it has three varieties now: 1st and 2nd edition CL, and ANSI CL).
>Others include (in no particular order) Scheme, Emacs Lisp, Autolisp;
>Lisp 1.5, Maclisp, Interlisp, Zetalisp, *Lisp, Franz Lisp, Portable Lisp,
>etc.
Most of the non-Common Lisps still exist for a simple historical reason:
they predated Common Lisp, and there's lots of code that depends on them,
and/or there are programming communities that have grown around them.
However, it seems like a bad idea to invent a new dialect of Lisp at this
point. Why not embed one of the existing, popular dialects rather than
needlessly branching off?
The only other dialect of Lisp that has been invented in recent years was
ISLisp. It was created to solve a problem of international politics, not
for any good technical reason.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
From: Kent M Pitman
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <sfw7lqp974r.fsf@world.std.com>
Barry Margolin <······@bbnplanet.com> writes:
> The only other dialect of Lisp that has been invented in recent years was
> ISLisp. It was created to solve a problem of international politics, not
> for any good technical reason.
Some might dispute this entirely. Others might say you were missing
an "m" in the last line here.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Barry Margolin <······@bbnplanet.com> writes:
>
>> The only other dialect of Lisp that has been invented in recent years was
>> ISLisp. It was created to solve a problem of international politics, not
>> for any good technical reason.
>
>Some might dispute this entirely. Others might say you were missing
>an "m" in the last line here.
I'm sure they would. I admit that my comment was probably a bit extreme,
for rhetorical purposes.
I still feel that new dialects should not be created on a whim. Don't
create a new Lisp dialect just because you don't like the esthetics of IF
and backquote. There should be a stronger reason to force people to learn
a new dialect and lose compatibility with an existing code base. And
dialects that are "almost but not quite" like one of the existing dialects
are a big problem, IMHO -- programmers with experience in the the existing
dialect will easily lose track of the small number of differences. If you
look at the Lisp family, you see vast differences between the popular
dialects, which makes sense (the more differences, the harder it is to port
existing software and expertise to some other dialect, so the old dialect
is hard to kill).
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
From: Howard R. Stearns
Subject: implementing dialects (Re: ANN: NiCLOS Engineering Release now available)
Date:
Message-ID: <372F5D5E.3205D7DC@elwood.com>
My worms-eye view of the larger Lisp world is that there are far more
commercial applications that implement some kind of proprietary Lisp
dialect (including dialects of Scheme, etc.) than there are those that
are based in any implementation of a standardized dialect.
I don't know why this should be the case. (Indeed, I don't even know
that it's actually true.) I certainly don't think that it's a good idea
to go around reinventing the same things all the time.
In the case of CL, I could see people thinking that they don't want to
embed a product in something they have to pay a license for, but given
Eclipse, flexible options from other vendors, and indeed, the existance
of CMUCL, GCL, etc., I don't think this argument holds water. And why
do people keep reimplementing Scheme in order to base products?
Here we are beating up on Kelly for doing the right thing -- starting
with a standardized Lisp as an implementation substrate and embedding a
domain-specific language in it. That's what Lisp is for, damn it. (We
can argue over his choices for that domain-specific language, and I
think that's what Barmar is saying.) Suppose Kelly had implemented
everything in Java, creating yet another Lisp implementation in the
process. This new Lisp language, would indeed be a different dialect.
Would we be happier?
Barry Margolin wrote:
>
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >Barry Margolin <······@bbnplanet.com> writes:
> >
> >> The only other dialect of Lisp that has been invented in recent years was
> >> ISLisp. It was created to solve a problem of international politics, not
> >> for any good technical reason.
> >
> >Some might dispute this entirely. Others might say you were missing
> >an "m" in the last line here.
>
> I'm sure they would. I admit that my comment was probably a bit extreme,
> for rhetorical purposes.
>
> I still feel that new dialects should not be created on a whim. Don't
> create a new Lisp dialect just because you don't like the esthetics of IF
> and backquote. There should be a stronger reason to force people to learn
> a new dialect and lose compatibility with an existing code base. And
> dialects that are "almost but not quite" like one of the existing dialects
> are a big problem, IMHO -- programmers with experience in the the existing
> dialect will easily lose track of the small number of differences. If you
> look at the Lisp family, you see vast differences between the popular
> dialects, which makes sense (the more differences, the harder it is to port
> existing software and expertise to some other dialect, so the old dialect
> is hard to kill).
>
> --
> Barry Margolin, ······@bbnplanet.com
> GTE Internetworking, Powered by BBN, Burlington, 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.
From: Fernando Mato Mira
Subject: Re: implementing dialects (Re: ANN: NiCLOS Engineering Release now available)
Date:
Message-ID: <3730279B.56D29E6C@iname.com>
"Howard R. Stearns" wrote:
> Here we are beating up on Kelly for doing the right thing -- starting
> with a standardized Lisp as an implementation substrate and embedding a
> domain-specific language in it. That's what Lisp is for, damn it. (We
> can argue over his choices for that domain-specific language, and I
> think that's what Barmar is saying.) Suppose Kelly had implemented
> everything in Java, creating yet another Lisp implementation in the
> process. This new Lisp language, would indeed be a different dialect.
> Would we be happier?
I know. It's one of those things where you can't be completely
consistent. But my point is the same as that of barmar: these
look too much like a couple gratuitous changes in something
that as a whole follows a different style.
NiCLOS SilkScript supports Common Lisp syntax.
If you are a CL programmer, you can use CL syntax
to write NiCLOS web apps, i.e. (setf foo 10),
(if (eq foo 10) 20 30) (let ((bar 10)) ..)
(cond ((..) (..))).
In fact, I have backed-off syntactic changes
that are incompatible, such as balanced single quotes,
i.e. (let x = 'foo' ..)
But SilkScript is much MORE than just syntax differences.
In my view, 98% of web application developers do not know
Common Lisp, and thus SilkScript is specifically designed
to be a simpler language than CL that will be easier to document
and I predict easier to learn and become proficient with.
(Note that if you're selling CL, it makes sense to want
the world to learn CL, but that is not our business.
As a further note, why is it that there does not exist
ANY CL third-party tools vendors?)
I don't think NiCLOS web apps need Complex Numbers, or Defstruct
or Deftype or Load or Compile-File or even Intern and Defpackage.
It would be a very bad business decision to throw copies
of ANSI Common Lisp manuals to our prospective developers
as documentation on how to develop web apps.
Lispers argue that Lisp is great for creating new
domain-specific languages -- that is what SilkScript is,
a web-app-specific language.
Notice that the CL Community already has CL-HTTP, which as far as I know
has not been very successful, despite being available for free
and including all the source code.
I would be most pleased if CL-compatibility is worth something
--- show me CL programmers that are developing
commercial web applications that will pay for a NiCLOS license,
and I will continue to argue to my business partners why
we shouldn't have a VB or Java or Perl or TCL or XML extension language
in the server like other competing products in the marketplace.
-Kelly Murray ···@niclos.com
Barry Margolin wrote:
>
> In article <············@nnrp1.dejanews.com>,
> Vassil Nikolov <········@poboxes.com> wrote:
> >I guess it needs to be repeated once again that Lisp is not a language,
> >it is a family of languages. Common Lisp is one of those (in fact,
> >it has three varieties now: 1st and 2nd edition CL, and ANSI CL).
> >Others include (in no particular order) Scheme, Emacs Lisp, Autolisp;
> >Lisp 1.5, Maclisp, Interlisp, Zetalisp, *Lisp, Franz Lisp, Portable Lisp,
> >etc.
>
> Most of the non-Common Lisps still exist for a simple historical reason:
> they predated Common Lisp, and there's lots of code that depends on them,
> and/or there are programming communities that have grown around them.
>
> However, it seems like a bad idea to invent a new dialect of Lisp at this
> point. Why not embed one of the existing, popular dialects rather than
> needlessly branching off?
>
> The only other dialect of Lisp that has been invented in recent years was
> ISLisp. It was created to solve a problem of international politics, not
> for any good technical reason.
>
> --
> Barry Margolin, ······@bbnplanet.com
> GTE Internetworking, Powered by BBN, Burlington, 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.
In article <·················@IntelliMarket.Com>,
Kelly Murray <···@IntelliMarket.Com> wrote:
>I don't think NiCLOS web apps need Complex Numbers, or Defstruct
>or Deftype or Load or Compile-File or even Intern and Defpackage.
>It would be a very bad business decision to throw copies
>of ANSI Common Lisp manuals to our prospective developers
>as documentation on how to develop web apps.
>Lispers argue that Lisp is great for creating new
>domain-specific languages -- that is what SilkScript is,
>a web-app-specific language.
I don't think there's anything wrong with an application-specific subset.
But in the aspects of the language that remain, I think it's reasonable to
use standard syntax rather than making up a new variant.
However, if you've subsetted it as far as the above paragraph indicates,
compatibility probably isn't much of an issue. As I said, I was more
concerned with dialects that are "almost but not quite like" an existing
dialect. It does sound like you've staked out your own point on the
continuum.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
From: Sam Steingold
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <m3emkvu548.fsf@eho.eaglets.com>
>>>> In message <·················@IntelliMarket.Com>
>>>> On the subject of "Re: ANN: NiCLOS Engineering Release now available"
>>>> Sent on Tue, 04 May 1999 12:40:51 -0700
>>>> Honorable Kelly Murray <···@IntelliMarket.Com> writes:
>>
>> I don't think NiCLOS web apps need Complex Numbers, or Defstruct
>> or Deftype or Load or Compile-File or even Intern and Defpackage.
this is the old problem of choosing between a "scripting language" and a
real language for extensions.
in http://www.goems.com/~sds/tool.html I argue that an extension
language should be a full-fledged high-level mature language with a
well-developed library since whenever a good application has an
extension language, people start writing *EVERYTHING* in that language,
and there is no reason to constrain them.
the bottom line is: you don't know what your users will want.
--
Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Trespassers will be shot. Survivors will be prosecuted.
Sam Steingold wrote:
>
> >>>> In message <·················@IntelliMarket.Com>
> >>>> On the subject of "Re: ANN: NiCLOS Engineering Release now available"
> >>>> Sent on Tue, 04 May 1999 12:40:51 -0700
> >>>> Honorable Kelly Murray <···@IntelliMarket.Com> writes:
> >>
> >> I don't think NiCLOS web apps need Complex Numbers, or Defstruct
> >> or Deftype or Load or Compile-File or even Intern and Defpackage.
>
> this is the old problem of choosing between a "scripting language" and a
> real language for extensions.
>
> in http://www.goems.com/~sds/tool.html I argue that an extension
> language should be a full-fledged high-level mature language with a
> well-developed library since whenever a good application has an
> extension language, people start writing *EVERYTHING* in that language,
> and there is no reason to constrain them.
That is part of the point of NiCLOS, the scripting language
is a "real" language, the same language the "system" is implemented
in, which compiles to native machine code and is scaleable.
The system is built with a Common Language Object System.
If you mean to say a "real" language needs all of Common Lisp,
then you must not consider "C" or "Scheme" or "Dylan"
to be a "real" language because they don't have all this stuff
that CL has.
>
> the bottom line is: you don't know what your users will want.
>
Note that I've actually USED NiCLOS for a long time,
and I can say from experience and I have never needed
Complex Numbers, Deftype, Defstruct, Load, Compile-File, Intern,
Defpackage, etc.
But with an implementation base of CL,
it is possible to "give" just about anything
if it turns out it is really necessary.
-Kelly Murray ···@niclos.com http://www.niclos.com
> --
> Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux
> Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
> (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
> Trespassers will be shot. Survivors will be prosecuted.
From: Erik Naggum
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <3134943930910275@naggum.no>
* Kelly Murray <···@IntelliMarket.Com>
| If you mean to say a "real" language needs all of Common Lisp, then you
| must not consider "C" or "Scheme" or "Dylan" to be a "real" language
| because they don't have all this stuff that CL has.
I think you have answered your own question (why are there third-party
tools vendors for other languages, but not Common Lisp?): the other
languagages are in fact seriously incomplete without third-party tools
vendors.
#:Erik
From: Sam Steingold
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <m33e1aqmt7.fsf@eho.eaglets.com>
>>>> In message <·················@IntelliMarket.Com>
>>>> On the subject of "Re: ANN: NiCLOS Engineering Release now available"
>>>> Sent on Wed, 05 May 1999 18:03:52 -0700
>>>> Honorable Kelly Murray <···@IntelliMarket.Com> writes:
>> Sam Steingold wrote:
>> >
>> > in http://www.goems.com/~sds/tool.html I argue that an extension
>> > language should be a full-fledged high-level mature language with a
>> > well-developed library since whenever a good application has an
>> > extension language, people start writing *EVERYTHING* in that language,
>> > and there is no reason to constrain them.
>>
>> That is part of the point of NiCLOS, the scripting language is a
>> "real" language, the same language the "system" is implemented in,
>> which compiles to native machine code and is scaleable.
>> The system is built with a Common Language Object System.
how is it related to CLOS?
>> If you mean to say a "real" language needs all of Common Lisp, then
>> you must not consider "C" or "Scheme" or "Dylan" to be a "real"
>> language because they don't have all this stuff that CL has.
absolutely.
a "high-level" (or, if you prefer, "real") language should have
- GC (<==> no pointers)
- OO
- everything first class
- standard hashtables, adjustable arrays, strings, lists &c.
see http://www.goems.com/~sds/tool.html for details.
>> > the bottom line is: you don't know what your users will want.
>>
>> Note that I've actually USED NiCLOS for a long time, and I can say
>> from experience and I have never needed Complex Numbers, Deftype,
>> Defstruct, Load, Compile-File, Intern, Defpackage, etc.
a successful tool will be used for what the creator did not intend it to
be used for. if you didn't need something before, this doesn't mean I
won't need this in the future.
--
Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Trespassers will be shot. Survivors will be SHOT AGAIN!
From: Howard R. Stearns
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <3731E2DF.D7921106@elwood.com>
Sam Steingold wrote:
> ,,,
> a "high-level" (or, if you prefer, "real") language should have
> - ...
> - everything first class
> - ...
Really? Continuations? Environments? Bindings? Blocks? Tagbody
tags? Declarations? Breakpoints? "Places"? Memory locations? Time
intervals? Garbage collections? Registers? Processors? Disk drives,
busses, memory pages....?
Sam Steingold wrote in message ...
>>>>> Honorable Kelly Murray <···@IntelliMarket.Com> writes:
> >>
> >> I don't think NiCLOS web apps need Complex Numbers, or Defstruct
> >> or Deftype or Load or Compile-File or even Intern and Defpackage.
>
>this is the old problem of choosing between a "scripting language" and a
>real language for extensions.
>
>in http://www.goems.com/~sds/tool.html I argue that an extension
>language should be a full-fledged high-level mature language with a
>well-developed library since whenever a good application has an
>extension language, people start writing *EVERYTHING* in that language,
>and there is no reason to constrain them.
>
>the bottom line is: you don't know what your users will want.
Disclaimer: I haven't looked at Kellys latest and greatest.
It seems pretty clear to me that NiCLOS is simply a thin layer of sugar on
top of a Web Server and an Object Store. I don't think Kelly went and
"removed" all of those things he mentioned, he's just not going to document
them in his product.
What's important here isn't the candy coating the Kelly has placed on top of
Lisp, but how well does his Web Server and Object Store work? All you need
to know is how to read the sugar he's added. Nothing forces you to use it.
The only other thing that he may have done is used an object system that
isn't CLOS. He's mentioned that before, mostly for performance, but perhaps
ACL 5 is fast enough that he didn't bother. But, he have done it anyway to
support his Object Store.
Some day, someone is going to look at NiCLOS and say "Boy, this sure looks a
whole bunch like Lisp". At that point, Kelly mails them the HyperSpec URL
with the subject "Congratulations! Your probing insite wins you a cookie!".
Then the secret gets out.
Will Hartung
(·····@msoft.com)
From: Erik Naggum
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <3134943719915207@naggum.no>
* Kelly Murray <···@IntelliMarket.Com>
| (Note that if you're selling CL, it makes sense to want the world to
| learn CL, but that is not our business.
but it is. you want the world _not_ to (have to) learn Common Lisp.
| As a further note, why is it that there does not exist ANY CL third-party
| tools vendors?)
this is actually a good question. here's my take on it: in order for
there to be a huge market for something, you need publicity, and in order
to get publicity, you need to have serious flaws and problems that make
people want to talk about your product. when people talk about flaws and
problems, some people will see a market for their own third-party tools
and packages, just as some people see a market for magazines and news
coverage of the players in the third-party tools market. in order to get
this ball rolling, your product obviously has to be quite useful or have
the potential of becoming quite useful or people won't put up with the
flaws and start talking about them or, better yet, try to fix them for
you. so, to be successful, you need something that is obviously useful
so people will use it and obviously broken so people will fix it after
they have started to use it. now, if you're really smart, your fixes are
_also_ half-assed, and you hook people into the con game by offering new
and improved fixes, and the primary vendor offers new and improved shit
that has different flaws and problems, so the third-party tools vendors
also stay in business. on top of this, if you can pull it off without
anyone noticing it, allow nasty viruses to take advantage of you product
and voil�, you have publicity in the media and an air of responsibility
when you take charge to plug security holes, and you create business for
people who plug security holes for you while you also ensure that a lot
of criminally-minded idiots will use your system for their activities.
Common Lisp doesn't have the "obviously broken" property, so it doesn't
get popular because programmers can't share stories. it's damn hard to
fix Common Lisp, so people don't. you can't really make a living out of
writing about complaints about Common Lisp, so the magazines don't spring
into existence. you won't have any fun writing viruses for Common Lisp
systems, either, so you neither get publicity nor the attention of the
criminal world. all in all, you lose if you don't peddle broken shit.
all in all, I think it's a wonderful situation that there are no third-
party tools vendors for Common Lisp. :)
| I don't think NiCLOS web apps need Complex Numbers, or Defstruct or
| Deftype or Load or Compile-File or even Intern and Defpackage. It would
| be a very bad business decision to throw copies of ANSI Common Lisp
| manuals to our prospective developers as documentation on how to develop
| web apps.
why? have you seen what the other "apps" come with? _tomes_ with what
passes for reference material. and not just crappy Windows cruft, but
serious stuff like Oracle databases or cisco systems routers/firewalls.
| Lispers argue that Lisp is great for creating new domain-specific
| languages -- that is what SilkScript is, a web-app-specific language.
I'm sure it is that, too, but changing the syntax of core operators is
not what people usually associate with domain-specific languages.
| Notice that the CL Community already has CL-HTTP, which as far as I know
| has not been very successful, despite being available for free and
| including all the source code.
the reasons for this are very complex, and should not be taken as
arguments for a particular differing view.
| I would be most pleased if CL-compatibility is worth something --- show
| me CL programmers that are developing commercial web applications that
| will pay for a NiCLOS license, and I will continue to argue to my
| business partners why we shouldn't have a VB or Java or Perl or TCL or
| XML extension language in the server like other competing products in the
| marketplace.
this is _really_ not how you attract people's attention. you just told
me, in effect, that I can't trust the stability of your product and that
I'd be foolish to invest any time in learning SilkScript or developing
"apps" in it, because you're competing out in the open with those crappy
languages that have all the obviously-broken properties they can possibly
get their hands on, and are therefore guaranteed success. you should
instead focus on telling me that I should be able to trust you to stay
around, to capitalize on the existing skills and that I can expand my
skills into the Common Lisp third-party tools market, if I use NiCLOS.
on the other hand, people _are_ talking about NiCLOS because it is
obviously broken in the "gratuitously changed syntax" department.
#:Erik
Fernando Mato Mira <········@iname.com> writes:
> I know he never refers to it at Lisp. The problem is people who have
> some vague notion of what Lisp looks like and will start spreading
> misinformation.
Well, then you should probably first get AutoCAD Lisp (and maybe Emacs
Lisp) destroyed and removed from the past, shouldn't you? While both
of them exhibit (some parts of) normal Lisp syntax, they are in other
parts quite broken w.r.t. Common Lisp (i.e. dynamic scope, slow, even
sometimes case-sensitive). I'd guess that contact with AutoCAD Lisp
has probably turned more newbies away from Lisp and confused more of
them about Lisp's nature than NiCLOS will probably ever get as
customers.
And McCarthy's Lisp 1.5, MacLisp and Interlisp should probably be
banned in retrospect as well... And maybe we need to excorcize Common
Lisp's loop construct, too. Oh, and if I see it correctly, then
NiCLOS' syntax can be/is achieved through a normal CL and the
read-table, so arguably, this is either Common Lisp syntax, or most
everyone should be banned from changing the read-table.
IMHO this whole deal about not giving misimpressions to the newbies is
ill-conceived. We have far better areas to worry about, than this
small opportunity for misunderstanding. Indeed, I'd think that if KEM
put up a large sign at the website, saying "This is NOT (Common)
Lisp", I think that _more_ people would get misimpressions about the
thinks that can be derived from NiCLOS w.r.t. Common Lisp[1]. And it
would thus probably harm both NiCLOS and Common Lisp more.
Regs, Pierre.
PS: I also think that Common Lisp has no right to set precedents for
what constitutes "Real Lisp Syntax(tm)". Under these grounds loop
would never have happened, and now you need to support it to be "The
Real Thing!(tm)"?!?
Footnotes:
[1] That is because those who are apt to draw wrong conclusions from
evidence, are mostly not thinking logically to begin with...
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Fernando Mato Mira
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <372EC70E.4AB835C9@iname.com>
"Pierre R. Mai" wrote:
> Fernando Mato Mira <········@iname.com> writes:
>
> > I know he never refers to it at Lisp. The problem is people who have
> > some vague notion of what Lisp looks like and will start spreading
> > misinformation.
>
> Well, then you should probably first get AutoCAD Lisp (and maybe Emacs
> Lisp) destroyed and removed from the past, shouldn't you? While both
> of them exhibit (some parts of) normal Lisp syntax, they are in other
> parts quite broken w.r.t. Common Lisp (i.e. dynamic scope, slow, even
> sometimes case-sensitive). I'd guess that contact with AutoCAD Lisp
There're are many (most old) lisps that are really broken, but
they don't violate the basic principle of Lisp syntax in general.
Neither elisp nor Autocad use things like:
(set <var> = <value>)
From: ····@cs.tu-berlin.de
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <7gn8mt$guk$1@nnrp1.dejanews.com>
In article <·················@iname.com>,
Fernando Mato Mira <········@iname.com> wrote:
> There're are many (most old) lisps that are really broken, but
> they don't violate the basic principle of Lisp syntax in general.
I think describing most old Lisps as "really broken" is a somewhat
heavy-weight judgement on the past. But that's another issue.
> Neither elisp nor Autocad use things like:
>
> (set <var> = <value>)
So this would mean ELisp and Autocad's Lisp are right, and we should destroy
Common Lisp instead, which has violated this basic principle of Lisp syntax:
(loop with <var> = <value>
for <var2> = (random <var>)
if (evenp <var2>) collect (/ <var2> 2) else collect (/ (1+ <var2>)))
Sorry, but I don't think this kind "the one true syntax" discussion is
getting anywhere. Now I don't think that NiCLOS' syntax is all that great,
and I really doubt whether it is going to advance the easy of use of NiCLOS,
since IMHO it just stands in the way of consistency (both internal and
external). But I really don't think argueing about the "one true syntax of
Lisp" is any useful reaction to that, especially since CL has provided the
precedent in this area.
Regs, Pierre.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <············@nnrp1.dejanews.com>, <····@cs.tu-berlin.de> wrote:
>So this would mean ELisp and Autocad's Lisp are right, and we should destroy
>Common Lisp instead, which has violated this basic principle of Lisp syntax:
>
>(loop with <var> = <value>
> for <var2> = (random <var>)
> if (evenp <var2>) collect (/ <var2> 2) else collect (/ (1+ <var2>)))
CL didn't invent this, it inherited it from its progenitors (LOOP was
popularized under Maclisp).
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
Barry Margolin <······@bbnplanet.com> writes:
> CL didn't invent this, it inherited it from its progenitors (LOOP was
> popularized under Maclisp).
I didn't mean to imply otherwise. I should have written "Common Lisp
(through inheritance) violated this". Since we aren't concerned about
moral guilt at the moment, the fact that CL inherited LOOP is IMHO no
reasonable defence against the allegation of "Violating the One True
Lisp Syntax"... ;)
I think from a programming POV, the use of (set XXX = XXX) in NiCLOS
should not be judged differently from the use of (loop with XXX = XXX
do <body>) in CL, just because CL inherited this from MacLisp, and KEM
invented it in NiCLOS.
Rather (set XXX = XXX) and (loop with XXX = XXX) should each be judged
according to the usual standards for syntax, in the context of their
respective languages:
- Is it unambiguous?
- Is it succinct?
- Is it consistent within the language?
- Does it allow for the anticipated and real-world usage patterns?
- Is it easy to learn/remember, and more importantly (IMHO) is it easy
to use?
- Is it not error-prone?
- ...
In my very humble and tentative opinion as a non-user of NiCLOS, and
thus extrapolating from CL, (set XXX = XXX) suffers from many of the
same problems that LOOP suffers from, with the addition of providing
questionable benefits to the experienced user (whereas LOOP is the
only standard way of doing descriptive iteration in CL, and thus
does offer functionality other constructs lack).
So the "only" reason I see for set&co. in NiCLOS is KEM's conjecture
that his intended audience will find this syntax easier to learn. I
can't pass judgement on the validity of this conjecture, lacking any
serious knowledge about his intended audience. But let me observe
that from the sample programs in NiCLOS that I've seen, I think KEM's
changes to NiCLOS's syntax are *too few*, so that inner consistency
suffers. And I think that missing inner consistency is a hurdle
towards ease of learning in any audience.
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Fernando Mato Mira
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <373023B3.4B509BA7@iname.com>
····@cs.tu-berlin.de wrote:
> In article <·················@iname.com>,
> Fernando Mato Mira <········@iname.com> wrote:
>
> > There're are many (most old) lisps that are really broken, but
> > they don't violate the basic principle of Lisp syntax in general.
>
> I think describing most old Lisps as "really broken" is a somewhat
> heavy-weight judgement on the past. But that's another issue.
I meant that most broken Lisps are old, not the other way around.
I should have written "mostly".
> > Neither elisp nor Autocad use things like:
> >
> > (set <var> = <value>)
>
> So this would mean ELisp and Autocad's Lisp are right, and we should destroy
> Common Lisp instead, which has violated this basic principle of Lisp syntax:
I didn't say that. I hate AutoLisp and its broken `/' syntax for local
variables.
>
> (loop with <var> = <value>
> for <var2> = (random <var>)
> if (evenp <var2>) collect (/ <var2> 2) else collect (/ (1+ <var2>)))
That's why I said "in general". LOOP constructs with tags have been around
for a long time. This one goes further. If you don't like this LOOP, you don't
need to use it. It's a high-level macro thing. The other place where tags occur
is in TAGBODY, and that's a low-level facility for `language' implementors.
Even if you wanted to forgive NiCLOS because of TAGBODY
and classic LOOP, `then' and `else' in NiCLOS are not tags. You can't say (goto
then). And if you could, wouldn't that be a _Bad_Thing_?
Regarding `set', there's one point that is probably of little relevance.
Traditional SET evaluates both arguments. That's where SETQ
comes from.
I understand that he wants to make it more marketable by adding
those markers, but I'm not sure if that's how it will work out.
What could happen is that non-lispers will bash it because
of its `Lisp syntax', and lispers will flee it because of the bastardized
syntax.
I could relentlessly point somebody to a non-standard Lisp - based tool,
but certainly not to this. I'm not a web developer, so maybe it's not too
relevant that I don't care finding out more and understanding how is
this tool interesting. On the other hand, I've been wanting to play with
CL-HTTP for a long time.
Fernando Mato Mira <········@iname.com> writes:
> That's why I said "in general". LOOP constructs with tags have been
> around for a long time. This one goes further. If you don't like this
I don't think the time argument should apply here.
> LOOP, you don't need to use it. It's a high-level macro thing. The
If I understand correctly, in NiCLOS you can always/mostly fall back
on standard CL syntax (see the demo sources, where I think there are
some mix-ups with old CL syntax somewhere).
> LOOP, `then' and `else' in NiCLOS are not tags. You can't say (goto
WHEN and ELSE in LOOP aren't tags either, in fact a very disturbing
thing about LOOP's keywords are that they are not treated like normal
symbols in the rest of CL at all: That is (loop KKK::FOR x in y) is
treated the same as (loop CL::FOR x in y) even if KKK::FOR and CL::FOR
are different symbols!
> I understand that he wants to make it more marketable by adding
> those markers, but I'm not sure if that's how it will work out.
> What could happen is that non-lispers will bash it because of its
> `Lisp syntax', and lispers will flee it because of the bastardized
> syntax.
That may very well happen, I'm not arguing about that (in fact I
think it quite possible to occur as well). That, as Kent Pitman
might say, is for the market to sort out. The same argument IMHO
applies to Dylan, and it seems to be doing well (of course I think
Dylan's new syntax is much more consistent, both in itself, and with
the expectations of the intended target audience, than NiCLOS's). If
NiCLOS will do well, great! If it won't, well, I've got no stake in
KEM's business...
> I could relentlessly point somebody to a non-standard Lisp
> - based tool, but certainly not to this. I'm not a web developer, so
> maybe it's not too relevant that I don't care finding out more and
> understanding how is this tool interesting. On the other hand, I've
> been wanting to play with CL-HTTP for a long time.
IMHO the point you are missing is that NiCLOS isn't a CL library/tool
like CL-HTTP, and isn't marketed as such. That has nothing to do with
NiCLOS's syntax. Since I work in CL, NiCLOS isn't for me either, but
e.g. all the nice tools for Scheme aren't, too. Now I don't go over
to the Scheme people, telling them that they are using the wrong
language (can't bitch about the syntax, since they've got the claim
to the "One and Only True Lisp syntax" ;), fragmenting the Lisp
market, or other such things. While I'd prefer the numerous Scheme
implementation builders to rather advance CMU CL or CLISP than to
build YASI with YAMS and YAGL, etc., it's their choice, based on
their perception of their markets.
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Fernando Mato Mira
Subject: Re: ANN: NiCLOS Engineering Release now available
Date:
Message-ID: <37314E13.4F455DC3@iname.com>
"Pierre R. Mai" wrote:
> Fernando Mato Mira <········@iname.com> writes:
>
> > That's why I said "in general". LOOP constructs with tags have been
> > around for a long time. This one goes further. If you don't like this
>
> I don't think the time argument should apply here.
The point was that LOOP syntax is not CL's fault (if a fault it is indeed).
> > LOOP, you don't need to use it. It's a high-level macro thing. The
>
> If I understand correctly, in NiCLOS you can always/mostly fall back
> on standard CL syntax (see the demo sources, where I think there are
> some mix-ups with old CL syntax somewhere).
Can I fall back to standard (if <predicate> <then> <else>) ?
> > LOOP, `then' and `else' in NiCLOS are not tags. You can't say (goto
>
> WHEN and ELSE in LOOP aren't tags either, in fact a very disturbing
I don't remember if in pre-CL LOOP (eg: IQLisp) there were other things
than tags. CL LOOP would degenerate from that in a similar (but more useful)
way than NiCLOS does.
[other stuff]
In this case it's not about fragmenting the Lisp market. It's about
doing things in a very Unix-like way, where you have all those annoying
little differences among sh,csh,tcsh,ksh, etc. providing nothing of real value.
NiCLOS is not for me. If the main audience is so allergic to lisp, I don't know
why he couldn't just go with python. I think that having yet another language,
even if lisp-like, is worse than making one more tcl or perl based tool.
As I read somewhere in this thread, the syntax changes might be more the PHBs
fault,
than Kelly's. If forced, I think I would also do something like this to avoid
dealing
with those other languages, although it would not be very ethical (a la
Stroustroup).
In article <·················@iname.com>,
Fernando Mato Mira <········@iname.com> wrote:
(...)
> As I think you'll go anyway with this, you should put a big sign saying
> `THIS IS NOT LISP', otherwise we'll have to deal with more people saying
> that Lisp has a confusing (and now verbose) syntax.
Thou shalt have no other Lisp but Lisp.
--
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own