I do not understand the appeal of non-LISPy languages. I get that most people are used to reading it and that they are efficent, but I believe the developer (of the compiler in this case) should serve the convenience of the user, not the other way around.

Writing code like this is combersome and unnecessarily symbol heavy, and reading it isn't really nice as well.

I'd rather have the language add those extra parens into the parser than have me stare down these endless semi-colon, linebreaks or indentation. Parsing something Lisp-like is not that, hard, trust me, I've done it.

Let's be real in most situations it doesn't matter. One "statement" per line is bog standard. Whether that statement is surrounded by parens or ended in a semicolon isn't impactful for reading.

LISP is only better when you add source code transformation (which is way easier with its source code looking like the transformed code). But then you introduce "everyone can write their own syntax" which is good and bad given the history of DSLs...

When writing code you are transforming it all the time. Having only expressions (mostly) comes in very handily. It is called structured editing of code.

> One "statement" per line is bog standard

This isn't really true. Most non-Lisp languages I work in, like JS or Ruby or Python, have things like long_expression =\n long_other_expression, or long_expression\n.another_long_expression\n.another_long_expression.

And if most of your code looks like that you are making a mistake.

"Sometimes I need multiple lines" is fine, exceptions happen.

But again I ask, visually are those lines super different?

Ditto for things like for loops which have multiple statements in a line.

This doesn't really resonate with people though, as most people are more familiar with C-style notation. Also:

>Writing code like this is combersome and unnecessarily symbol heavy

Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily.

>Does not make sense in this context, as it mainly applies to Lisp-like languages that uses parentheses heavily.

I had read, some years back, that someone did an actual calculation / demonstration that showed that the number of symbol / punctuation characters in Lisp is actually less than in C-based languages, for a block of code with equal functionality in both languages.

I don't have the reference handy. Someone here may know of it, and post it.

It's obvious to anyone who is familiar with both.

    (f x y)

vs

    f(x, y);

Note the extra comma and semicolon. The only place this breaks down is for simple arithmetic expressions like (+ a b) vs a + b, which is trivial enough to ignore (and also goes back in favor of Lisp when you start having more operands).

As someone who likes lisps, visual separation is helpful. I tend to find complicated Lisp code just blends together into syntax soup

It is only function calling that needs (,); in C and () in Lisp. Which is half as many characters, but much much much noisy since:

    - it is used everywhere
    - carries very little information

Look at the example on the Janet page transcribed to Python syntax [0]. Several differences:

    - in Janet nearly every line starts and ends with ( and ), which is just noise
    - in Janet there are several ))))
    - in Janet there is no special syntax for: function definition, variable definition, collections, statements
    - while Python is the opposite, it reads like a mix of English and Mathematics. Also it has special syntax for the ~5 things that you can do with the language, so you can just look at the Python code from far, don't read it, and you'll have a clue what's going on. It is also helpful when you search for something with your eyes. Also nested parentheses are different shaped parentheses, so you know which ones match.

Also in theory you could manipulate Python AST the same way you do in Lisps both in your editor and both at program-level. In practice you can't do that.

[0] : https://news.ycombinator.com/item?id=34846516

Ok, let's compare looping

    for (int i = 0; i < 5; i++) {
        printf("%d\n", i);
    }

vs

    (loop for i from 0 below 5
          do (format t "~A~%" i))

C has the same number of parentheses and also has curly brackets. C additionally has a bunch of semicolons and a comma not present in the Lisp version. The C version is also omitting the required function encapsulation to actually run this, while the Lisp version can be run as a top level expression.

The comparison really isn't even close. If you really want, you can always put the trailing )) on new lines like people do with the trailing }}}} for their nested if in a for in a method in a class in C-like languages. The Lisp community has just decided that putting single characters on new lines like that is needlessly noisy and emphasizes characters that are easily ignored by humans and instead manipulated using structural editing.

> The comparison really isn't even close.

IMO it's close. Lisp isn't much worse than other languages. Tho it needs special syntax for some common constructs. It helps the human.

Regarding the for loop, if you only loop one statement, you do

    for (int i = 0; i < 5; i++) printf("%d\n", i);

