4 ms·

> (And yes, despite what the Common Lisp community has to say, Janet is a lisp, even if it’s not a Lisp) I love this and understand both the sentiment expresse

> (And yes, despite what the Common Lisp community has to say, Janet is a lisp, even if it’s not a Lisp) I love this and understand both the sentiment expressed and (as a recovering member of the Cult Of Lisp) the reason why it was said.

didibus 5y ago
I've tried to check why it was said by the CL folks, but I'm only seeing that they feel it's not a Lisp because it lacks cons cells, which I find a very weak argument, since cons cells are an implementation detail in my mind. The syntax and semantics are clearly similar to that of Lisps before it, and so is the feature set enabled by that very same syntax and the very same semantics. In that sense if Janet had to be the dialect of something else, I don't see what else but being a dialect of Lisp it could be. And I don't think Janet is different enough in syntax and semantics to be given its own new family of language. Anyways, those debate are kind of for fun and games, cause it doesn't really matter, but I think the description you could give to someone else who's asking: What's it like? And if you say, it's a bit like programming in any other Lisp, well you'd be giving them a pretty good idea of what it was like, unless they'd never programmed in any other Lisp either, then you're going to struggle, because there's not a whole lot like Lisp.
- zdragnar 5y ago
  It's all in the name- lisp : LISt Processing. That said, I am not such a purist as to be bothered by it, and janet has a special place in my heart right along with chicken, racket, clojure and CL.
  - didibus 5y ago
    What's a list though? Why should it refer specifically to the concrete implementation? Lists in a conceptual sense are an ordered collection of heterogeneous elements with nestings. In that sense, code in Janet is very much represented as such and processed as such. Which in my mind makes it a LISt Processing language :p
    - lispm 5y ago
      Lisp is does not stand for generic 'List Processing', but for 'List Processor' -> a specific formalism to process lists. There is a specific minimal core of Lisp, which consists of a certain minimal set of data structures, operations and an evaluation mechanism. An early version is described here: https://dspace.mit.edu/bitstream/handle/1721.1/6096/AIM-008.pdf https://dspace.mit.edu/bitstream/handle/1721.1/6096/AIM-008.... Another one is described here: https://www.ee.ryerson.ca/~elf/pub/misc/micromanualLISP.pdf https://www.ee.ryerson.ca/~elf/pub/misc/micromanualLISP.pdf
      - yumaikas 5y ago
        That is true, but to engage in a bit of semiotics: those cores are hardly the most appealing part of Lisp for most of the uses cases it's found. It certainly was one way to enable the interactivity and homoiconicty and metacircularity, but, as Clojure and Janet demonstrate, there are a lot of other aspects of Lisp that have value. And while one could (and some have, IIRC) built a Lisp on those minimal data structures that doesn't have parens, most people associate Lips with them being in the strange place. Cons/car/cdr are far less important, IMO, than eval. Read, on the other hand, is also technically missing from Janet, and I personally don't mind a great deal, but I could see that being argued.
        deleted 5y ago
        [deleted]
        lispm 5y ago
        One of the inventions of McCarthy (and team) was that EVAL can be defined in the core language itself (!) and thus serve as a relatively simple model of computation. Thus the particular EVAL is important, not that source code can be executed at runtime by some api call to execute code. That's part of the core of the language. Sure: Many other aspects from Lisp can be found also in Lisp-derived languages and other languages. Like all or some of runtime code loading, symbolic expressions, using symbolic expressions to encode source code, saving and starting heap images, garbage collection, managed memory, source level interpreters/debuggers, self-hosted compilers, read-eval-print-loops, macros, fexprs, integrated interactive development environments, ...
- deleted 5y ago
  [deleted]
yumaikas 5y ago
What's funny is that I came up with a half-decent acronym this morning: PAST. Paren AST languages. But this article has been sitting in a draft for the better part of a month, lol.
Decabytes 5y ago
I mean Racket is a Lisp, but the new syntax they are going for with the Rhombus project is based on Shrubbery notation. Which doesn’t have all the parenthesis

didibus 5y ago

I've tried to check why it was said by the CL folks, but I'm only seeing that they feel it's not a Lisp because it lacks cons cells, which I find a very weak argument, since cons cells are an implementation detail in my mind. The syntax and semantics are clearly similar to that of Lisps before it, and so is the feature set enabled by that very same syntax and the very same semantics. In that sense if Janet had to be the dialect of something else, I don't see what else but being a dialect of Lisp it could be. And I don't think Janet is different enough in syntax and semantics to be given its own new family of language. Anyways, those debate are kind of for fun and games, cause it doesn't really matter, but I think the description you could give to someone else who's asking: What's it like? And if you say, it's a bit like programming in any other Lisp, well you'd be giving them a pretty good idea of what it was like, unless they'd never programmed in any other Lisp either, then you're going to struggle, because there's not a whole lot like Lisp.

zdragnar 5y ago
It's all in the name- lisp : LISt Processing. That said, I am not such a purist as to be bothered by it, and janet has a special place in my heart right along with chicken, racket, clojure and CL.
- didibus 5y ago
  What's a list though? Why should it refer specifically to the concrete implementation? Lists in a conceptual sense are an ordered collection of heterogeneous elements with nestings. In that sense, code in Janet is very much represented as such and processed as such. Which in my mind makes it a LISt Processing language :p
  - lispm 5y ago
    Lisp is does not stand for generic 'List Processing', but for 'List Processor' -> a specific formalism to process lists. There is a specific minimal core of Lisp, which consists of a certain minimal set of data structures, operations and an evaluation mechanism. An early version is described here: https://dspace.mit.edu/bitstream/handle/1721.1/6096/AIM-008.pdf https://dspace.mit.edu/bitstream/handle/1721.1/6096/AIM-008.... Another one is described here: https://www.ee.ryerson.ca/~elf/pub/misc/micromanualLISP.pdf https://www.ee.ryerson.ca/~elf/pub/misc/micromanualLISP.pdf
    - yumaikas 5y ago
      That is true, but to engage in a bit of semiotics: those cores are hardly the most appealing part of Lisp for most of the uses cases it's found. It certainly was one way to enable the interactivity and homoiconicty and metacircularity, but, as Clojure and Janet demonstrate, there are a lot of other aspects of Lisp that have value. And while one could (and some have, IIRC) built a Lisp on those minimal data structures that doesn't have parens, most people associate Lips with them being in the strange place. Cons/car/cdr are far less important, IMO, than eval. Read, on the other hand, is also technically missing from Janet, and I personally don't mind a great deal, but I could see that being argued.
      - deleted 5y ago
        [deleted]
      - lispm 5y ago
        One of the inventions of McCarthy (and team) was that EVAL can be defined in the core language itself (!) and thus serve as a relatively simple model of computation. Thus the particular EVAL is important, not that source code can be executed at runtime by some api call to execute code. That's part of the core of the language. Sure: Many other aspects from Lisp can be found also in Lisp-derived languages and other languages. Like all or some of runtime code loading, symbolic expressions, using symbolic expressions to encode source code, saving and starting heap images, garbage collection, managed memory, source level interpreters/debuggers, self-hosted compilers, read-eval-print-loops, macros, fexprs, integrated interactive development environments, ...
deleted 5y ago
[deleted]

yumaikas 5y ago

What's funny is that I came up with a half-decent acronym this morning: PAST. Paren AST languages. But this article has been sitting in a draft for the better part of a month, lol.

Decabytes 5y ago

I mean Racket is a Lisp, but the new syntax they are going for with the Rhombus project is based on Shrubbery notation. Which doesn’t have all the parenthesis