gui VS jank

> The problem with learning Lisp is `(a ,b c)

If you can understand "String ${interpolation}", you can understand list quasiquoting.

> But the problem remains: it only takes one wizard to make reading code impossible by outsiders.

This really is a Lisp meme. There are plenty of Lisp wizards like Guy Steele, Rich Hickey, and Matthew Flatt. The wizards perform the magical act of making code legible and intelligible. I have stumbled around several Clojure and Racket code bases and never felt like "I should understand this code but the features of Lisp make it impossible to know for sure." "Infinite power" macros and whatever are really only used sparingly and generally when it's impossible to achieve a goal otherwise. No one is doing (define + -).

> But this means no-one outside of the language/system developers know the language, this means Lisp tends to be write-only by design - not in the line-noise meaning, but in the obscure foreign language meaning.

I, as a Racket novice, have been able to add candlesticks [1] to the plot library without learning much about it. I have also debugged DrRacket (an IDE) to uncover that Racket GUI operations performed significantly worse if non-integer scaling was used [2]. At no point when I was going through Racket internal code did I ever feel it was write-only. In fact, it was quite convenient to modify Racket internal source code, rebuild, and test changes in a way that would be much more difficult in Java or C++.

> You certainly can not do that, but if you choose to not do that, why pick Lisp?

Built in rationals.

The ergonomics of defining [XML / JSON / etc] data as S-expressions and doing things like pattern matching on that data.

Great, coherent integration between GUIs, plots, statistics functions, and all the other bits of Racket's batteries inclusions.

You still have access to all the other great features that other languages have borrowed from Lisp like REPL development, package managers, good IDE tools, etc.

It is nice to learn the meta-syntax of parentheses once and know that the code will always look like that. No need to consider if some feature is implemented as a syntactically different new keyword, annotation, function call, or whatever. It'll always be a (feature).

> something you have to conciously work for with Lisp.

Plenty of languages have style guides, linters, static analysis tools, etc. to make sure the code conforms to certain restrictions. Lisp feels no different in this regard.

[1] https://docs.racket-lang.org/plot/renderer2d.html#%28def._%2...

[2] https://github.com/racket/gui/commit/20e589c091998b0121505e2...

Please file a bug report at https://github.com/racket/gui/issues

https://github.com/racket/gui/issues/207#issuecomment-753406612

There's an effort afoot to bring this to the Clojure world, with the lovely name jank: https://jank-lang.org

I also liked that reference since I had not heard of Jank before. It is a work in progress so I just added a calendar entry for 9 months from now to check it out. https://jank-lang.org/

There will be a lot of room for this, once I build out more of the features. In particular, there will be a lot of Clojure libraries which need to gain jank support. Clojure doesn't require "porting", so to speak, since it has a special .cljc file which can use reader conditionals to check the host that it's in (clj, cljs, cljr, jank, etc). So anywhere those libs are using Java interop, we'd need to wrap it to use native interop instead.

On the compiler and tooling itself, I have some open issues here: https://github.com/jank-lang/jank/issues

The vast majority of it is heavy C++ work, though. Outside of that, the biggest gains will come from time spent on packaging, distribution, and testing on various platforms.

And if none of that sounds interesting or applicable, don't worry. Just be sure to join the Slack channel and hang out with us. :)

On the top of using C++ for scripting, and related to the discussion of CERN's ROOT/Cling, I am developing a Clojure dialect on C++/LLVM called jank: https://jank-lang.org/

jank is a true Clojure, meaning you get interactive, REPL-based development and a whole stdlib of persistent, immutable data structures and functions to transform them. But it's also C++, so you can write inline C++ within your jank source, and interpolate jank values within that. You can link with existing native code using LLVM and you can embed jank into your existing native projects to use for scripting.

jank is pre-alpha, right now, and I've only been showing it to Clojure devs so far, but there's a huge audience of C++ devs which may be interested in introducing Clojure to their native code.

jank (https://jank-lang.org/) is a Clojure dialect on LLVM with C++ interop. In this talk, Jeaye will cover jank's use cases, some challenges around building a native Clojure dialect, and some insights about Clojure itself found only by spelunking deep into the Clojure compiler.

I wonder if Jank [1] could be such a Lisp? I haven't played around with it, but I really like the idea and would love to see it get more traction.

[1]: https://jank-lang.org/

This isn't usable yet, but in active development by the author, and looks promising: https://jank-lang.org/

Jank looks pretty legit: https://jank-lang.org/