This is a pretty weird hill to die on, boss. Are you suggesting that all of the software written over the years by emacs users (eg gcc) is “ivory tower”?

As a community of practitioners we should embrace the idea that not all tools have to be “ideal” for all users. Some people like hacking their editor, and some don’t. If software tools sink to the lowest common denominator, like the vast majority of commercial software, we’ll all be worse for it.

I know you're being down voted, but I've struggled with my Emacs config breaking quite frequently over the years. Nearly all of the breakages were due to plugins. I assume these breakages would be far less common if I was only using old plugins like Helm. But I like fancy new plugins that bring new functionality and smooth UX. They just seem to make breaking changes a lot more often. As far as performance goes, Emacs is roughly equal to VSCode IMO. It sometimes chokes on large files, but in general works well enough for me. To be fair, I've had trouble with Neovim + plugins becoming sluggish as well.

I have about 140 Emacs plugins running.

I've never had to declare Emacs bankruptcy.

10 years of good times with Emacs+evil and 35 years of vim.

Fwiw.

Hey... could you write about one or two of the worst offenses? I consider myself an emacs/elisp power user, yet somehow (M)ELPA seems pretty doinked out-of-the-box on a stock Debian nox-emacs install. I just thought it was me.

A bit but I don't like "set foo 32"

One way I think I can get rid of that is like this

    32 = foo;

But why do we even need variables? I think the perfect language design would be if you could just do this:

    pow(x, 2);
    pow(y, 2);
    sqrt() = result;

And maybe you could do this

    {
        pow(x, 2);
        pow(y, 2);
        sqrt();
    } + 1;
    pow(2) = result;

Instead of result = pow(sqrt(pow(x, 2), pow(y, 2)) + 1, 2); that we have today.

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.

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

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) ...)

  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

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

  (ifx
    (defstruct user ()
      id name)

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

    ...)

  (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)))))

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

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

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

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

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

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

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.

[dead]

> 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?"

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

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

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

> 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 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.

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

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

    // 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?

    // 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)"))

    // 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?

    // 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)"))

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).

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