> 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?
> 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.
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.
> 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?
> 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:
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").
"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.
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?