Our great sponsors
-
-
deprecated-coalton-prototype
Discontinued Coalton is (supposed to be) a dialect of ML embedded in Common Lisp.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
immer
Postmodern immutable and persistent data structures for C++ — value semantics at scale (by arximboldi)
-
-
web-development-with-clojure
Repository for the examples from the book Web Development with Clojure, 2nd edition
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Do you know about the Typed Clojure project? More or less Racket's contract system, for Clojure:
https://github.com/clojure/core.typed
To me, it's one of the great testaments to the power of Lisp that you can bolt on a static type system after the fact.
This looks like something Common Lisp does better, however I have too little Clojure experience to compare. CL (and SBCL in particular) does "good enough" static type checks, it throws warning at compile time (when we compile one function with a keystroke). We can also precise our function types gradually. It isn't a HM type system (Coalton[1] could be it) but it's already great (compared to no compile-time types at all).
Oh, about interactive development: that's sure, CL shines here. Objects get updated (lazily) after a class change, we can install Quicklisp libraries without restarting the image, etc. It's very smooth.
1: https://github.com/stylewarning/coalton
https://github.com/clj-kondo/clj-kondo/blob/master/doc/edito...
If you want types at your system boundaries like on your API then specs or malli is great for that
A great thing that Rich Hickey always advocated is separating out problems and then solving them individually I think modern type systems try and take on too many problems at once, static analysis tools are great because they're uncoupled by time and are laser focused on detecting mistakes only
I've been using Clojure since the summer of 2009, started a startup with it, using it exclusively on one project right now... and I agree about static types. I love many many things about Clojure, its my favourite language to use and I find it very well designed over all. But proper first class static types are the one thing I wish it had.
My dream programming language is basically a statically typed Clojure.
I've on and off poked at trying to make something like that (parsed using instaparse, type checked in Clojure, compiled to C++ using https://github.com/arximboldi/immer for the data structures), but haven't had the time to really get anywhere with it. Plus, even if I succeeded, I wouldn't have the rich Clojure (and by extension, Java and Javascript) ecosystem.
6. ClojureScript. Could be my unfamiliarity with ClojureScript/JavaScript, but I find I have to revert to JavaScript too often to get something done. And if I can't just use ClojureScript, why use ClojureScript?
Like any Lisp, Scheme is easier to read than Python, Java, JavaScript, Haskell, PHP, Perl, Fortran, Forth, APL, etc. Pascal is pretty good in this regard though. Clojure might actually be better in my opinion.
Why not Common Lisp? It's pretty good and at least as powerful. The warts annoy me though.
So I will continue using Scheme while looking into Janet https://github.com/janet-lang/janet. Janet has most of the things I like about Scheme _and_ Clojure. More experience will tell. I just miss the way maps are handled in Clojure.
I actually did build something basic following the book Web Development With Clojure (https://github.com/jumarko/web-development-with-clojure), but honestly the way the code snippets were presented in the book were sometimes difficult to use if trying to follow along and build it yourself.
I think you could probably get code from different chapters from their git repo, but then you're not doing it yourself - you are instead trying to read diffs to understand what's new and figure out why it has been changed.
My experience has been that there is no complete guide, tutorial, or example that is kept current and provides every detail such that you can follow it and learn. I'm sure with enough concerted effort, one obviously can learn it... but there will be some trial and error and some guesswork. Normally that's fine, but it slows the process compared to other tech stacks and their guides.
The Clojure community is nice and helpful, but they're all busy doing real work (rather than teaching). Even the book I mentioned is not yet complete and has been in progress for over two years I think.
Maybe what I should have said was something along the lines of an "iterative language." Essentially I was thinking of a language where you can reload the functions/types in a single module and see the results instantly without restarting. The shortening of the feedback loop is the important part. And also important is being able to take some code and out it in a REPL to find out what it does or modify it until it's just right.
One language which is explicitly designed to have first-class hotloading support and static types is Mun. It's not production ready, but it was born out of frustration over the dynamically typed nature of Lua while appreciating the benefits it brought to extensibility and code discovery/exploration.
https://mun-lang.org/
For me Lua has the iterative part, but no types. The iteration makes LÖVE an attractive target for gamejam developers, who don't want to be constrained by compile-restart cycles when they don't yet understand what ever aspect of the finished game will look like.