It's my understanding that as part of Project Loom, Tail Call Elimination is on the table for implementation.

yawn

Scheme is nice. Currently doing, slowly, SICP with scheme. But I don't think it's used in the industry. Whereas clojure is used, and being a JVM language surely has its advantages.

Clojure lets you do manual tail call elimination using recur if you want. Using it is not built into the compiler, but as long as you know this, I have rarely seen programs where Scheme's automatic tail call optimization makes a huge difference. Seems like a pretty minor objection to Clojure to me, personally, relative to other differences, e.g. Clojure's built-in default implementations of immutable collections.

Different people have different judgements for how important technical language differences are to them.

Do Scheme/Racket feature homoiconic maps, vectors, and sets? (I know it has lists covered 😆) Are its collections immutable?

I always view any functional language with non-homoiconic, mutable-by-default collections with great suspicion.

I am less knowledgeable about Racket, and could not answer for it, but Scheme definitely has mutable cons cells and set! .

Racket's cons cells are immutable. I don't think you want to pick a fight with Racket on syntax 😛

there's an (unmaintained) port of Clojure to Gambit Scheme which does have TCO: https://github.com/takeoutweight/clojure-scheme

most Schemes allow you to extend the reader to introduce data literals, and there are implementations of immutable/persistent data structures. Clojure doesn't stand out for what it can do (except if you count the reach of the JVM, but there are other lisps there). it stands out by the good things it nudges you to do and the bad things it discourages you from doing, which has helped create a more widely shared culture around those values

i.e., Racket probably has persistent data structures (I haven't checked), but if you grab any Racket library at random you can't assume its interface is based around them in the same way you've come to expect in Clojure

I think recur is enough for most application code in practice. TCO and continuation support would allow to implement things like core.async without macros: https://pastebin.com/ff732013 (this is just an old POC and it's of course much more limited in scope than core.async, but it has the fundamental mechanics). I don't miss them much, though

Note that that website hasn't been maintained for years. Apart from just having broken links, it also uses a quite old Clojure version so some of the things you know will not be useful. And conversely, some of the things you will learn with the website will be outdated.

several of the exercises focus on problems like "if a function like foo did not exist in Clojure, how can you implement it using other built-in functions?", to get you to think about other ways to do it. Such exercises can result in a better understanding of how those built-in functions work under the hood, and that there is pretty much always more than one way to do things, which can be a useful mind set to have. I wouldn't call those particular exercises useful when writing production code -- in production coding situations you would use the built in functions that let you do the job in the most developer-time-effective way you know.

If you like programming, and like solving "logic puzzle" types of problems, 4clojure can be interesting and you can learn a few things from it. Many people have found it useful in helping to improve their understanding of Clojure as a language beginner. The easier and medium problems can typically be solved in a short amount of time. I wouldn't say "If you haven't done 4clojure problems, you aren't a real programmer" or anything like that.

the old clojure version is intentional (the site maintainer thinks it would be unfair to past participants to introduce a clojure version that wasn't available to them) - but very little that you learn about clojure 1.4 doesn't apply to today's version

I learned a lot about clojure from 4clojure (though many of the answers that others submit, if you compare your answers, are written for code golf and not quality)

Transducers are a significant chunk of Clojure that's missing from 4Clojure. I remember encountering some other issues where the documentation clearly states that something is possible but 4Clojure doesn't work with it - alas, I don't remember the details. @U051SS2EU Do you have a reference to that statement about an update being unfair (which, IMO, is not a good argument all by itself)? I know only of this comment that explains that the update hasn't been done only because of clojail: https://github.com/4clojure/4clojure/issues/303#issuecomment-509882098

@U2FRKM4TW this is the explanation that amalloy gave when I asked about updating the version, he still hangs out on #clojure freenode IRC, though he isn't active in clojure dev any longer

yeah, clojail is a hack, a modern redo of 4clojure would likely be better off using a self hosted cljs in browser

though that leaves an opening for exploits where a "solution" does something unexpected when run in your browser

I mean, if someone wanted to make http://5clojure.com , I doubt anyone at http://4clojure.com is going to complain 🙂

since 4clojure uses clojure 1.4, maybe we are due for 11clojure

this is not wrong as an idea, but a bit smelly because of alter-var-root using. Have a look at this macro — https://github.com/ptaoussanis/encore/blob/master/src/taoensso/encore.cljc#L406-L431

This thread is worth a read https://groups.google.com/g/clojure/c/Ng_GXYSrKmI/m/q0cxahB3BAAJ indeed a thin replacement can be ok, but it's better to assess first the structure of your code

thanks a lot guys