9 ms·

I write Lisp professionally and love s-expressions, but the comparison with ALTER TABLE's grammar is pretty unfair. Postgres can detect many invalid ALTER TABLE

by tsm 3y ago

I write Lisp professionally and love s-expressions, but the comparison with ALTER TABLE's grammar is pretty unfair. Postgres can detect many invalid ALTER TABLE formulations by checking the grammar, whereas in Lisp it's much easier to have grammatically-correct but semantically-wrong formulations. A major saving grace here (which was not covered in the section on macros) is that you can write clever macros that do appropriate checking at macroexpansion time, not runtime. This lets you use Lisp to write checkers for your Lisp code, which gives you a Turing-complete language you already know to do the checking instead of the (formally and practically) more limited checking of a grammar.

gostsamo 3y ago
Can you share where do you use lisp? I'm curious what are its niches nowadays.
- agumonkey 3y ago
  clojurians seems to still be active and somehow numerous, datascience subgroups held regular online meetups not long ago. some would say clojure is not true-lisp but well.
  - kgwxd 3y ago
    I’ve seen people saying that but never with an argument as to why. What do they mean?
    - nordsieck 3y ago
      > I’ve seen people saying that but never with an argument as to why. What do they mean? I don't know but if I had to guess, it's because lisp is list processing language, and Clojure doesn't really support lists (I mean, it's possible to make some, but there are none out of the box); instead it has a variety of trees that mimic the runtime performance of lists, arrays, hashes, etc.
      - deleted 3y ago
        [deleted]
      - kgwxd 3y ago
        I’m not sure I understand how there are no lists out of the box in Clojure. What makes the data structures not valid lists? Basic lisp lists are nestable, doesn’t that make them trees? The underlying structure is to support immutability by default but that’s under the hood stuff. Conceptually and, I think more importantly, syntactically they’re list.
        nordsieck 3y ago
        I'm probably the wrong person to have this conversation with - I agree with you for the most part, and I think Clojure is a lisp. My guess was the only thing that I could really think of. That and the syntax support and integration of non-list datatypes into the core language (e.g. function syntax).
        cfiggers 3y ago
        AFAIU, "list" has a specific technical meaning when used by someone complaining about Clojure not having them. It has to do with the implementation details, not just the semantics of how they're used. Clojure has "sequences" or "seqs", which are semantically the closest to what lispers mean by a "list"—but also "vectors," denoted by square brackets, "maps," denoted by curly brackets, and "sets", denoted by curly brackets prefixed with a hash sign. Having these as core data structures violates the Lisp principle of "everything is just a list," and they introduce something other than round parens into the syntax, which looks really weird to those practiced with traditional/conventional Lisps. For those well-practiced in "true" Lisps, Clojure reads like a very strange hybrid (one might say "corruption") of Lisp and JSON.
        robto 3y ago
        When lispers talk about lists, they are usually speaking about a very specific type of data structure - a linked list of cons cells[0]. Clojure's lists are not actual chains of cons, they are immutable hash array map tries. This means that Common Lisp code can't interoperate with Clojure code. The precise/pedantic lisper may insist that since Lisp stands for List Processing and Lists are chains of cons cells and since Clojure doesn't have cons cells for the built-in lists, then Clojure is not a Lisp. If, however, you view lisp (lower case) as a family of homo-iconic languages that use s-expressions, then Clojure happily fits under that umbrella. The trick is to pay close attention to whether the person is talking about a Lisp (ANSI Common Lisp implementation) or a lisp (the family). Sometimes people say "lisp" when they are talking about "Lisp", which can cause some confusion. [0]https://en.wikipedia.org/wiki/Cons https://en.wikipedia.org/wiki/Cons
    - giancarlostoro 3y ago
      My understanding is that Clojure is meant to be Scheme like, but it is not fully compliant to a Scheme spec, my only guess is due to JVM specific nuances, but I could be wrong. It has been some time since I last dived into Clojure specifics. I will say though, that side from Racket, I think Clojure is top notch, although it seems a lot of my favorite projects from a few years ago have been abandoned. One of my favorite things with Clojure is using the REPL to build a GUI using JVM libraries.
      - thesuperbigfrog 3y ago
        >> My understanding is that Clojure is meant to be Scheme like, but it is not fully compliant to a Scheme spec, my only guess is due to JVM specific nuances, but I could be wrong. Clojure's syntax and semantics are quite different from Scheme and Common Lisp: https://clojure.org/reference/lisps https://clojure.org/reference/lisps https://www.more-magic.net/posts/thoughts-on-clojure.html https://www.more-magic.net/posts/thoughts-on-clojure.html Most differences are due to design choices, not merely JVM nuances. A few differences are due to JVM limitations at the time that Clojure was designed. I don't think any attempt was made to comply with a Scheme spec.
        giancarlostoro 3y ago
        Good to know, thank you! I have only done a small amount of Clojure and Racket.
    - agumonkey 3y ago
      It's a slight cultural shift, rich hickey probably tried to modernize/homogenize things sensibly, adding a few literals for vectors, maps and sets (a very interesting idea ergonomics wise, i'm 80% for it personally, having easy data notation is such a bliss), and some underlying changes (immutable DS first) which makes clojure feel different than lisps/CL/scheme.
    - rawoke083600 3y ago
      I'm sure it matters for purist (valid concern), language designers and "lisp-power-users (sic ?)" I do feel however like that statement is kind a like a "tomato is a fruit" statement. Technically true but for the vast (again not all) amount of tomato users does it really matter ?
    - mikelevins 3y ago
      There are some other explanations given in sibling comments. They may be right, but there's another point that may also explain some of this sentiment. In Common Lisp and its antecedents, a "list" is a chain of cons cells, as mentioned by some of the sibling comments, but that's not all. Another important point is that in Common Lisp and its antecedents, source code is not made of text strings; it's made of Lisp data structures--atoms and chains of cons cells. A text file containing "Common Lisp source code" does not actually contain Common Lisp source code. It contains a text serialization of Common Lisp source code (one of many possible text serializations, actually). It isn't actually Common Lisp source code until the reader gets done with it. This might sound like a trivial pedantic point, but it isn't. Because Common Lisp source code is made up of standard Common Lisp data types, its standard library provides everything you need to walk arbitrary source code, deconstruct it, transform it, construct it, and compile it. Those features are all built into the language in a way that they are not in most languages. For those of us who are accustomed to using those features regularly, working with a language that lacks them is such an impoverished experience that I can understand folks objecting that "that's not a proper Lisp." I don't tend to make that objection myself, but I do understand it. If your Lisp does not represent its source code in this way, or if it doesn't even have the data structures that source code is made of in Common Lisp and its antecedents, then there is a nontrivial sense in which it's not a Lisp--or at least not the kind of Lisp that those older ones are.
      - eduction 3y ago
        >In Common Lisp and its antecedents, a "list" is a chain of cons cells, as mentioned by some of the sibling comments, but that's not all. Another important point is that in Common Lisp and its antecedents, source code is not made of text strings; it's made of Lisp data structures--atoms and chains of cons cells. Source code in Clojure is also not made of text strings, it also reads text as the serialization of data structures, which are then interpreted as source. The difference is, Clojure uses data structures other than cons cells for source. What do you see as particularly important about cons cells? What advantages do they give what some might call a "real LISP" over Clojure, which, I'd argue, smartly abstracts around more modern data structures like vectors, maps, sequences, collections as opposed to being "married" to cons cells as Rich Hickey once put it?
  - kaliszad 3y ago
    Clojure and ClojureScript communities are thriving. Our product, orgpad.com is written completely in those two. I have written about some of the technologies we use before.
