Why Fennel?

Sadly that's not worth anything. ¯\_(ツ)_/¯ Anecdotal evidence in both directions.

I had a soft spot for Emacs for a _long_ time (almost two decades)... FWIW. ;)

Key word: had.

1. I ain't willing to die on any hill. In fact I was 100% certain I'll regret commenting negatively on Emacs. Pretty ardent and devoted fans, it seems.

2. The ivory tower thing is dedicated to the parent poster sounding a bit elitistic and trying to imply I am doing it wrong and he's doing it right -- which I did not deny by the way (which is the really funny part) as my central point was "too much freedom is not good".

3. I completely agree with the notion that not all tools are ideal for all users. I used this sub-thread to express a strong opinion that Emacs allows the "too much freedom" thing that actually becomes much more of a hurdle for those of us that just want to get on with it. I was sure it's going to ruffle feathers which makes me commenting on it fairly stupid, come to think of it, because I was not looking to pick fights, but just to broadcast an apparently unpopular opinion and never engage with replies. Which I failed spectacularly. :D

> If software tools sink to the lowest common denominator, like the vast majority of commercial software, we’ll all be worse for it.

Here's the part where you and I will disagree. Your statement is correct on the outset but I take issue with it because I take it as a hint that Emacs > all other editors. Which cannot be stated as a fact, ever, not for any editor, not just Emacs.

I am no longer impressed by the gray color treatment of my comments when it happens (don't get the impression that it's the norm; it's fairly rare). HN has showed me that it's much more about group-think and cargo culting than objective and calm discussion. Obviously those elements still kinda sorta prevail a good part of the time but for the most part the random HN user fell victim to the usual big herd logic fallacies. So let them press their arrows, that's not changing anything. And I didn't even claim something is objectively / universally bad. I said that the priorities of Emacs are not my priorities, in not-the-perfect diplomatic way that's apparently expected. Some people couldn't take that and pressed the arrow.

It's their right. ¯\_(ツ)_/¯

With that being said, I also struggled with Emacs. Again, too much freedom. I don't want to care where am I supposed to put `.el` files. I want a plugin manager and to be able to tell it: install / update / delete. Neovim's Lazy and Mason do that and that's why I love them. Just earlier today some configuration of a plugin broke; it used git submodules and something got moved and the new revision used another mechanism. I literally fixed it in 5 seconds: deleted the plugin, installed it again, and configuration persisted and I didn't have to set it up again. Reopen a file (just input `:e` in the command bar), everything worked right away. Is this too much to ask of Emacs?

> They just seem to make breaking changes a lot more often.

That was my experience as well. Always some warning in the command bar or a full-blown stack trace. No thanks. I don't associate with amateur work.

My apologies, but I no longer remember. I only remember my huge annoyance that almost anything I did, even successful, led to some warnings or unnecessary notifications in the command bar. Always some noise there. Not to mention the occasional actual failure in a plugin leading to huge stacktraces and leaving me with a partially working editor that kind of still works but not quite.

My brain mercifully deleted all details. At one point I really had enough (and waiting for 19 years for an editor to get better is IMO having an angelic patience that Emacs did not deserve) and just moved on and forgot all about it.

At that point you’re almost, but not quite into the realm of “forth”

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.

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

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

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

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.

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.