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

I'd rather have the language add that extra complexity into the parser than have me stare down these endless paretheses. Parsing something C-like is not that, hard, trust me, I've done it

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.

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.

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

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

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.

    (f x y)

    f(x, y);

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

[1] https://paredit.org/

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)

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

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

[0] https://tinysse.com

[1] https://github.com/benwilber/tinysse

[2] https://github.com/mlua-rs/mlua

There might be a way to get standard ML to output lua or something but I'm not that familiar with it. I think it would be an incredible fit for a third backend for gleam, but they say they aren't adding any more beyond erlang and js.

[1] https://github.com/minoki/LunarML

[1] https://github.com/yanghuan/CSharp.lua

[1]: https://github.com/Grazfather/dotfiles/blob/master/nvim/fnl/...

[1]: https://git.sr.ht/~xerool/fennel-ls/

[2]: https://github.com/rydesun/fennel-language-server

[3]: https://github.com/LuaLS/lua-language-server

[4]: https://gitlab.com/repetitivesin/16cm.nvim/-/tree/main

[5]: https://gitlab.com/repetitivesin/madol.nvim

A good and comprehensive LSP for example. It really needs to be on par with other languages to increase adoption

I appreciate customization; that's why I moved to Neovim and not to a full-blown GUI IDE (and I'll never use those). But that editor you speak of practically requires me to fix the idiocies of plugin authors that can't be bothered to run 7 tests on their code.

I get it, a lot of programmers are cult followers. I was as well. At one point though, pragmatism should prevail. The editor should ideally be non-laggy and not spit warnings after I move from one buffer to another. Just embarrassing.

Before anyone yells "skill issue!", I'll say that if any plugin author can make the editor crap the bed, then the editor is not good.

There are degrees to freedom. Complete freedom in such environments is a liability, not an asset.

Say hi to the others in the ivory tower. And remind them not to do selective omissions in their supposed counter-arguments to "win" an argument, and that it's a cheap tactic.

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.

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've never had to declare Emacs bankruptcy.

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

Fwiw.

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

Key word: had.

Also by the same author.

But it does come with some design decisions that I'm a bit ambivalent about and for which I haven't found a good explanation:

- No persistent data structures. I guess this has something to do with limitations of the GC?

- unhygienic macros combined with lack of namespaces. XOR those two choices would be fine, but the combination is janky

- Somewhat peculiar choices in syntax. It's neither Scheme, nor is it Clojure. # starts comments, ; is splice, @ marks literals as mutable...

https://git.sr.ht/~benthor/absolutely-minimal-love2d-fennel

0(example config): https://github.com/TheBlob42/love2d-fennel-neovim

https://git.sr.ht/~technomancy/fennel-lang.org

Janet looks like is by Calvin Rose (bakpakin) https://github.com/janet-lang/janet/graphs/contributors

    % git remote -v
    origin https://git.sr.ht/~technomancy/fennel (fetch)
    origin https://git.sr.ht/~technomancy/fennel (push)

    % git log --reverse
    commit 9afe4338ed1816a759cb4b120f89e8f67159ce16
    Author: Calvin Rose 
    Date:   Sun Aug 7 18:50:34 2016

        First commit.

    commit b62a24853e24662f76932a2a81bb77cc25704491
    Author: Calvin Rose 
    Date:   Sun Aug 7 19:05:40 2016

        Add some examples.

    commit 5e3e0fe11e4f56007b3523e54d81d55280ef2204
    Author: Calvin Rose 
    Date:   Tue Aug 9 08:27:43 2016

        Update README.md

I don't think the average programming language enthusiast is maintaining multiple well-known languages.

I really want to try making a language that is imperative, like really imperative, where every line must start with a verb, just to see what it would look like.

It would look like Tcl.

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

    32 = foo;

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

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

The author posts on HN as ‘munificent’, I think.

I wish it had gradual typing support though or at least allowed for type annotation for static tooling. Not that dynamic typing isn't a valid choice but with more and more languages getting gradual typing support it is hard to go back.

I guess we could build something like Coalton but for Lua.

Maybe a static system can be built upon it.

https://github.com/codr7/eli?tab=readme-ov-file#type-checkin...

Yeah, it is very nice to work with.

The only tiny "complaint" I have is that it doesn't compile to pure Lua, but instead assumes you'll be running it together with Lua's libraries.

I say this because, for me, the places where I'd like to use Fennel have a lot of overlap with the places where I'd like to use Lua without loading any of the provided libraries (e.g. embedding Lua into other software, instead of using it standalone).

I just know that I tried to use it without loading Lua's libraries (i.e. without calling the `luaL_openlibs` function or equivalent) and was unable to.

> I just copy the compiled lua into the place the program expects to find lua scripts.

Yeah most existing programs just load all Lua libraries by default, so that's generally not an issue.

My post is more from the point of view of embedding a restricted Lua interpreter into a program (i.e. only Lua-the-language, not Lua-the-language-plus-its-libraries) while still supporting Fennel.

---

EDIT: Just checked, the Fennel code `(lambda [foo bar] bar)` compiles to Lua code that calls `_G.assert`.

https://moonscript.org/

So anything that requires C libs would automatically rule out fennel for a lot of projects that are essentially using someone's lua api as the target platform. Roblox, mud client scripting, openresty, that sort of thing.

And these environments usually have so much added to them, pcre, stdlib extensions, class systems etc fennel works best not making any assumptions about any of that. It's just straight up the lua semantics, and so anywhere lua works it works. I've used it a lot and originally recoiled from this decision but now I think it is genius.

On the "Values" page, they also mention a macro that alters the lexical scope somehow. This macro is now deprecated, but its mere existence implies that such a macro can be expressed in Fennel -- that is, that it's possible to write Fennel code that causes what looks like an ordinary function call to do surprising things to the program state.

As they rightly mention (on either this page or the "Values of Fennel" page), the advantage of constraining a language is that you can more easily tell what a program is doing (and not doing) at a glance. But this seems to be undone by giving a pass to (unhygienic?) macros.

But they do have one, that you just copied?