- deleted 3y ago
  [deleted]
- smcn 3y ago
  We use it for stock market analysis over at https://feetr.io https://feetr.io. Honestly, I couldn't imagine a better language as it makes large tasks almost effortless. Plus the fact that I can connect to the running image and query data feels like magic and makes farming content for social media almost facile as I can pipe some of the data through cl-table and just post a screenshot.
  - zetalyrae 3y ago
    What's the scale of the codebase, in kilolines of code? Do you find the dynamic typing to be a problem at scale?
    - smcn 3y ago
      `cloc` has it at 24k lines of code so it's by no means a huge project but it's big enough where I feel like we would have encountered a large variety of issues. As of yet there hasn't been anything major. We have felt the lack of libraries at times but that just means we need to write more lisp, which is a good thing as lisp is fun. Honestly, I don't know that I'd classify our use of CL as dynamic. We're happy customers of `deftype` and `declaim`. While it's true that not every function makes use of them, most of them do. So in that regard, I can't comment but that's the beauty of lisp: it's the language that you need it to be.
  - belmarca 3y ago
    Are you guys hiring?
    - smcn 3y ago
      We aren't currently, no, sorry. However, I'll reach out when that changes!
      - belmarca 3y ago
        Ok great!
  - 3y ago
nerdponx 3y ago
I think of specialized language syntax on a spectrum similar to "Dynamic types <-> Static types". Very general syntax like S-expressions provides you maximum flexibility, but the minimum amount of guidance on semantics and protection against mistakes, along with the opportunity for nicer, more-detailed error messages.
- reikonomusha 3y ago
  I don't agree. One can write a serious, syntactically bullet-proof grammar for a language built out of S-expressions, with nice error messages and all. We can imagine a parallel universe in which TFA's Postgres example were written using S-expressions: <alter> := (ALTER-TABLE (:IF-EXISTS? :ONLY?) <symbol> :*? <action>+) | ... <action> := ... Despite using S-expressions, this is parseable with as much rigor as more free-form character syntax. I think Coalton [1] is a good example of this. The language is embedded as S-expressions in Common Lisp, but you get Rust-like error messages, showing exact source lines (with line numbers) and embedded underlines showing the location of the offending code. With that said, what is true is that if you're using Common-Lisp-style macros and you're manipulating S-expressions programmatically, lexical information may get thrown out. This is not unlike doing a bunch of string manipulation in an ORM to generate SQL, which will have similarly poor error messages. [1] https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
