To choose a scheme/lisp?

So… what is the tooling you are referencing? I’d love to get rid of that default behavior in the Clojure REPL.

OK, what “default behavior in the Clojure REPL” are you talking about – because it doesn’t involve Java stacktraces. See my post earlier in this thread.

You’ll very rarely have minimal and elegant alongside with useful and practical.

A lot of the “small”, “elegant” lisps tend to also be bare-bones that nothing useful or substantial can be implemented with them.

Try using threads in chez-scheme, the elegance disappears. Try doing some serious form of I/O, the elegance will disappear as well.

If you added mountains of libs, frameworks, drivers, components, dependencies, and all that, what attracts you to it would also slowly disappear.

I think Clojure manages to strike a good balance between the two.

1 Like

Obviously walled gardens benefit some people but this is getting ridiculous.

Racket is written with chez, Idris is written with chez, Julia could very well also have been written with chez. It seems the lack of libraries haven’t stopped implementors from creating a language and their own ecosystems.

It’s almost akin to a clojure developer going… the JVM is elegant and minimal but who writes bytecode?


Chez provides a really good compilation target because it’s small and it’s a scheme.

https://idris2.readthedocs.io/en/latest/backends/chez.html


As for the FUD regarding threading:

Futures with chez

thread system
https://www.scheme.com/csug8/threads.html


experimental implementation of future with Chez Scheme threads

I love relying on experimental gists for production use-cases :innocent:

But also this wasn’t my point. My point is that once you build the necessary frameworks and libraries (either standard or 3rd party) for a complex use-case needing threading and/or complex IO, you’ve lost the elegance, because now you’ve got all these complicated threading and IO frameworks/libraries you need to include in your application, learn, manage, maintain, interoperate, etc. This then starts to feel like “bloat” which kills the elegance. And similarly, your own application will grow in complexity, because even using futures is inelegant if you need complex use of threading, and similarly complex IO is just inelegant. Scheme hasn’t found a revolutionary paradigm to handling threading and IO that is elegant the way that it has elegance for pure logic.

That’s not to say Chez-scheme cannot handle threads or IO, but it kills the elegance if you use those features.

There’s other considerations that are similar, implementing sagas, singleton components, app state, plugins, database access, error and retries, etc. When you put all that together, elegance goes out the window.

Similarly, you could take Clojure, remove all the things it has that is designed to support or that were compromised to handle those kind of application requirements, and you’d be left with a pretty elegant language.

That means that, it’s inherent to a Scheme, in order to remain small and elegant, that it does not add bloat to handle these things, otherwise it would grow inelegant. And in-turn, that’s why CL or Clojure are more often used for these nasty kind of use-cases, and schemes are popular in more pure domains like a compiler or transpiler implementation.

2 Likes

Janet is a pretty neat lisp as well to consider. Very pleasant to use with C for games and gui. Others use it for web servers and scripting as well. It’s essentially Lua with Clojure syntax.

I use Common Lisp (https://lisp-lang.org/) when I want a LISP that doesn’t run on JVM.

1 Like

Ok, now I have decided to stuck with clojure, I am doing web dev in luminus. But I will keep an eye on chez scheme, and when it gets more libs, I might switch back to it. And in the meantime, verse on a terminal and repl would be interesting

2 Likes

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.