5 ms·

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 un

by imagist 10y ago

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.

qwertyuiop924 10y ago
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.
- imagist 10y ago
  > 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?
  - qwertyuiop924 10y ago
    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.
    - kazinator 10y ago
      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 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.
      - qwertyuiop924 10y ago
        ...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.
      - imagist 10y ago
        > 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?
  - kazinator 10y ago
    > 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.
    - qwertyuiop924 10y ago
      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.
    - imagist 10y ago
      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.
- lispm 10y ago
  > 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.
  - qwertyuiop924 10y ago
    And your definition of what makes a Lisp is pretty strange. For one thing, Racket and Scheme are definitely in the lisp family.
    - lispm 10y ago
      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 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.
      - qwertyuiop924 10y ago
        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.

by imagist 10y ago

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.

qwertyuiop924 10y ago

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.

imagist 10y ago
> 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?
- qwertyuiop924 10y ago
  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.
  - kazinator 10y ago
    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 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.
    - qwertyuiop924 10y ago
      ...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.
    - imagist 10y ago
      > 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?
- kazinator 10y ago
  > 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.
  - qwertyuiop924 10y ago
    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.
  - imagist 10y ago
    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.
lispm 10y ago
> 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.
- qwertyuiop924 10y ago
  And your definition of what makes a Lisp is pretty strange. For one thing, Racket and Scheme are definitely in the lisp family.
  - lispm 10y ago
    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 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.
    - qwertyuiop924 10y ago
      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.