datagram 3y ago
I don't think the article is necessarily claiming that specific syntaxes like SQL are bad. I think they just wanted to highlight how different the languages are.
7thaccount 3y ago
What kind of work do you do? I occasionally daydream about working in something like APL/q, Forth, or Lisp.
- tsm 3y ago
  I write Clojure for https://www.metabase.com/ https://www.metabase.com/ Lots of interesting problems involving working with different database engines, processing data, compiler design, etc.
  - 7thaccount 3y ago
    That sounds super cool!

by tsm 3y ago

gostsamo 3y ago

Can you share where do you use lisp? I'm curious what are its niches nowadays.

agumonkey 3y ago
clojurians seems to still be active and somehow numerous, datascience subgroups held regular online meetups not long ago. some would say clojure is not true-lisp but well.
- kgwxd 3y ago
  I’ve seen people saying that but never with an argument as to why. What do they mean?
  - nordsieck 3y ago
    > I’ve seen people saying that but never with an argument as to why. What do they mean? I don't know but if I had to guess, it's because lisp is list processing language, and Clojure doesn't really support lists (I mean, it's possible to make some, but there are none out of the box); instead it has a variety of trees that mimic the runtime performance of lists, arrays, hashes, etc.
    - deleted 3y ago
      [deleted]
    - kgwxd 3y ago
      I’m not sure I understand how there are no lists out of the box in Clojure. What makes the data structures not valid lists? Basic lisp lists are nestable, doesn’t that make them trees? The underlying structure is to support immutability by default but that’s under the hood stuff. Conceptually and, I think more importantly, syntactically they’re list.
      - nordsieck 3y ago
        I'm probably the wrong person to have this conversation with - I agree with you for the most part, and I think Clojure is a lisp. My guess was the only thing that I could really think of. That and the syntax support and integration of non-list datatypes into the core language (e.g. function syntax).
      - cfiggers 3y ago
        AFAIU, "list" has a specific technical meaning when used by someone complaining about Clojure not having them. It has to do with the implementation details, not just the semantics of how they're used. Clojure has "sequences" or "seqs", which are semantically the closest to what lispers mean by a "list"—but also "vectors," denoted by square brackets, "maps," denoted by curly brackets, and "sets", denoted by curly brackets prefixed with a hash sign. Having these as core data structures violates the Lisp principle of "everything is just a list," and they introduce something other than round parens into the syntax, which looks really weird to those practiced with traditional/conventional Lisps. For those well-practiced in "true" Lisps, Clojure reads like a very strange hybrid (one might say "corruption") of Lisp and JSON.
      - robto 3y ago
        When lispers talk about lists, they are usually speaking about a very specific type of data structure - a linked list of cons cells[0]. Clojure's lists are not actual chains of cons, they are immutable hash array map tries. This means that Common Lisp code can't interoperate with Clojure code. The precise/pedantic lisper may insist that since Lisp stands for List Processing and Lists are chains of cons cells and since Clojure doesn't have cons cells for the built-in lists, then Clojure is not a Lisp. If, however, you view lisp (lower case) as a family of homo-iconic languages that use s-expressions, then Clojure happily fits under that umbrella. The trick is to pay close attention to whether the person is talking about a Lisp (ANSI Common Lisp implementation) or a lisp (the family). Sometimes people say "lisp" when they are talking about "Lisp", which can cause some confusion. [0]https://en.wikipedia.org/wiki/Cons https://en.wikipedia.org/wiki/Cons
  - giancarlostoro 3y ago
    My understanding is that Clojure is meant to be Scheme like, but it is not fully compliant to a Scheme spec, my only guess is due to JVM specific nuances, but I could be wrong. It has been some time since I last dived into Clojure specifics. I will say though, that side from Racket, I think Clojure is top notch, although it seems a lot of my favorite projects from a few years ago have been abandoned. One of my favorite things with Clojure is using the REPL to build a GUI using JVM libraries.
    - thesuperbigfrog 3y ago
      >> My understanding is that Clojure is meant to be Scheme like, but it is not fully compliant to a Scheme spec, my only guess is due to JVM specific nuances, but I could be wrong. Clojure's syntax and semantics are quite different from Scheme and Common Lisp: https://clojure.org/reference/lisps https://clojure.org/reference/lisps https://www.more-magic.net/posts/thoughts-on-clojure.html https://www.more-magic.net/posts/thoughts-on-clojure.html Most differences are due to design choices, not merely JVM nuances. A few differences are due to JVM limitations at the time that Clojure was designed. I don't think any attempt was made to comply with a Scheme spec.
      - giancarlostoro 3y ago
        Good to know, thank you! I have only done a small amount of Clojure and Racket.
  - agumonkey 3y ago
    It's a slight cultural shift, rich hickey probably tried to modernize/homogenize things sensibly, adding a few literals for vectors, maps and sets (a very interesting idea ergonomics wise, i'm 80% for it personally, having easy data notation is such a bliss), and some underlying changes (immutable DS first) which makes clojure feel different than lisps/CL/scheme.
  - rawoke083600 3y ago
    I'm sure it matters for purist (valid concern), language designers and "lisp-power-users (sic ?)" I do feel however like that statement is kind a like a "tomato is a fruit" statement. Technically true but for the vast (again not all) amount of tomato users does it really matter ?
  - mikelevins 3y ago
    There are some other explanations given in sibling comments. They may be right, but there's another point that may also explain some of this sentiment. In Common Lisp and its antecedents, a "list" is a chain of cons cells, as mentioned by some of the sibling comments, but that's not all. Another important point is that in Common Lisp and its antecedents, source code is not made of text strings; it's made of Lisp data structures--atoms and chains of cons cells. A text file containing "Common Lisp source code" does not actually contain Common Lisp source code. It contains a text serialization of Common Lisp source code (one of many possible text serializations, actually). It isn't actually Common Lisp source code until the reader gets done with it. This might sound like a trivial pedantic point, but it isn't. Because Common Lisp source code is made up of standard Common Lisp data types, its standard library provides everything you need to walk arbitrary source code, deconstruct it, transform it, construct it, and compile it. Those features are all built into the language in a way that they are not in most languages. For those of us who are accustomed to using those features regularly, working with a language that lacks them is such an impoverished experience that I can understand folks objecting that "that's not a proper Lisp." I don't tend to make that objection myself, but I do understand it. If your Lisp does not represent its source code in this way, or if it doesn't even have the data structures that source code is made of in Common Lisp and its antecedents, then there is a nontrivial sense in which it's not a Lisp--or at least not the kind of Lisp that those older ones are.
    - eduction 3y ago
      >In Common Lisp and its antecedents, a "list" is a chain of cons cells, as mentioned by some of the sibling comments, but that's not all. Another important point is that in Common Lisp and its antecedents, source code is not made of text strings; it's made of Lisp data structures--atoms and chains of cons cells. Source code in Clojure is also not made of text strings, it also reads text as the serialization of data structures, which are then interpreted as source. The difference is, Clojure uses data structures other than cons cells for source. What do you see as particularly important about cons cells? What advantages do they give what some might call a "real LISP" over Clojure, which, I'd argue, smartly abstracts around more modern data structures like vectors, maps, sequences, collections as opposed to being "married" to cons cells as Rich Hickey once put it?