If you loop several statements, you do

  (loop for i from 0 below 5
        do (progn
           (format t "~A~%" i)
           (format t "~A~%" i)))

again, lisp lacks the syntax to group several statements together. In C it ends with );} , indicating a function call inside a control flow or a block. In lisp ))) can be anything from function definition to assigning variables or arrays/collections or anything.

How would you write this in Lisp without introducing a bunch of parens? `if (0 <= x + m && x + m <= n) {…}`

I’m not a Lisp hater, but there’s a reason people make this criticism. I think most people find the infix version easier to read.

    (if (<= 0 (+ x m) n) ...)

There is one additional set of parentheses due to the simple addition, which I already mentioned.

I unwittingly chose an example that allowed you to write fewer s-expressions in Lisp… touché.

I've been working on this for TXR Lisp. The next, release 300, will support infix.

The core expression in your example expression will parse as you have written it. Except we have to add ifx:

  1> (ifx (if (0 <= x + m && x + m <= n) (prinl 'do-this)))
  ** expr-1:1: warning: unbound variable x
  ** expr-1:1: warning: unbound variable m
  ** expr-1:1: warning: unbound variable x
  ** expr-1:1: warning: unbound variable m
  ** expr-1:1: warning: unbound variable n
  ** expr-1:1: unbound variable x

Though it doesn't work since it's not a complete example with defined variables, we can quote it and expand it to see what the expansion looks like, which answers your question of how you write it one underlying Lisp:

  1> (expand '(ifx (if (0 <= x + m && x + m <= n) (prinl 'do-this))))
  (if (and (<= 0 (+ x m))
        (<= (+ x m) n))
    (prinl 'do-this))

The ifx macro deosn't have to be used for every expression. Inside ifx, infix expressions are detected at any nesting depth. You can put it around an entire file:

  (ifx
    (defstruct user ()
      id name)

    (defun add (x y) (x + y))

    ...)

Autodetection of infix add some complexity and overhead to the code walking process that expands macros (not to mention that it's newly introduced) so we wouldn't want to have it globally enabled everywhere, all the time.

It's a compromise; infix syntax in the context of Lisp is just something we can support for a specific benefit in specific use case scenarios. It's mainly for our colleagues who find it a barrier not to be able to use infix.

In this particular infix implementation, a full infix expression not contained inside another infix expression is still parenthesized (because it is a compound form, represented as a list). You can see from the following large exmaple that it still looks like LIsp; it is a compromise.

I took an example FFT routine from the book Numerical Recipes in C and transliterated it, to get a feel for what it's like to write a realistic numerical routine that contains imperative programming "warts" like using assignments to initialize variables and such:

  (defun fft (data nn isign)
    (ifx
      (let (n nmax m j istep i
            wtemp wpr wpi wr wi theta
            tempr tempi)
        (n := nn << 1)
        (j := 1)
        (for ((i 1)) ((i < n)) ((i += 2))
          (when (j > i)
            (swap (data[j]) (data[i]))
            (swap (data[j + 1]) (data[i + 1])))
          (m := nn)
          (while (m >= 2 && j > m)
            (j -= m)
            (m >>= 1))
          (j += m))
        (nmax := 2)
        (while (n > nmax)
          (istep := nmax << 1)
          (theta := isign * ((2 * %pi%) / nmax))
          (wtemp := sin 0.5 * theta)
          (wpr := - 2.0 * wtemp * wtemp)
          (wpi := sin theta)
          (wr := 1.0)
          (wi := 0.0)
          (for ((m 1)) ((m < nmax)) ((m += 2))
            (for ((i m)) ((i <= n)) ((i += istep))
              (j := i + nmax)
              (tempr := wr * data[j] - wi * data[j + 1])
              (tempi := wr * data[j + 1] + wi * data[j])
              (data[j] := data[i] - tempr)
              (data[j + 1] := data[i + 1] - tempi)
              (data[i] += tempr)
              (data[i + 1] += tempi))
            (wr := (wtemp := wr) * wpr - wi * wpi + wr)
            (wi := wi * wpr + wtemp * wpi + wi))
          (nmax := istep)))))

It was very easy to transliterate the C code into the above, because of the infix. The remaining outer parentheses are trivial.

A smaller example is a quadratic roots calculation, from the test suite. This one has the ifx outside the defun:

  (ifx
    (defun quadratic-roots (a b c)
      (let ((d (sqrt b * b - 4 * a * c)))
        (list ((- b + d) / 2 * a)
              ((- b - d) / 2 * a)))))

sqrt is a function, but treated as a prefix operator with a low precedence so parentheses are not required.

I never got people’s objections to the parentheses when the bottom of most js/ts files is a soup of three different flavors of closing bracket. Even more “fun” in languages like PHP that make you sprinkle ceremonial semicolons into some parts to satisfy the compiler. Hunting for the right brace is tedious, whereas in a lisp I just bounce on close paren til the open paren highlight is where I want it.

Yeah was going to change that part too for something like "Writing code like this is verbose and spans too many lines", but then I just thought it'd be better if it sounded more like the parent comment.

And I understand it doesn't resonate with most, I just wanted to highlight how the initial parent comment was very subjective and not very substantive, some people didn't take the joke so well, I guess it could've sounded a bit passive aggressive. I personally enjoy both C-like and Lisp-like syntaxes and languages, I do have a sweet spot for Forth tho.

But back on topic, Fennel is a great language, working with Love and Fennel is really nice. And if the parentheses can seem off-putting for some, I'd highly encourage to give it a shot as you can quickly get past it and see how comfy it feels to have your statements properly demarkated.

S-expr shine the most when working with XML-like structure. Spinneret[1] was the most fun I ever had working with HTML, every other templating engine feels subpar now that I have tasted that sweet nectar..

[1] https://github.com/ruricolist/spinneret

It's your comment that seems to add the least, because the majority agree with the OP. The point is that ergonomics is not as good, of course there are contrary opinions. The existence of a contrary and minority opinion doesn't detract from the point.

>> as it mainly applies to Lisp-like languages that uses parentheses heavily.

This is so wrong. Lisp does not use parentheses heavily. It doesent even use more parens than any C like language. I just dont understand the fixation with parentheses. The power of lisps comes from the fact that everything is an expression. Someone can correct me if I am wrong, since I only have experience with functional lisp Clojure, but I believe other lisps are more or less similar.

So if everything can be evaluated, then you can have a really great REPL experience. You can be inside your favorite editor and have the tightest feedback loop possible. So the absence of statements is actually a great feature of the language which improves ergonomics.

The anti parentheses argument is usually just a straw that people grasp, who have no experience with writing code in lispy languages. A quick superficial jab at something they do not know well, so that they can go on with their day, without having to deal with learning a new thing, that might change their whole view of programming.

Plus, don't forget the secret sauce of Lisp syntax: same number of parentheses, with none of the commas. Nor the semicolons. Nor the brackets. Nor the braces.

I can live with brackets and braces tho ;) Clojure <3 But that is a very nice observation that is true for traditional lisps. I need to give racket or scheme one more look.

I just don't understand the fixation with REPL. How do you use it? It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.

> It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.

That doesn't even make any remote sense. "I don't get the fixation with the JVM. It sounds like you write code as a black box, then compile and run it to see what it does because you don't understand it by yourself."

> I just don't understand the fixation with REPL

Perhaps because maybe you just haven't used one? I'm not talking about "a REPL" in langs like Python, where you typically have to type stuff into it. Lisp REPLs allow evaluating code directly in the source buffer, by sending it into the REPL. That REPL can be remote. Like seriously remote - NASA once did it on a spacecraft 150 million miles away from Earth. We run ours in a kubernetes cluster. Lisp REPL allows you to evaluate specific expressions, functions, or regions directly from where you are. Without saving, linting, linking, compiling, etc.

> because you don't understand it by yourself.

REPL is not about "understanding your code", it's about interactive development and exploration - it allows you to test your ideas and assumptions in real-time. Imagine being able to send http request, pull some good chunk of data, and then sort it, group it, slice it, dice it, filter it, visualize it - do whatever you want to do with it, directly from your editor. It's incredibly empowering and extremely liberating.

The only downsides - after getting used to that, using non-lispy languages sucks all the joy out of programming and you also have to explain to people what it is like.

It's like moving to an island where people have never discovered salt, pepper, and other spices, and though their cuisine looks beautiful - you just can't describe to them what they all are missing. Some even may say - "Hey, I've tried pepper once - but I don't understand your fixation with it" and you'd be like: "have you ever tried putting it into your food?"

You check assumptions about dynamic types this way? To see what the function even returns in the first place. Browser console has a similar function: you type a function invocation, run it, then the returned value is presented as a tree for inspection.

You can check any assumptions about the code. But it's not exactly like using browser's dev tools console. First — you don't have to type things "somewhere else" — you're doing it right where you're writing code. And it can be a file or a scratch buffer — you don't even have to save those experimental bits. Second — because you have things neatly wrapped into symbolic expressions (those pesky parens that non-lispers find so confusing), you don't need any ceremony for setting up the stage.

take this Javascript example:

    function addFive(x) { return x + 5; }
    

or

    const addFive = (x) => x + 5;

And its counterpart in Clojurescript:

    (defn add-five [x] (+ x 5))

In javascript REPL you can eval the entire thing, but try doing it piecemeal - it makes little sense, i.e., what is (x) or => from js perspective, semantically? While Clojure variant already is a list - a native data-structure, the argument is just a vector - another native thing, etc.

So that infamous code-is-data & data-is-code mantra may not seem like a big deal in a trivial example like this, in practice, it's very nice, it allows you to do things otherwise difficult to achieve, watch this video https://www.youtube.com/watch?v=nEt06LLQaBY and give it a thought, how does one build something like that and how using a Lispy language helps there, while using more traditional PL would make things much more difficult.

<3

Are n4ture and torginus the same person?

Why the exact repeat of the earlier post under a different name or some bots at play here?

It's not an exact repeat.

Stop karma whoring!!

If it is not suspicious then why has the comment been deleted, causing this comment to rise to the top level?

My understanding is that Lisp and most functional languages map very well to PL theory and how compilers and interpreters manipulate programming languages (functions as graphs of code, types as contracts etc.), while procedural languages map well to how CPUs execute programs, and the abstractions operating systems provide (functions as mappable pieces of memory, types as memory or register layouts etc. )

Focusing on the runtime's parser is a red herring and I think a common error in lisp advocacy.

Even if I didn't the full power of a lisp macro system, it is an absolute joy to manipulate programs written in s-expressions. Being able to cut/copy/paste/jump-[forward/back] by sexpr is really convenient, and often done nowhere near as well in other languages. I think this is because until the invention of tree-sitter and LSPs (and the former isn't yet widely adopted in editor tech), most editors had regex-based syntax highlighting and some kind of ad-hoc "parser" for a language. This makes them less aware of the language the developer is editing, but was probably a pragmatic design decision by editor implementers: it's easier than writing a full parser and means the editor can still assist even if a program is syntactically ill-formed.

It does sound interesting, and I'll look into Lisp, can you give me some advice on what's the best way to learn it?

On your other point, I've programmed in many languages in many years, and mostly I did some in an environment with an IDE, or powerful language-specific tooling (not tree-sitter) that had a proper good understanding of the syntax and semantics of the language used.

If you learn better by video than by reading, the Structure and Interpretation of Computer Programs lectures by Abelson and Sussman are spectacular. I have watched the entire course multiple times. The SICP book also receives a lot of praise, but I have yet to read it myself. They specifically use Scheme, but most of the knowledge can be translated to other Lisp dialects as well. The biggest difference between the different Lisp dialects are the macro systems and the standard libraries, so getting started and learning it doesn't really matter which one you choose. GNU Guile or Racket would be easy to use to follow along with SICP though.

Also... HtDP (How to Design Programs) is a good follow-on to SICP.

Oh... and I think we can't mention SICP without referencing this (relatively recent) video about why MIT moved from Scheme to Python for intro classes: https://youtu.be/OgRFOjVzvm0

HtDP was written to address difficulties with learning from SICP https://cs.brown.edu/~sk/Publications/Papers/Published/fffk-...

I have gotten much farther (and accordingly learned more from HtDP). It is accurate to think of it as an on ramp for SICP.

> what's the best way to learn it?

What's the best way to learn programming in general? For me, is to try to build something. Find a problem, pick a Lisp, start building.

Just make sure to have two things: structural editing and the REPL. Without these two, Lisp may feel awkward. But when you have the ability to quickly move any expression around, transpose them, etc., - writing programs becomes like composing haikus or something. You basically will be moving some "lego-pieces" around. With the connected REPL, you will be able to eval any expression in-place, from where you're writing your code.

I started without these and indeed, that was challenging. Having to balance the parentheses by hand, counting them, omg, I was so obtuse, but I'm glad I didn't give up. You don't have to go too crazy - in the beginning, something that automatically balances out the parens, or highlights them when they are not, and lets you grab an expression and paste it somewhere else would be good enough.

And the REPL. Shit, I didn't know any better, I thought I was suppose to be copypasting or typing things into it. That is not the way! Find a way to eval expressions in-place. Some editors even show you the result of the computations right where the cursor is.

I have done years of programming prior to discovering Lisp, and I don't really understand how I was okay without it. I wish someone has insisted to try it out. Today I don't even understand how can anyone identify as a programmer and "hate" Lisp, just because they have stared at some obscure Lisp code for like two minutes at some point.

also, for what it's worth, I've moved on to mexp in my old age. Just easier to figure out where things begin and end without all those parens. And they more-or-less mechanically convert to sexpr when you need them to.

And back in my day you couldn't get a CS degree without a class on parsing and interpreting structured data. Usually it was the compilers class. Now we don't require kids to take a compilers class so an entire generation doesn't understand why regexes don't work in all cases. When kids in my organization try to "parse" HTML or XML with regexes, I hand them a copy of the O'Reilly Lex and Yacc book. And when they come back saying they can't understand it, I hand them the Dragon book. I guess I just think we should all feel that particular pain. Sorry for the digression, but I was triggered by "regex" and "parser" used in the same sentence.

The appeal can be seen with paredit-style [1] editor plugins. They give you the power of working on trees rather than text. When you master the paredit way of editing you’ll wish you could do that with every language.

[1] https://paredit.org/

> I’d rather have the language …

check out Lean 4 then. Its syntax system is based on Racket but —instead of parens— implements stuff like [JSX syntax](https://github.com/leanprover-community/ProofWidgets4/blob/d...) and a [maze](https://github.com/dwrensha/lean4-maze)

The unmatched beauty of the Lisp is the elegance of writing code generators (macros).

Code is list and main structure is list. This is genius.

It's called https://en.m.wikipedia.org/wiki/Homoiconicity

i have never used a lisp, but i’d assume due to its focus on macros, you are alternately the developer of a compiler and the user of that compiler. so making it easy on the compiler dev makes it easy on you.

The first thing that comes to mind is macros.

Are you interested in learning the appeal?

Consider the following LISP function that performs a transformation of an MxN matrix:

(defun transpose (matrix) (apply #'mapcar #'list matrix))

Based on my own experience I think I can say that It isn't until one has acquired a reasonable amount of experience with the language that they can fully appreciate its power.

Now try it with BQN

Try defining data in C. Try extracting data from that data you've defined in C.

If you can understand the appeal of having JSON in JavaScript, you can understand some of the appeal of Lisp.

I’m having trouble understanding what you mean, if you could provide or link to an example I’d appreciate it.

Sure. Here's a comment with more of an explanation:

https://news.ycombinator.com/item?id=36158974

How does it know "1970-01-01" is a date?

It wouldn't. The consumer would need to know to expect a date as a string and parse it.

I feel like I must be missing something, because I don’t understand why representing data in an s-expression is better than representing it as nested arrays (lists of lists) and hashtables/dictionaries. I also don’t see why representing data in a language’s data structure is inherently better than representing it in a language-agnostic format like JSON, and having libraries to parse and convert data from that format into a language data structure, or a library that defines a JSON type, or storing the JSON in a string and using a library that operates on strings that contains valid JSON. I’ve worked with data in this way (JSON on disk, converted to nested arrays/tables in code) and haven’t felt it to be painful.

I can see how one might have a taste preference for it, but I’m struggling to understand what the tangible benefits are.

> I don’t understand why representing data in an s-expression is better than representing it as nested arrays (lists of lists) and hashtables/dictionaries.

An s-expression is a list. An s-expression like (list (list 1 2) (list 3 4) (list 5 6)) is a list of lists. An s-expression like (hash "a" 1 "b" 2) is as hash table/dictionary.

> I also don’t see why representing data in a language’s data structure is inherently better than representing it in a language-agnostic format like JSON

You don't see why having a language data structure like Date is better than having a date-string stored in a JSON value that you need to provide parsing and other functions for? If you have a language data structure like Date, you can add days to a date, extract the month, convert it to a DateTime, etc. If you just have a JSON value, you either need to provide those functions or convert your JSON value to the Date language data structure. It seems like you see the value in using the language's data structure because you then say:

> having libraries to parse and convert data from that format into a language data structure

Also, JSON is just as "language agnostic" as s-expressions. JSON happens to be a first class component of JavaScript, as s-expressions are a first class component of Lisp; if libraries exist to help you deal with JSON in other languages, so, too, can libraries exist to help you deal with s-expressions.

> I’m struggling to understand what the tangible benefits are.

I think you understand the tangible benefits of JSON? It is a human readable/writable data serialization format. It is integrated in JavaScript in such a way that you can easily serialize, parse, and extract data from it without reaching for a library. S-expressions within Lisp do that, but they don't limit you to strings, floats, arrays, and unsorted maps. You don't need to write conversion functions or use them from a library because reading and writing s-expressions are core parts of Lisp.

I appreciate your time and explanation. I'm really trying to understand the POV here, and I feel like we're veering away from my original confusion, which was around "Try defining data in C. Try extracting data from that data you've defined in C". I'm assuming your statement would be meant to apply to other common languages without s-expressions, but maybe I've misunderstood.

I don't get why Lisp's s-expressions are much better than using arrays/tables in another language, such that they are a justification for using the language. Are they only significantly superior over a language with only arrays, like C? What's something that is made significantly easier by an s-expression than by arrays/tables?

To make s-expressions language-agnostic, wouldn't you need libraries in the languages to convert between the s-expression as it exists in some specification, and the language's native data structures? This doesn't sound all that different from JSON at this point, or a much more complex specification that defines the representation of all kinds of types, like dates.

> I'm assuming your statement would be meant to apply to other common languages without s-expressions, but maybe I've misunderstood.

It was meant for C specifically. Take a JSON document. Define it in C. Here's what I see on a random cJSON GitHub project:

https://github.com/DaveGamble/cJSON/blob/master/README.md#ex...

Now do that in JavaScript:

    const jsonDoc = { "name": "Awesome 4K" ... }

Now make the equivalent jsonDoc in Lisp with s-expressions:

    (define json-doc
      (hash "name" "Awesome 4K"
            "resolutions" (list (hash "width" 1280
                                      "height" 720)
                                (hash "width" 1920
                                      "height" 1080)
                                (hash "width" 3840
                                      "height" 2160))))

The C approach is the approach you'd similarly take in many languages where you create the HashMap, then create the Array, then populate them. Of course, you could "cheat" in many languages by first making a string and then calling the JSON library's `parse` on the string. But, this is different than JavaScript where you can directly create the JSON document. In Lisp, you are always writing s-expressions, both for data and code.

> What's something that is made significantly easier by an s-expression than by arrays/tables?

An s-expression is a form of syntax. Even though it is a "list", the s-expression (list 1 2 3) is an actual list. It's not like you're taking the idea of arrays and tables and replacing it with a list. It's like you're taking the idea:

    // Create a List in Java
    var l = new ArrayList();
    l.add(1);
    l.add(2);
    l.add(3);

    // Print the List in Java
    System.out.println(l);
    // Prints [1, 2, 3];

    // Can we construct a List from the String "[1, 2, 3]"? Is there a fromString() or similar for a Java Object?

And replacing it with the idea:

    // Create a List in Lisp
    (define l (list 1 2 3))

    // Print the List in Lisp
    (println l)
    // Prints (list 1 2 3)

    // Can we construct a List from the String "(list 1 2 3)"?
    (eval (read "(list 1 2 3)"))
    // Prints (list 1 2 3) as a List object

What about dates? What if we want rationals? What if we want to use a binary-search-tree-map instead of a hash?

    // Create a Date in JavaScript
    const date = new Date()

    // Print the Date in JavaScript
    console.log(date);
    // Prints Wed Apr 16 2025 00:00:00 GMT ...

    // Can I JSON.parse that string and receive a date?

Lisp:

    // Create a Date in Lisp
    (define d (today))

    // Print the Date in Lisp
    (println d)
    // Prints (date 2025 4 16)

    // Construct a Date from the String "(date 2025 4 16)"
    (eval (read "(date 2025 4 16)"))
    // Prints (date 2025 4 16) as a Date object

The Lisp examples are simplified, but that is the idea.

> To make s-expressions language-agnostic, wouldn't you need libraries in the languages to convert between the s-expression as it exists in some specification, and the language's native data structures?

Yes.

> This doesn't sound all that different from JSON at this point, or a much more complex specification that defines the representation of all kinds of types, like dates.

Correct. It would just be like JSON and whatever bits are standardized are what would be handled.

I think I see what you’re getting at. Thank you for the explanation!

Hash tables or dictionaries can be S-expressions.

Some Lisp dialects do not have printed-representations for these; that is a bug, and needs no further discussion.

Common Lisp and Scheme have vectors: they are notated as #(...). That is an S-expression.

CLISP has a #<N>A(...) notation for multidimensional arrays, which it can print and read:

  [8]> (make-array '(2 2) :initial-element 0)
  #2A((0 0) (0 0))

There is a little bit of a restriction in that backquote doesn't support multi-dimensional arrays:

  [2]> (let ((x 42)) `#2A((,x 0) (0 ,x)))
  *** - READ: unquotes may not occur in arrays

But this does work for vectors (as required by ANSI CL, I think):

  [11]> (let ((x 42)) `#(0 ,x 0))
  #(0 42 0)

You might think that #(0 42 0) is just some list variation, but in fact it is a bona-fide vector object, with fast numeric indexing, and without the structural flexibility of lists. Vectors are typically implemented as flat arrays in memory. (Though they could use something else, particularly if large, like radix trees.)

Hash literals look like this in TXR Lisp:

  1> #H(() (a 1) (b 2) (c 3))
  #H(() (a 1) (c 3) (b 2))

You can see the order of the keys changed when it was echoed back. The first element in the #H syntax, (), gives properties. It's empty for the most general form of hash, which uses equal comparison, and doesn't have weak keys or values.

Binary search trees are likewise printable. The #T notation gives a tree (concealing the nodes). The #N notation for individual tree nodes:

  1> (tree)
  #T(())
  2> (tree-insert *1 1)  ; *1 means value from repl line 1
  #N(1 nil nil)
  3> (tree-insert *1 3)
  #N(3 nil nil)
  4> (tree-insert *1 7)
  #N(7 nil nil)
  5> (tree-insert *1 4)
  #N(4 nil nil)
  6> (tree-insert *1 2)
  #N(2 nil nil)
  7> (tree-insert *1 8)
  #N(8 nil nil)
  8> (tree-insert *1 0)
  #N(0 nil nil)
  9> *1
  #T(() 0 1 2 3 4 7 8)
  10> (tree-root *1)
  #N(3 #N(1 #N(0 nil nil) #N(2 nil nil)) #N(7 #N(4 nil nil) #N(8 nil nil)))

The #T notation is readable. It gives the values in order, but they don't have to be specified in order when you write a literal:

  11> #T(() 3 2 1)
  #T(() 1 2 3)

If we ask for the tree root, we see the actual nodes, and how they are linked together:

  12> (tree-root *11)
  #N(2 #N(1 nil nil) #N(3 nil nil))

All these notations are something we can casually use as data in a file or network stream between TXR Lisp programs, or anything else that cares to read and write then notation.

The printed notation of any object in a Lisp is a S-expression. S-expression syntax usually strives for print-read consistency: when an object's printed notation is read by the machine, a similar object is recovere. (In some cases, the original object itself, as with interned symbols).

If you parse things with structure, and the structure is unknown in advance. In C(++) you have to generate all dynamically, and is very complex.

In other systems, you can just read the object, and the structure comes with it.

Javascript does that without lisp syntax. Not sure how helpful it is though, unknown structure is equivalent to no structure, an attempt to communicate without a protocol.

Most Lisp-y language have multiple parsers. The frontend may be that one, or it might be another. Racket has hundreds of frontends [2], Scheme has Wisp [0], and so on.

The ideal part of it comes down to the language being able to manipulate itself. Make the tokens an array, that you can shift, inject and/or mould into what you need.

That being said, that power isn't isolated to just Lisp-y. A few stack languages have it, like Forth, or to plug myself [1]. However, stack languages are a bit harder to optimise.

It isn't that they don't want a complicated parser. It's that you want to be able to easily modify that parser as its running, without hitting TeX levels of performance slowdowns.

[0] https://srfi.schemers.org/srfi-119/srfi-119.html

[1] https://git.sr.ht/~shakna/jstack

[2] https://doi.org/10.1145/3580417

I personally find lisp-y syntax to be pleasant to write, and to generally be straightforward and easy to read. It's interesting to hear you have the opposite opinion, though.

I tried fennel for a game jam and honestly was pretty disappointed. The way lisp languages are pitched here, I thought I was in for a mind opening experience, but instead the end experience was pretty much identical to lua in ever meaningful way, the only differences felt surface level (I.e. using closures, and parentheses).

I'm forever indebt to lisp for giving JS it's saving graces (closures and FN as first class citizens), but I think we some honestly on what the end experience really is.

Did you program against a REPL connected to your game, with state maintaining hot reload? Does your editor support working with s-expressions (eg. slurping and barfing)?

Batch processing style programming (write to file, save, run, stop, repeat) in Lisp removes some 3/4 of what the language(s) offer. It's especially so if one is navigating code by text rather than structure, eg. jump-to-next-word instead of jump-to-next-expression.

What is magical about Lisps, esp. the ones that are fully featured in this sense (Common Lisp, Clojure), is that you're programming a running program without losing state when you re-evaluate code.

That is magic. Instead of doing the save-compile-run-setup-conditions-wait-for-result-repeat hundreds of times per session, you run and write the code for your given problem when it arises during gameplay.

On top of that you throw on things like paredit, condition systems and you're and order of magnitude less frustrated and dare I say it, productive, than when you constantly have to churn through constant transitions between the code-in-file and game-in-memory disparity.

For games especially, things like test driven development make no sense because state is so insanely tangled. So you either hope for the best, or you program against a live game. I prefer the second option.

The way to appreciate a Lisp is to use an actual Lisp, not a syntax transpiler for a non-Lispy language.

Common Lisp, Racket or Scheme with a good REPL and editor integration are light years ahead than Fennel which is little more Lua-with-parens.

> Fennel is little more Lua-with-parens.

Totally. And Clojure is Java-with-parens; Janet is C-with-parens; LFE - Erlang-with-parens; Elisp is a Stallman's erotic fantasy, neatly wrapped in parens. Only Common Lisp is an "actual Lisp for immortal souls" - the rest is for peasants.

Fennel isn't a "real" Lisp. It's more of an aesthetic layer on top of Lua than anything else. Try learning Scheme.

Give me a break. What's not "real" about it? It's homoiconic, it supports connecting to a REPL, it has macros, first-class functions and proper lexical scoping. What else do you want, Guy Steele personally sending you an emoji whenever you install it?

> The way lisp languages are pitched here, I thought I was in for a mind opening experience

Have you used a Lisp with a connected REPL? Not the one that you have to type instructions into - the one that allows you to send any expression at point, with virtually zero ceremony to it, basically letting you evaluate any part of the program on the fly? And that REPL can be even remote - at work we use one running in a kubernetes cluster, we can change our APIs and experiment without not only redeploying things, we don't even have to save our changes. Can you imagine being able to try your code without saving, linting, linking, compiling, deploying - all that on the fly? It is truly mind-opening experience. It's so fucking nice, it's like playing a video game. I do understand why it's appealing to build actual video games that way.

Using a Lisp without structural editing tools and without a REPL is like having a Ferrari without a working engine - you'd have to pedal it to move around, it's ridiculous.

And yet people write a ton of XML, JSON or YAML by hand.