Hacker News Reader

Well, okay, it's not literally called Lisp; it has the "Common" in front. On the surface, it seems to be sticking to the letter of the wish. Does it conform to the spirit, though? Is a common English adjective enough? Is "Common" a sufficient qualifier?

Yes. Yes it is.

("new" is more common than "common", but not incredibly so: https://books.google.com/ngrams/graph?content=common%2Cnew&y...)

When the next Lisp comes out, this one won't be "new" anymore so it'll be just "Lisp".

I've never seen a rewrite or next generation of any program or function called "common". But new is common: ntalkd -- new talkd; nvi -- new vi; nftw -- new version of the ftw POSIX function (file tree walk); ncurses -- new curses; ncal -- new cal program; nawk -- new awk, ...

Basically Lutz calling his project NewLisp is a form of trolling.

Common Lisp was supposed to provide a "common" successor to the various Lisp platforms developed especially at MIT's project MAC, SAIL, and the Lisp machine vendors spun off from these.

>Change the arrogant name, and you will not hear another criticism from Lisp programmers.

I don't think anyone else cares for that, or even went that far in their syllogism anyway.

Agreed. Most people just freak-out over the speed (it's closer to picolisp than SBCL being interpreted) although I recall a pretty major design decision that most lisps haven't used in decades that many would consider a flaw. I do like that it is similar to python in that it is easy to setup and comes preloaded with a lot of libraries.

I wonder if the reason that a Lisp hasn't made it into the mainstream is that Lispers can shut up about pedantic naming rules that are completely and totally unimportant.

It's important because we have to distinguish between many dialects. If any of them are just Lisp, it starts to get confusing.

Despite what the CLers say, we all have an equal claim to the name.

> Despite what the CLers say, we all have an equal claim to the name.

Agreed, but who cares? Is this what you want the Lisp community to spend our time on?

> It's important because we have to distinguish between many dialects. If any of them are just Lisp, it starts to get confusing.

I don't think it's important. I'm not confused, and if you understand what's going on enough to disagree with it, you aren't confused either.

More to the point, neither being confused about what dialect is being discussed nor arguing about semantics helps anyone, but at least confusion doesn't waste enormous amounts of time and energy, divide the community, and derail productive discussions.

Look at this thread. I'd like to talk about ORO memory management, which is pretty interesting, but instead we're talking about semantics. The top response is about terminology. Is this what you want?

No, not especially. I think terminology matters, but not that much, and not compared to the more interesting aspects of NewLisp. That's why I didn't upvote Kaz. I'd down him, but I'm OP, so I can't.

Naming a project in such a way as to troll people is not a matter of "terminology".

Terminology issues consist of inter-language conflicts among definitions of technical terms like "list", "scope", "variable" or "macro" and such.

The proper noun that Lutz Mueller chooses to call his project is not a definition of a technical term.

To me, NewLisp is uninteresting. I already know how to avoid sharing issues in memory management in C programs by mallocing a copy of everything and duplicating it; that bores me. Lots of programs in POSIX environments do that with strings: strdup everything you receive, and cheerfully free it knowing that nobody else has that pointer. NewLisp is just doing "strdup for lists". It might as well work using strings, just like the "Lisp in sed" implementation: https://github.com/shinh/sedlisp . Why use objects, when pictures of objects provide a reasonable facsimile? I know how fexprs work, and they bore me also. Once you allow them, you can kiss goodbye the future prospect of having a compiler. As an implementor, if I want to introduce a new special operator in an interpreter (a decision not to take lightly), I can write it in the hosting language (such as C), and not as a fexpr. By writing such an operator, I get essentially the same development experience as if I wrote a fexpr, without inflicting harm on the language. If interpretation is a wart, then interpreted code being dispatched to interpret code is a tuft of hair growing out of wart.

...That depends on whether you think interpretation is a wart: if you don't need the perf, a lot of us don't.

And you have no evidence that that was Lutz's intent.

> Naming a project in such a way as to troll people is not a matter of "terminology".

1. I see no reason to NewLisp was named to troll people. It only has the effect of trolling you because you have created a subset of the English language in your head which you view as "correct" without any basis in reality.

2. In the English language, "terminology" can be applied to the names of programming languages and people will know what you're talking about. It can also be applied to things like "list", "scope", etc.; generally people use context clues to figure out what you're talking about.

> To me, NewLisp is uninteresting. I already know how to avoid sharing issues in memory management in C programs by mallocing a copy of everything and duplicating it; that bores me.

Thank you for sharing. I'm sure you're very knowledgeable and smart and whatnot, have a cookie. Now can we who are interested and curious about this have a conversation without you butting in, please?

I'd like to know:

What are the performance implications of doing ORO universally? The tradeoff seems to be that copying takes time, but it also allows you to treat everything as stack-allocated, so it saves time on heap management. What's the average case performance like? In what cases is this a good tradeoff? In which cases is this a bad tradeoff?

Somewhere down the original thread, somebody posted some benchmarks, IIRC.

Not as helpful as I'd like, but hope it helps nonetheless.

> Now can we who are interested and curious about this have a conversation without you butting in, please?

Judging by the root post, it appears I started this thread on the subject of the trollish behavior of the NewLisp project. You can collapse it and use another one.

> I see no reason to NewLisp was named to troll people.

I have visited the NewLisp website a couple of times in the last 15 years or so and found trollish content. Example:

https://web.archive.org/web/20041010181233/http://newlisp.or...

Quote: "Don't read books about LISP, if you want to learn newLISP, most deal with Common LISP or Scheme, two different older standards of LISP. These books teach you many concepts unnecessary to learn newLISP, which does some things in a very different way than the older standards. Try to understand newLISP on it's own terms."

There you go!

* Don't read books about Lisp.

* Lisp and Scheme are older standards (NewLisp is the new standard, hence the "New").

Newer version of last sentence:

https://web.archive.org/web/20080726054533/http://www.newlis...

"newLISP does things much differently from the older standards, in ways that are more applicable to today's programming tasks."

Thus, pre-existing Lisps are not applicable to today's programming very well; here is a new standard to fix it. We're bringing back dynamic-scope-only and frexps because today's programming once again requires a Lisp from 1960.

"More applicable" isn't trollish enough, so the webmaster added the text "and on a higher level closer to the problem at hand" sometime by 2012, which stands today. (The "old standards" are low-level languages, incapable of the same level of abstraction offered by NewLisp). At least the "don't read books" remark was removed, though.

> I'd like to talk about ORO memory management, which is pretty interesting

I'd like to see talk about ORO memory managment which is not of the following form: "NewLisp isn't really Lisp because of its <expletive deleted> ORO memory management; you cannot replace real Lisp with that kind of cruft ..."

That is why I have tried to articulate what I suspect it is that actually bugs Lisp people about NewLisp. It's not the fexprs or the lists working differently and so on; trying to frame it technically is misguided.

If you have some problem with the trolling behavior of a project, but you try to frame it in technical terms, that's a waste of time.

I hate that. Seeing as I'm a Schemer, I also hate the other classics: It's not really a lisp because false and nil aren't the same, It's not really a lisp because it doesn't have real* macros, and It's not a lisp for various reasons which amount to: it's not CL or any of its predecessors*.

My usual responses to each of these, respectively, are: come off it, even McCarthy says that was totally by chance, and may not have been the best idea; pretty much every implementation has really macros, and even the original lisp didn't have real macros; and finally, come on, Rainer, we've had this discussion like three times already.

But I don't think the project is trolling, and I don't have any problem with the project's behavior. I'm curious about ORO. You're the only one who's looking for a fight here.

> Despite what the CLers say, we all have an equal claim to the name.

Only actual Lisp dialects have a claim to the name.

That's why Scheme is called Scheme and not Lexical Lisp. That's why Logo is called Logo and not Simple Lisp. That's why Javascript is called Javascript and not WebScheme. That's why Racket is called Racket, and not NewScheme.

And your definition of what makes a Lisp is pretty strange. For one thing, Racket and Scheme are definitely in the lisp family.

It's not my definition. I just happen to agree with a lot of others, many who don't post here. It's also not new. I just remind people of a view, you might never heard of, because you never were involved in Lisp meetings, Lisp conferences or Lisp standardization efforts. Lisp is old, and many younger people don't know much of its history and evolution.

See for example Pitman, Lambda the ultimate political party

http://www.nhplace.com/kent/PS/Lambda.html

Published in Lisp Pointers (a regular Lisp magazine, published in the 80s/90s) in 1994.

> Lisp users are accustomed to being able to write programs that take program texts in different dialects (or older versions of the same dialect) and process them to bring them up to date. No single common linguistic feature supports this. And yet, Lisp users are accustomed to expecting that there will be some way to accommodate the needs of compatibility and translation.

That's is what makes Lisp, in my opinion. Sharing of code, implementations, libraries, books, tools, ...

A language spectrum serves a diverse community. It is not a dead body of abstract and vague principles. It grows out of sharing and communication.

Kent knows the Lisp and Scheme landscape very well. He worked as developer, in standardisation efforts (both Lisp and Scheme), as an implementor, editor, author, etc.

I read Pittman. The thing is, the Scheme community may not be able to share code directly, but we are able to, and often do, share ideas. In addition, many Schemers are active in the CL community and vice versa, like Pittman. Many of the same people were involved in the standardization effort, and the creation of both.

A language spectrum does indeed serve as a diverse commiunity. One us Schemers are a part of.

I know my history, I just disagree with you.

His name is Pitman. Kent Pitman.

> Many of the same people were involved in the standardization effort, and the creation of both.

I doubt that this is the case for R7RS.

> The thing is, the Scheme community may not be able to share code directly, but we are able to, and often do, share ideas.

That's my point. There are few ideas shared and no code. Today the various spinoffs of Lisp have their own communities. I don't say that it is bad or good, it's just the way it is. That's not only the fate of a programming language family, it also happens in other areas, that domains are divided into groups which have problems to understand each other and which are not able to track or use the work of other groups. The groups have different preferences and their topic gets an independent life.

Sorry. I always get names wrong.

As for r7rs, Sussman, at the very least, was on the commitee. Several other Lispers as well, IIRC, but it would take too long to check.

All the Lisps have different communities. That's why the languages are different. There's some overlap, but if the communities were identical than all the languages would be the same.

But then, you could say the same of C, C++, and Java, which don't all share code, but are all in the same family.

Sussman is a Schemer.

To be fair, he's done some lisp work. But that's true enough.

Steele was on the commitee for many years, although not this one.

I'd give you a list of CLers on the commitee, but I honestly can't dig through 12 people's online profiles just to prove a point right now.

I still don't see anything here which indicates to me that I should give a shit about NewLisp being called "NewLisp", or about referring to CL/Scheme/Racket/whatever as "Lisps".

Kaz's point is that NewLisp is slightly confusing, but it's not, not incredibly, so I don't see that point. I think terminology's important, but that particular instance isn't. As for why people complain about calling things Lisps, it's a mystery to me.

Now complaints about calling Racket Scheme, OTOH, I get. Scheme has a specification which Racket doesn't comply to: they changed the name for a reason when they started to deviate. Calling Racket Scheme is like seeing a language that's kind of similar to C and just calling it C.

Are you expecting a sound technical argument why designers should show respect at least for the sources where they cribbed most of their core ideas? Not piss into the pool where they learned to swim (even if merely the "doggy paddle")?

Sorry, I don't have that argument.

> Only actual Lisp dialects have a claim to the name.

Frankly, I don't give a fuck about anyone's "claim". If people can use a word to move an idea accurately from their brain to other people's brains, communication has occurred and I'm happy.

If I say "NewLisp" and my audience knows what interpreter I'm talking about, I have succeeded in my goal.

how is that any different than Common Lisp?

In a number of ways. "Common" is not that common of an adjective for software projects, compared to "new". Common Lisp is actually derived from dialects that trace their lineage to Lisp (the Lisp, unqualified) standardizing what is common among them. And the full name is actually "ANSI Common Lisp"; "Common Lisp" and "CL" are just nicknames.

Common Lisp people insisting on "Lisp" denoting "Common Lisp" are simply wrong, and that's that.

> Common Lisp people insisting on "Lisp" denoting "Common Lisp" are simply wrong, and that's that.

I don't think that's really true. After all, 'Common Lisp is actually derived from dialects that trace their lineage to Lisp (the Lisp, unqualified) standardizing what is common among them,' to quote someone. The intent of the Common Lisp standardisation effort was to standardise a common Lisp that programmers could rely on.

a Common Lisp. Anybody want to tell the Schemers that they're not Lisp (even though Scheme diverged from MacLisp, much the same as common lisp did), because you said so, for no real reason?

TXR looks more interesting (from your profile).

> you will not hear another criticism from Lisp programmers

From what I've seen of the lisp community, one of their favorite activities is criticizing variants of lisp that aren't their preferred one.

I made one and haven scarcely had any negative eaction from Lispers, including the Usenet newsgroup comp.lang.lisp.

Maybe that's because I didn't go around saying that it's a awesome, new, improved, easy-to-use dialect for the modern world that's going to replace outdated, academic, hard-to-use, stuffy Common Lisp and its ilk.

NewLisp in particular has attracted vitriol, and it's because of the arrogant trolling.

NewLisp is no worse than, say, AutoLisp, yet AutoLisp doesn't attract flaming every time it is mentioned.