- kaliszad 3y ago
  Clojure and ClojureScript communities are thriving. Our product, orgpad.com is written completely in those two. I have written about some of the technologies we use before.
deleted 3y ago
[deleted]
smcn 3y ago
We use it for stock market analysis over at https://feetr.io https://feetr.io. Honestly, I couldn't imagine a better language as it makes large tasks almost effortless. Plus the fact that I can connect to the running image and query data feels like magic and makes farming content for social media almost facile as I can pipe some of the data through cl-table and just post a screenshot.
- zetalyrae 3y ago
  What's the scale of the codebase, in kilolines of code? Do you find the dynamic typing to be a problem at scale?
  - smcn 3y ago
    `cloc` has it at 24k lines of code so it's by no means a huge project but it's big enough where I feel like we would have encountered a large variety of issues. As of yet there hasn't been anything major. We have felt the lack of libraries at times but that just means we need to write more lisp, which is a good thing as lisp is fun. Honestly, I don't know that I'd classify our use of CL as dynamic. We're happy customers of `deftype` and `declaim`. While it's true that not every function makes use of them, most of them do. So in that regard, I can't comment but that's the beauty of lisp: it's the language that you need it to be.
- belmarca 3y ago
  Are you guys hiring?
  - smcn 3y ago
    We aren't currently, no, sorry. However, I'll reach out when that changes!
    - belmarca 3y ago
      Ok great!
- 3y ago

nerdponx 3y ago

I think of specialized language syntax on a spectrum similar to "Dynamic types <-> Static types". Very general syntax like S-expressions provides you maximum flexibility, but the minimum amount of guidance on semantics and protection against mistakes, along with the opportunity for nicer, more-detailed error messages.

reikonomusha 3y ago
I don't agree. One can write a serious, syntactically bullet-proof grammar for a language built out of S-expressions, with nice error messages and all. We can imagine a parallel universe in which TFA's Postgres example were written using S-expressions: <alter> := (ALTER-TABLE (:IF-EXISTS? :ONLY?) <symbol> :*? <action>+) | ... <action> := ... Despite using S-expressions, this is parseable with as much rigor as more free-form character syntax. I think Coalton [1] is a good example of this. The language is embedded as S-expressions in Common Lisp, but you get Rust-like error messages, showing exact source lines (with line numbers) and embedded underlines showing the location of the offending code. With that said, what is true is that if you're using Common-Lisp-style macros and you're manipulating S-expressions programmatically, lexical information may get thrown out. This is not unlike doing a bunch of string manipulation in an ORM to generate SQL, which will have similarly poor error messages. [1] https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton

datagram 3y ago

I don't think the article is necessarily claiming that specific syntaxes like SQL are bad. I think they just wanted to highlight how different the languages are.

7thaccount 3y ago

What kind of work do you do? I occasionally daydream about working in something like APL/q, Forth, or Lisp.

tsm 3y ago
I write Clojure for https://www.metabase.com/ https://www.metabase.com/ Lots of interesting problems involving working with different database engines, processing data, compiler design, etc.
- 7thaccount 3y ago
  That sounds super cool!