Try Clojure | Hacker News Reader

Try Clojure

tryclojure.org

552 pointsducktective382 comments

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decision in my professional life. It went away for a while for reasons I'm unclear on.

I use Clojure nearly daily at my job and at home. Sometimes it's standard Clojure, sometimes it's the excellent Babashka flavor which I use as a make-like task runner and Zsh-like script replacement. It's not the only language I use of course, and Go is a strong second place most of the time especially if I need something compiled to a single binary. But Clojure is where I generally feel most at home thanks to the irreplaceable REPL based development flow which is more like a dialogue with my program than your typical write compile run loop.

Combine that with it running on the JVM and you have a wonderful set of tools to get things done in a pleasant way.

I strongly encourage anyone with even a passing interest in Lisp and functional programming to give it a try. If you're using VSCode there is the excellent Calva plugin to help you out.

> It went away for a while for reasons I'm unclear on.

The creator, Anthony Grimes (https://github.com/Raynes), sadly passed away seven years ago: https://www.reddit.com/r/Clojure/comments/5gyyxw/clojure_ope...

As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18).

To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express.

Maybe the key thing is to only write small things in less expressive languages, like shell scripts, or small C functions to help performance or FFI, or, well, tiny Go utilities.

Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasoning.

There's a population of people that don't like this kind of abstraction, because to understand the code you first need to understand the problem, the data flow and how it's expressed. They prefer to look at the issue "bottom up" than "top down", and for them Go is perfect, because instead of reasoning about what the module does, how the data flows, what the algorithm does, they can focus on the small: this is a loop that iterates through a slice, this is an if condition that depends on this variable.

There's no better or worse here, just two types of people. Some like to look at the whole bridge, some like to examine the individual nuts and bolts and joints.

> There's no better or worse here, just two types of people.

No, two types of solving a problem. I like writing both (Haskell and Go) - for _myself_ - but the tooling and standard library and ... of Go is orders of magnitudes better.

> they can focus on the small: this is a loop that iterates through a slice, this is an if condition that depends on this variable.

Then a week later, the squinty mole discovers the code is dead; not called at all. There is no slice and no variable.

> The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasoning.

How does this affect readability when one tries to dive into an existing Go project? Is Go code harder to navigate than code in more expressive languages?

While I share your perspective on go, I do prefer developing in a bottom-up way myself: I just do so with the intent of iterating my way to a higher level abstraction. Sometimes I see the abstraction right away and start with it, but I don’t want a language that gets in my way in either direction.

I do switch between Clojure and Rust depends on the problems I solve at hands ( prototypes vs building production ). And yes I need go through my checklist of each to switch from connecting data flows at high level to examine nuts and bolts at low level.

Writing Go is less fun but the language has far better tooling, dead simple deployment, lower memory usage, generally higher performance, and is easier to onboard new developers. Also I find it way easier to read old projects after time away.

You can get incredible mileage out of Go using just the stdlib, built in tools, and the pure go port of SQLite. With Clojure it feels like I have to stitch a million random libraries together to get anywhere. Writing Clojure is delightful but the ecosystem and tooling pale in comparison, and at the end of the day I think that’s what matters.

If Clojure had great built-in tooling, better error messages (and maybe some SBCL-esque type checking features), and if Datomic was open source and less rough around the edges, I think the language would have been far more successful.

I won't tell you there aren't stumbling blocks and impedence mismatches but most of them are relatively minor syntactical things. The faux-AST in my head gets typed out in the wrong format and I have to backspace and correct it (think function declaration differences). The biggest workflow difference is undoubtedly the lack of a REPL in Go, but that is somewhat made up for by Go's lightning fast compilation and testing tooling (probably its second strongest attribute after the excellent standard library). After a day or two of writing in one or the other my neurons seem to get used to it only to cause the same problem in reverse when I switch back. Overall, it's not too bad and a case of just accepting the tools available for what they are. I don't try to force Go to be Clojure or Clojure to be Go.

Python is the new Java 5 here. The lack of multiline lambdas is incredibly awkward, leading to code that bounces you around the file.

Lack of multiline lambdas is infuriating, but nested named functions partially make up for it.

I must use PyTorch for ML, but badly wish I could use TypeScript instead. Its type system demolishes anything else I've used. Writing anything from SPI communications, to server logic, to rich GUIs is a breeze. Then I work in Python and have to fight `Any`s, ambiguous arguments, more verbose code, and bizarrely slow run times. It makes me sad.

While I agree with you, Python is getting better in this regard, as is mypy.

Making historical interfaces well-typed is another kettle of fish. For instance, Python's range() is actually two overrides with incompatible signatures. I bet PyTorch has more of such examples.

i find i flip between different languages when i'm thinking about the problem in a different way

an expressive language (clojure, python, C#, etc.) is good when you're iterating "what problem am i even trying to solve?"

a less expressive language is typically better when you more or less know a high level solution to your business problem, and you're iterating on "how do i make the machine actually do it". like "how do i reduce my AWS bill" or "how do i render it in 16ms?"

for something like gamedev, enough of the problem is in the second category that you might not even reach for the expressive language. (many do, though. with lua, or artisanal lisp dialects)

If you're counting C# as an expressive language then a lot of gamedevs will reach for one, judging by the market share of unity, me included :P

Java has had lambdas, map/filter/reduce and other stuff for like ten years or so I think. It's a bit chatty for sure, but that's what you want sometimes, the verbosity can make it easier for newcomers to make changes and additions.

To me it isn't more infuriating than learning a new language or practicing one I'm not very good at. There's a bit of friction, but that's common when I'm developing in the languages I'm most fluent in too. Either that or the problem is trivial and likely to be in most common programming languages.

I’ve been writing a lot of Java 11 recently, and I find it to just be a very pleasant environment to work in: the IDEs still are best in class, afaict; the newer APIs avoid a lot of the boilerplate I used to have to write out and there are generally mature libraries to interact with just about any system you might need. Where Clojure really shines is that it’s a really well thought-out layer that can leverage this ecosystem and adds its own well-designed tools on top for my preferred more-interactive development style.

These Java features are ruined by not allowing mutable variables to be captured. Having to do the 1-element array trick when the compiler could just do it for me is insane.

If you are making JavaScript look good you are failing as a language.

Java 7 is already pretty pleasant, and it has been improving ever since then.

(Say what you want about Oracle Corporation, but as the wardens of Java they're doing a pretty good job.)

The funny thing is, go is significantly more verbose than even decade-old java.

It's like looking at two very different people and realizing you are attracted by both: each one has their quirks and perks, so you like both.

Might still end up marrying only one though!

Expressiveness has many dimensions. It depends on what you are trying to express in the first place.

C++ or Rust are expressive in both directions, towards the metal and upwards in terms of abstractions. But those languages are not easy to reason about. They come with lots of stuff, hard to grok abstractions, ceremony and so on.

Small languages like Scheme or Lua are expressive in that they don't force you to write a lot of stuff to get the job done. But those languages don't typically let you express what the computer should actually do at a lower level.

C or Zigs let you do those things and are also relatively small languages. But their facilities for abstraction are limited and they force you to express more computational details.

Go frees memory and schedules goroutines for you, but lets you express a lot more about how you lay out memory than other managed languages, so you can actually think in terms of bits and bytes. It has a great std lib so you can get stuff going quickly and reliably.

As a C++ programmer, I definitely like my languages with extra legs nailed on.

But sometimes limitations can spur creativity.

I write less boilerplate in Go than in Rust, about as much in Go (but of course different ;) as in Haskell).

That's cool! How do you manage? E.g. the `if err != nil { return err; }` stuff?

We get used to being yet another work related chore.

The "j" is always what put me off from learning Clojure. I've had too many bad experiences with JDKs and JVMs that I stay a thousand kilometers away from any thing that has "J" in it unless it's referring to JavaScript.

Check out Babashka. It's a single binary that runs Clojure without a JVM. It also starts up really fast and has a much lower base memory requirement: https://github.com/babashka/babashka

It's pretty easy to switch to writing JVM Clojure if you're familiar with Babashka. Most of the libraries written for Babashka are designed to work in either environment.

That said, there are reasons you may want to use the Clojure on the JVM later on. It might be interesting to read the replies to another poster with similar concerns about the JVM: https://news.ycombinator.com/item?id=40445415

Interesting. Usually the reluctance comes from people confusing Java the language with JVM the platform.

Well, there aren’t too many more stable platforms out there, so your experience elsewhere couldn’t be all that cloudless either.

You can also try ClojureScript, which runs on JavaScript. If you're developing frontends.

If you are new to Clojure and would like to experiment with it in a way that is immediately useful, I highly recommend the Babashka runtime for scripting [0]. It's very fun, approachable, and one of the more polished parts of the Clojure ecosystem.

It's a particularly good entry point because unlike full-JVM Clojure it has a very fast startup time. Newcomers can use any file-watching /reloading tools (e.g. nodemon) that they're already familiar with to work with it interactively.

Hopefully, a enthusiastic user will graduate to using a REPL connection in their editor for a fully interactive setup. But newcomers tend not to do this... its an unfamiliar workflow to most, and can be pretty cumbersome to setup.

[0]: https://babashka.org

And when you're ready to take the fun to the web, look no further than Biff: https://biffweb.com

I love this so much. The power of being able to connect a repl to your production instance and fix bugs instantly is hard to understate. It’s actually kind of hard to explain to devs used to deployment cycles measured in weeks

How is the fix committed once you are done? Does this run counter to immutable deployments?

I recently went through most of the Biff tutorial but found it seemed to be missing some parts later on that had me scratching my head. It was otherwise a very enjoyable experience and Biff seems like a great way to get a "batteries included" starting point for web (similar to something like Rails or Django, though maybe not as comprehensive as either of those).

Mind sharing the parts of the tutorial you had trouble with, if you remember?

Ah neat. But darn, I was kinda hoping for supporting tools and packages with names like tannen, delorean, doc, mcfly, and strickland ;)

It features a time-travel database, if that helps!

https://biffweb.com/p/xtdb-compared-to-other-databases/

The best part about Babashka is that it's really batteries included nowadays. I had to make a little UI to display some stats about an app at work, and decided to try using it with HTMX. Turned out to be a really good experience. Babashka has pretty much everything you need for a basic web app baked in, and HTMX lets you do dynamic loading on the page without having to bother with a Js frontend.

Best part is that bb can start nREPL with `bb --nrepl-server` and then you can connect an editor like Calva to it and develop the script interactively. Definitely recommend checking it out if you need to make a simple web UI. Here's an example of a full fledged web app:

    #!/usr/bin/env bb
    (require
     '[clojure.string :as str]
     '[org.httpkit.server :as srv]
     '[hiccup2.core :as hp]
     '[cheshire.core :as json]
     '[babashka.pods :as pods]
     '[clojure.java.io :as io]
     '[clojure.edn :as edn])
    (import '[java.net URLDecoder])

    (pods/load-pod 'org.babashka/postgresql "0.1.0")
    (require '[pod.babashka.postgresql :as pg])

    (defonce server (atom nil))
    (defonce conn (atom nil))

    (def favicon "data:image/x-icon;base64,AAABAAEAEBAAAAAAAABoBQAAFgAAACgAAAAQAAAAIAAAAAEACAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//AAD8fwAA/H8AAPxjAAD/4wAA/+MAAMY/AADGPwAAxjEAAP/xAAD/8QAA4x8AAOMfAADjHwAA//8AAP//AAA=")

    (defn list-accounts [{:keys [from to]}]
      (pg/execute! @conn
                   ["select account_id, created_at
                     from accounts
                     where created_at between to_date(?, 'yyyy-mm-dd') and to_date(?, 'yyyy-mm-dd')"
                    from to]))

    (defn list-all-accounts [_req]
      (json/encode {:accounts (pg/execute! @conn ["select account_id, created_at from accounts"])}))

    (defn parse-body [{:keys [body]}]
      (reduce
       (fn [params param]
         (let [[k v] (str/split param #"=")]
           (assoc params (keyword k) (URLDecoder/decode v))))
       {}
       (-> body slurp (str/split #"&"))))

    (defn render [html]
      (str (hp/html html)))

    (defn render-accounts [request]
      (let [params (parse-body request)
            accounts (list-accounts params)]
        [:table.table {:id "accounts"}
         [:thead
          [:tr [:th "account id"] [:th "created at"]]]
         [:tbody
          (for [{:accounts/keys [account_id created_at]} accounts]
            [:tr [:td account_id] [:td (str created_at)]])]]))

    (defn date-str [date]
      (let [fmt (java.text.SimpleDateFormat. "yyyy-MM-dd")]
        (.format fmt date)))

    (defn account-stats []
      [:section.hero
       [:div.hero-body
        [:div.container
         [:div.columns
          [:div.column
           [:form.box
            {:hx-post "/accounts-in-range"
             :hx-target "#accounts"
             :hx-swap "outerHTML"}
            [:h1.title "Accounts"]
            [:div.field
             [:label.label {:for "from"} [:b "from "]]
             [:input.control {:type "date" :id "from" :name "from" :value (date-str (java.util.Date.))}]]
    
            [:div.field
             [:label.label {:for "to"} [:b " to "]]
             [:input.control {:type "date" :id "to" :name "to" :value (date-str (java.util.Date.))}]]
    
            [:button.button {:type "submit"} "list accounts"]]
           [:div.box [:table.table {:id "accounts"}]]]]]]])
    
    (defn home-page [_req]
      (render
       [:html
        [:head
         [:link {:href favicon :rel "icon" :type "image/x-icon"}]
         [:meta {:charset "UTF-8"}]
         [:title "Account Stats"]
         [:link {:href "https://cdn.jsdelivr.net/npm/bulma@1.0.0/css/bulma.min.css" :rel "stylesheet"}]
         [:link {:href "https://unpkg.com/todomvc-app-css@2.4.1/index.css" :rel "stylesheet"}]
         [:script {:src "https://unpkg.com/htmx.org@1.5.0/dist/htmx.min.js" :defer true}]
         [:script {:src "https://unpkg.com/hyperscript.org@0.8.1/dist/_hyperscript.min.js" :defer true}]]
        [:body
         (account-stats)]]))

    (defn handler [{:keys [uri request-method] :as req}]
      (condp = [request-method uri]
        [:get "/"]
        {:body (home-page req)
         :headers {"Content-Type" "text/html charset=utf-8"}
         :status 200}

        [:get "/accounts.json"]
        {:body (list-all-accounts req)
         :headers {"Content-Type" "application/json; charset=utf-8"}
         :status 200}

        [:post "/accounts-in-range"]
        {:body (render (render-accounts req))
         :status 200}

        {:body (str "page " uri " not found")
         :status 404}))

    (defn read-config []
      (if (.exists (io/file "config.edn"))
        (edn/read-string (slurp "config.edn"))
        {:port 3001
         :db {:dbtype   "postgresql"
              :host     "localhost"
              :dbname   "postgres"
              :user     "postgres"
              :password "postgres"
              :port     5432}}))
    
    (defn run []
      (let [{:keys [port db]} (read-config)]
        (reset! conn db)
        (when-let [server @server]
          (server))
        (reset! server
                (srv/run-server #(handler %) {:port port}))
        (println "started on port:" port)))

    ;; ensures process doesn't exit when running from command line
    (when (= "start" (first *command-line-args*))
      (run)
      @(promise))

    (comment
      ;; restart server 
      (do
        (when-let [instance @server] (instance))
        (reset! server nil)
        (run)))

I agree. It's a breath of fresh air in the Clojure world. I'm grateful to thoughtful builders like yourself and borkdude for bringing the language to new heights.

Babashka is definitely the most exciting thing currently happening in Clojure world in my opinion. And thanks, always great to hear my stuff ends up being useful. :)

Another website in this vein is https://www.maria.cloud/ which is more geared up for teaching complete beginners programming, but I think with the basic paredit style controls and the evaluate-each-form-at-a-time style is I think a lot more realistic to the kind of REPL driven development that you actually use — typing directly into the REPL terminal window is very unergonomic imo. You’re much more likely to use something like VSCode’s Calva or emacs’ cider to send the form under the cursor to a REPL process somewhere.

the best reason to learn clojure is reagent[1], by far the best way to use react.

shadow-cljs[2] makes using npm libraries easy.

i’ve settled on go backends and reagent frontends as my default setup[3].

1. https://reagent-project.github.io/

2. https://github.com/thheller/shadow-cljs

3. https://github.com/nathants/aws-gocljs

Reagent is nice and has been around for about a decade now, but I moved away from it towards very thin wrappers around React[1], because I felt like it was adding too much additional complexity on top of React, which is already quite complex on its own. I wanted a clearer view at what is going on and a simpler way to interop with native React components.

Although it seems to catch up with experimental support of React 18 now, Reagent has fallen behind the latest developments in React and may not benefit from all of its performance optimizations. It is still using class components instead of hooks and there have been concerns that the runtime conversion of Hiccup may drag down performance. I guess in most cases it is not really an issue or in any way noticable, so if you’re not doing any fancy stuff it should be fine. I may even come back to Reagent at some point, since I have to admit that I miss the UI-as-data model with Hiccup.

What I highly recommend, however, is using re-frame[2] for state management. It has also been around for a long time (2014, around the same time Reagent came along) and pioneered some popular ideas in that area. It may seem a bit overwhelming at first, but the docs provide a great introduction and I find the model very clear once you wrap your head around it. At the moment it depends on Reagent, but there are ways around that. [3]

[1]: see Helix (https://github.com/lilactown/helix) or UIx (https://github.com/pitch-io/uix)

[2]: https://day8.github.io/re-frame/

[3]: refx (https://github.com/ferdinand-beyer/refx) is an almost drop-in replacement without the Reagent dependency, but hasn’t been updated in a while. Alternatively, re-frame can be integrated with UIx/Helix by adding some interop code https://github.com/pitch-io/uix/blob/master/docs/interop-wit...

you think reagent is more complex?

i don’t even know what the difference between hooks and classes are, reagent has never given me a reason to care.

if that’s not simplicity, i don’t know what is.

if i were to build a 3d high performance game in react, maybe i’d experiment with dropping reagent. instead i’d just use cpp.

not sure why people want yelp complexity websites to be 3d games.

i love react! i absolutely do not care about the details. never have…

Completely agree. Though I’ve also found an Elixir backend works well because of the power of the Beam VM.

Does your setup do code splitting, SSG? I can't really be shipping a blank html file in 2024, destroys SEO. Otherwise am interested in trying.

no, i’m not interested in seo.

this setup is a single go binary that serves a single pre-gzipped html file from a lambda.

that html file contains inlined js, that is a reagent app.

there is also a favicon. total of 3 files in the lambda zip.

you desired setup is certainly possible though. you’d probably want clojure on the backend though, so you could more easily do SSG.

I loved my stint with Clojure, highly recommend it (https://eli.thegreenplace.net/2017/clojure-the-perfect-langu...)

Clojure for the Brave and True by Daniel Higginbotham is a truly great resource to learn Clojure. I highly recommend it. It is also free online [0].

[0]: https://www.braveclojure.com/clojure-for-the-brave-and-true

I think the writing style is too fluffy, but I realize some people like that. The true sin of this book is that it actually starts by teaching the reader Emacs, not Clojure. That's a huge distraction for a beginner who is probably coming from VSCode these days.

Seconded. I'm also a big fan of Aphyr's "Clojure from the ground up" series: https://aphyr.com/posts/301-clojure-from-the-ground-up-welco...

Agreed. Perhaps using VSCode with the Calva plugin if the reader has no previous experience with Emacs.

I have to admit, several years ago, a colleague of mine advised me if not to try Clojure but at least to read the "History of Clojure": https://dl.acm.org/doi/pdf/10.1145/3386321, which I never did. But one day I decided to watch Rich Hickey - Greatest Hits https://changelog.com/posts/rich-hickeys-greatest-hits... I then read the "History of Clojure", and then jumped into learning it. This is probably one of the most fun languages to build with and one of the most beautiful ones. If not syntax-wise, rather in a way it allows you to express your thoughts via good design and composition that so nicely tickles your brain. If you are still searching for that one shiny tool, and none of them clicks, maybe try Clojure. It's one of the most concise and yet powerful languages I've seen.

I got what you described by learning Common Lisp just a few months ago. Do you think learning Clojure would get me something in addition to that or is it roughly the same?

> Do you think learning Clojure would get me something in addition to that

For me, the biggest benefit is that it's hosted. Learning only Clojure, I can easily today write for JVM, .NET, JavaScript, Flutter, or shell scripts. Even when I need to write Lua, I'd usually pick Fennel. It's not Clojure but feels very similar. There are libs that can give you Python or R interop from Clojure. There are projects to target Golang, Rust or Erlang. Jank is a super interesting, experimental implementation of Clojure that runs on LLVM, I'm very excited about it. Do you want to become a true polyglot programmer? You only need to learn Clojure.

>For me, the biggest benefit is that it's hosted...I can easily today write for JVM, .NET, JavaScript, Flutter, or shell scripts.

Isn't CL better for this? You are not bound to some VM and you can produce native binaries.

I think Clojure leans into immutability a lot, and that leads to more interesting APIs and norms that are valuable. CL has always felt a bit more.... "running on a machine" that I feel has less of a place in an era where everyone and their dog has functional programming essentials built in.

Clojure is interesting, but some Clojure APIs (stuff like Spectre) is "I want this everywhere now" stuff.

Clojure also teaches you functional programming, where-as CL only teaches you the LISP beauty. Clojure teaches you both Lisp and Fp. So the FP part should still be worth it even though you got the Lisp part from CL.

How does fp in clojure differ from fp on common lisp?

Depends on your style of programming CL. Clojure is immutable by default with a heavy emphasis on concurrency and strong ties to the JVM as its host environment. The differences you’ll find mostly lie in those areas.

IMO, Clojure is superficially/syntactically much more elegant and beautiful than Common Lisp or Scheme. I find this really helps you focus on what matters most.

really good talk from Rich Hickey: Clojure for Lisp Programmers - https://www.youtube.com/watch?v=cPNkH-7PRTk&t=3837s

Besides the superficial syntax, those are some differences pointed out by (common) lispers: https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1...

Clojure uses immutable lists, vectors, hashmaps, and sets. Also it has syntax sugar such as [1 2 3] for vectors, {"Jan" 31 "Feb" 28} for hashmaps, #{1 2 3} for sets, and much more. Also it has multimethods which are even more generic than CLOS.

Is there a version of Clojure that compiles to LLVM or something? Sort of like what Scala-native was supposed to be (but never materialized). I like functional programming but I can't abide the Java ecosystem in 2024, it's just too archaic for my taste.

There's an ongoing effort to create a Clang/LLVM implementation of Clojure's runtime with hot reloading and other very interesting features. You can take a look at it at https://jank-lang.org/. It still hasn't reached feature parity with full blown JVM Clojure but we've paying close attention to its development.

the top comment as of writing this reply points to https://babashka.org/, but it's GraalVM instead of LLVM (which shouldn't really bother you)

Babashka scripts are interpreted, the babashka binary itself is compiled with GraalVM.

But: you can also build regular Clojure programs using GraalVM and create a fast-starting binary.

Soon there will be! https://jank-lang.org

Do they have a realistic shot at implementing immutable datastructures?

Oh for sure. That's not the tough part. :)

jank uses immer for that: https://github.com/arximboldi/immer

https://jank-lang.org/

Try Clojure – An interactive tutorial in the browser - https://news.ycombinator.com/item?id=30423856 - Feb 2022 (93 comments)

Try Clojure in your browser - https://news.ycombinator.com/item?id=3366526 - Dec 2011 (26 comments)

Try Clojure - https://news.ycombinator.com/item?id=1359682 - May 2010 (60 comments)

Clojure is becoming popular in Mexico, and I'm guessing Brazil may see a similar situation, because of nubank. It is a popular destination to go work there for computer scientists, and they seem to work mostly in Clojure. I seem to remember they even employed some of the core members of the language? I think at some point they also bought the company of Jose Valim (Elixir's creator), but I think they are still mostly a Clojure shop.

Nubank purchased Cognitect (the consulting company behind Clojure) in 2020, as well as Platformatec (employers of Jose Valim); the latter was for access to Platformatec's project management expertise (see https://building.nubank.com.br/tech-perspectives-behind-nuba... there is no Elixir code running at Nubank AFAIK.

There is Python on the "other side" of the ETL pipeline, but everything user-facing is (again AFAIK) Clojure on the backend and TypeScript in the Android and iOS apps.

I often encounter Clojure Chinese users (at least Chinese sounding names, don't know about their nationality). I wonder if Clojure is a thing in China ?

no. But because of the population, even 0.0001% of developers using it, it still has an observable impact on the community.

Maybe online "learn lisp" repls should implement paredit keybindings in their editor and have a short section on how to manipulate s-expressions. Because you're gonna have to learn it to use the language, but it also helps people understand from the start that "oh, so using the language isn't actually complete shit".

Instead, this fact always seems glossed over, and because of it anyone who spends 60 seconds writing lisp by hand into a repl assumes that's the lisp experience and nopes out forever. When in fact paredit makes lisps the easiest-to-edit languages in the world.

I spent a few months writing a decent sized Clojure program just using my IDE's matching bracket highlighting and some sort of rainbow parentheses settings, and never found it very annoying. I'm not sure there are that many more parentheses than curly-bracket languages, it's just that all of the closing parentheses are more likely to cluster together at the end.

> When in fact paredit makes lisps the easiest-to-edit languages in the world

That is true and whenever I switch from Clojure to C, I immediately feel the pain (what do you mean I can't just kill or lift this entire expression?).

But structured editing has a learning curve, so it's a difficult balancing game. Beginners are overwhelmed by all the parentheses, while experienced programmers don't even notice them and love the structured editing approach.

At the very least they should have auto-closing and matching parens. I dread to think how many people have been put off Lisp because they think we actually type all those parens (in fact Lisp users have enjoyed IDE features many programmers could only dream of for decades).

I remember trying Clojure a few years ago, and Racket, and had similar problem with both... feels like everybody doing LISPs is using Emacs and it was hard to get a decent set up in VS Code configured and working properly

Or Parinfer. I personally like Parinfer more than Paredit, mainly because I can't be arsed to learn a gazillion keyboard shortcuts.

Oh, interesting. Yeah, that's even better for an onboarding tutorial. I didn't know it existed (used Clojure for 6 years a long time ago).

Cool: https://shaunlebron.github.io/parinfer/

I always thought that the surrounding tooling (having to learn how to edit parens productively, using nrepl/cider, maybe even emacs... with evil-mode of course) to be both the worst and then eventually the best parts of Clojure.

I'm one of those mainstream devs (who also did Clojure for 6 years, coincidentally) who never got into emacs, and always just used the Cursive IDE plugin for IntelliJ and its Parinfer editing mode. I know I probably didn't unlock true god mode of productivity, but it worked fine for me.

TryClojure author here. Thanks for the suggestions! I’ll look into adding parinfer soon and maybe add a section on the benefits of integrating Clojure with the editor.

I use Helix [0] myself, which has tree-sitter based commands for moving + selecting up/down/forward/back by expressions. These are built-in and require no configuration.

It's surprisingly excellent! Sure, the "language" of paredit features more powerful text manipulation that just simple movement... but combined with the new "jumping" in the latest Helix release [1], it makes for a very impressive keyboard-based navigation system.

[0]: https://helix-editor.com [1]: https://helix-editor.com/news/release-24-03-highlights/

I still remember Professor Brian Harvey rolling out his terminal on a cart in Berkeley's CS61A and typing out commands in a scheme repl. Learning what a y-combinator was with Structure and Interpretation of Computer Programs, and building my own scheme compiler with scheme.

Oh wow, I didn't know that "Y-Combinator" was not just a fancy name but was an actual computer science concept. Thanks!

https://combinatorylogic.com/table.html it's hard to read, but there's a ton.

ClojureScript Koans is also quite nice: http://clojurescriptkoans.com/

There is XSS in the (my-name) part :)

(my-name "<img src='#' onerror=alert(1) />")

It's not XSS if it's not cross-site.

Nice catch. Is it an issue though when the script injection only runs within your own browser session?

No. That in itself shouldn't be a cause for concern. Local users can do anything to their own machines already. It would be a concern if you persist this to then later be loaded by someono else's machine.

Shameless plug: If you’re looking for an online compiler specifically designed for conducting interviews in Clojure, you might find [0] very useful. It’s designed to streamline coding interviews with real-time collaboration features.

[0] https://codeinterview.io/languages/clojure

My favorite part of working in clojure is how easy it is to do common data structure operations.

map, filter and reduce are extraordinarily powerful, especially when combined with the other core library functions.

With Specter [0] to lend a hand for more uncommon operations. ;)

[0] https://github.com/redplanetlabs/specter

I wonder why no functional language has the degree of success imperative or OOP languages have.

Is functional programming too weird for majority of computer programmers? Is functional programming not optimal for solving industry problems? Maybe there is no functional programming that that is up to some set of standards? Is functional programming too complicated?

I do enjoy functional programming myself, and while I don't use a functional programming language at work, I try to use functional programming paradigms when I finds it suits the probem.

There are degrees and different shades of "success" and "functional programming".

Clojure is successful, stable and well maintained. However it is a niche language compared the big mainstream languages. It takes a functional approach by default, but doesn't shy away from other paradigms/patterns/idioms when appropriate.

Functional programming itself has had a huge influence on mainstream languages since about a decade and a half. More and more pragmatic features have been introduced in mainstream languages. Newer languages have adopted functional idioms from the get go. On the macro level as well, ops and architecture have been adopting statelessness, reproducibility and so on.

The consensus has shifted towards containing state. The more moving parts you have, the harder it gets to reason about a whole thing. Treating data as data.

OOP has also changed and got refined over this time. I think people realized that it has good ideas (generic interfaces, polymorphism etc.) and bad ideas (inheritance, local state etc.). Same thing with FP, there's stuff that's esoteric and too far from the reality of actual programming and stuff that is pragmatic and simplifying in there.

Functional programming languages haven't gone mainstream but functional techniques are very common now.

Higher order functions, immutable data structures, declarative UI frameworks, etc are things you're quite likely to encounter in a contemporary codebase these days.

That's what I said. I do use functional programming techniques, I just wonder why functional programming languages don't see a larger following.

So here's something which I, as a Lisper, don't understand: Clojure has syntax for hash tables (the curly braces), why doesn't it use those for let-bindings, instead choosing to use vector syntax? (Of course I prefer standard Lisp syntax which can easily be extended for multiple-value and destructuring bindings:

  (let ((a 1)
        ((b c) (list 2 3))
        (d e (values 4 5)))
    `#(,a ,b ,c ,d ,e))
  ;; => #(1 2 3 4 5)

Maps are unordered, but let bindings are sequential so order matters.

And also, a variable can be rebound in later bindings!

I see, so Clojure's let works like Lisp's let*. I didn't know that, thanks for the explanation!

Clojure has some very expressive destructuring syntax as well: https://clojure.org/guides/destructuring

What's so different to Clojure's ?

    (let [a 1
          [b c] (list 2 3)
          [d e] [4 5]]
      `(~a ~b ~c ~d ~e))
    ;; => (1 2 3 4 5)

But what would be the equivalent of:

  (let ((quotient remainder (floor x y)))
    (+ (* quotient z)
       (* remainder (floor z y))))

Where floor is a function which returns multiple values rather than a list or vector of results?

Also, but this is entirely on me being an absolute dullard, I like having the brackets around each binding as a kind of guardrails for my mind to not lose track of where I am and what belongs where.

It's just:

    (let [[quotient remainder] (floor x y)]
      (+ (* quotient z)
         (* remainder (first (floor z y)))))

Because in Clojure there's no multiple value bind, when you want to return many results from a function, you wrap it in a vector, and that means you than just destructure that vector. That also means, it's not smart enough to know if it's used in a single value context or multi value context, so you need to always get the value out of the vector, which is why I call first in that second call to floor.

this example shows how "elegant" closure treats syntax errors, almost looks like a bad joke.

=> (+ 2 2 + 3)

"4function Cg(a){switch(arguments.length){case 0:return Cg.s();case 1:return Cg.g(arguments[0]);case 2:return Cg.h(arguments[0],arguments[1]);default:for(var c=[],d=arguments.length,e=0;;)if(e<d)c.push(arguments[e]),e+=1;else break;return Cg.j(arguments[0],arguments[1],new gc(c.slice(2),0,null))}}3"

That's a bug in the JS interpreter they're running, not anything related to Clojure. Also, that's not a syntax error

Not a syntax error. TryClojure is running on SCI which is a interpreter that uses a Babashka version for Clojurescript compiler, not Clojure JVM.

Babashka cli returns this, telling you clearly what the error is:

   user=> (+ 2 2 + 3)
   java.lang.ClassCastException: clojure.core$_PLUS_ cannot be cast to java.lang.Number [at <repl>:1:1]

for some stories on Clojure in production, check out https://www.juxt.pro/clojure-in/

That's a great introduction, but... how to do an if statement would've been cool to add in the tutorial.

What is this "statement" you speak of?

(if (= 2 2) :OK :nope)

see, that was missing from the tutorial, or did I miss it? :ok and :nope - are those valid keywords or functions?

I love clojure, but it's really lost a lot of the momentum it had as many imperative languages have adopted parts of functional programming (and much for the better) over the last many years.

On the other side I've felt a lot of the ecosystem work that was done has a more "timeless" quality. Coupled with java interop I haven't ever felt wanting when I do reach for it for some hobby projects I keep up with.

One thing I will say, since it takes a different tack and philosophy, I think any programmer learning some of it benefits from the different perspective.

In my experience, the subsets of the community around clojure were one of the biggest problem with it. It's gotten better over the years, but circa 2016 - 2018 it had a spike in popularity despite being very hostile to newcomers.

There was an almost apologist attitude towards rough edges or failure modes folks new to the community would fall into. I managed to work with it for a time despite that, but it left me with a bad taste in my mouth. It's really important to make your ecosystem and communities welcome to new users or they're destined to fade.

  > ...had a spike in popularity despite being very hostile to newcomers.

To be fair the community itself, as humans, was very welcoming to newcomers. Really super nice and helpful folks.

If anything was "hostile" it was the dominance of emacs and very limited options for other tooling. That, and the horrifically unhelpful leaky abstractions in the stack trace when something went wrong. It's a big step, if you don't already know emacs to learn emacs (at a fairly advanced level) AND a new very different programming language.

I see now there's a vscode option with Calva. I haven't tried it. Might do that someday. Really wanted to like this language!

I'll second that the popular tooling, while powerful and reliable, its just not user friendly.

The official Clojure CLI, for example, is just plain confusing, and that's most people's first impression to the entire ecosystem. The config files, while they use the wonderful `.edn` format, are also not intuitive. Newcomers are the most likely people to encounter the most amount of error messages... which are famously difficult to read.

And that's before you even get into REPL configuration, which involves coordination with your editor process, a client process, and a server process. Even if you have a tool like Calva or CIDER managing it for you, you'll still get confused when something goes wrong unless you grok all the moving parts.

Even if you figure that all out, you still don't have Parinfer or equivalents setup yet in your editor. Also, clojure-lsp tends to require some configuration to get working the way you want. And that's before you get started with ClojureScript, which brings the complexity to another level entirely.

Despite all this, I love Clojure. It's an expert's language, even though it shouldn't have to be. Once you learn this stuff, you respect why much of this complexity exists. It's inherent to the amount of power the language gives you.

But doesn't mean we can't make it easier to use and get started with.

This matches my experience as an amateur programmer. The initial hill was steep, but I don't think it was because people weren't friendly.

There is one cultural thing that might be confused with unfriendliness. Sometimes people react badly if someone posts incorrect information. But I think that's good. When you search for information about Python or PHP you have to wade through quite a bit of junk. Ironically, it's sometimes easier to find correct answers for Clojure.

Clojure itself is very clean and consistent, it's got a lot of polish to it, which makes it comparatively easy to learn. And there isn't that much of it. But for a long time the tooling was hard.

That's far less of a problem than it used to be. deps.edn and shadow-cljs both made things easier, as has Cursive. People say nice things about Calva, but I don't know it.

I'm a big fan. Babashka alone is enough to make learning Clojure worthwhile. Also, for someone like me, it's kind of nice that it feels almost finished. Once you learn it, you know it, and now that the tooling has settled down a bit you don't have to keep running to keep up.

the tooling is the reason i gave up when i was interested in learning clojure. everywhere pretty much said that emacs was the "correct" editor to use for clojure, i tried it out for a bit but ultimately learning a new language and a new editor at the same time was just too big of an ask.

i tried calva with vscode afterwards but it was basically the same thing, calva has paredit which overrides the keyboard navigation and there was no way to disable it. somebody had asked for the option to disable it on the github but the creator said something along the lines of calva without paredit wasn't the way he wanted it to be used, so i just picked another language to learn.

Cursive plugin for IntelliJ is a fantastic option, it's not free but it is excellent.

clojure-lsp and clj-kondo work with any editor and are both excellent.

https://github.com/clojure-lsp/clojure-lsp

https://github.com/clj-kondo/clj-kondo

I've always used (Neo)Vim with Clojure.

A somewhat similar thing I ran into is that existing Clojure code can be incredibly difficult to grok if you don't already know the language very well.

Some of this comes from lisp's minimalist syntax, which makes it hard to even know what kind of thing you're looking at when you're encountering a new thing for the first time. But the problem is also compounded by some of Clojure's more distinctive (and powerful) features such as ad-hoc polymorphism and using maps to pass function arguments.

The closest analogy from imperative languages that I can think of is another language that's famous for being incredibly productive in the hands of a skilled user, but whose code tends to feel kind of write-only: Perl.

In Perl you have the dynamism, and the syntax.

Evidently, 93% paint splatters, when OCRed, are valid Perl programs:

https://www.mcmillen.dev/sigbovik/2019.pdf

I doubt that a similar thing is true for Clojure.

Here, the only problem is that you don't know what the symbols and some of the notations mean. You can look at the unfamiliar syntax and know what is a child of what. Most operators are words you can search for.

If I can get clojure storm running in my project then I find a lot of code incredibly straightforward

Because there's a preference for just passing immutable data around the time travel debugger really helps me understand complex interactions

YMMV. I always found it very welcoming and full of interesting people.

I may be wrong, but I think the parent poster was talking more about the language and ecosystem than the community. I, too, have found the community to be amazing. But the language itself used to be quite frustrating to learn. It's better now, but I think that by the time it got fixed many companies and teams had already been burned.

Clojure is particularly vulnerable to that because it really is an enterprise applications language. That makes it more vulnerable to learning curve problems than a language like Rust whose most direct competitors are other languages with comparably steep learning curves.

That is basically every functional programming language in existence.

> many imperative languages have adopted parts of functional programming

nailed it. I don't know much about functional languages other than a haskell course back in the day, but I don't want to do functional all the time. It plays great in some situations and I am happy to use those language subsets in my daily coding, but I don't need my entire application to be written in an esoteric language

This is of course a popular opinion and pretty much the C++ philosophy. Unfortunately a lot of the benefits of functional programming cannot be fully realised unless you are "all in". The paper "The Curse of the Excluded Middle" is somewhat blunt but it makes some good points: https://queue.acm.org/detail.cfm?id=2611829

Programming without immutability is so painful to me, no matter how many functional features a language adds.

>a lot of the benefits cannot be fully realized unless you’re all in

That is working under the assumption that “the benefits” are actual benefits.

IMO, “the benefits” are measurably drawbacks, and not a technical debt I am willing to accept for no good reason.

Should have maintained a python interoperable runtime. Less and less people use JVM languages for things like web apps, data eng, data science, ML, etc.

https://github.com/clj-python/libpython-clj has deep support for leveraging the Python ecosystem and it works great.

Give https://github.com/basilisp-lang/basilisp a try

Briefly looking through this it reminds me of hy

the Scicloj stack https://scicloj.github.io/

in my opinion competes with python when it comes to DS/ML. I find it a lot more comfortable to use if you use emacs bindings

Clojure looks productive. What frameworks libraries do people use to build web apps? Like, replacement for Django view layer and ORM (not looking to debate orms thanks)?

This is a good starting point if you want to get a web app going quickly: https://biffweb.com

It uses XTDB by default but you can switch to Postgres: https://biffweb.com/p/how-to-use-postgres-with-biff/

People don't really use ORMs in Clojure, they just write SQL directly and abstract the details from consumers using functions. That said, HoneySQL is a common alternative to writing SQL that makes it a lot less painful (and composable!): https://github.com/seancorfield/honeysql

HoneySQL is so, so good. It does for SQL what Hiccup did for HTML. Once you start writing with those, it's hard to remember there's any other way.

Totally agree! or datalog is even better if you can accept not using the mainstream databases.

Biff looks neat, thanks! I mainly just don't want to write raw sql/mappers to structures for simple queries. Looks like most sql libraries with clojure can just return maps so that's neat.

Here's a quick example of how DB access generally looks in production:

    (ns rads.sql-example
      (:require [next.jdbc :as jdbc]
                [honey.sql :as sql]
                [clojure.string :as str]))

    ;; DB Table: posts
    ;; +----+-------+
    ;; | id | title |
    ;; +----+-------+
    ;; |  1 | hello |
    ;; +----+-------+

    (def ds (jdbc/get-datasource (System/getenv "DATABASE_URL")))

    (defn row->post [row]
      ;; This is your optional mapping layer (a plain function that takes a map).
      ;; You can hide DB details here.
      (update row :title str/capitalize))

    (defn get-posts [ds]
      ;; Write a SQL query using Clojure data structures.
      (let [query {:select [:*] :from [:posts]}]
        ;; Run the query.
        (->> (jdbc/execute! ds (sql/format query))
             ;; Convert each raw DB map to a "post" map
             (map row->post))))

    (println (get-posts ds))
    ;; => [{:id 1, :title "Hello"}]

There's no object in Clojure, so there's no need for an Object Relational Mapper. You just work directly of the query result sets, which the SQL library itself can conveniently turn into rows of maps if you prefer (over rows of lists).

There is not a batteries included framework a-la Django or Rails for Clojure. I would argue that is one of the biggest pitfalls to the language/ecosystem. If you are building a web application, you will need to invent the entire thing yourself. There are micro frameworks and tools that exist standalone to deal with HTTP, DB ORM, etc... but that will be an exercise left to the reader.

Some will say this is a good thing (and as a very experienced engineer I will agree) but the barrier to entry for a newbie is quite high in this regard. You have all the rope to hang yourself with - and you will. Especially if you are on a team full of lots of interns and junior folks.

The closest to this (MVC framework with all features including migrations, API building, auth...) is Xiana https://github.com/Flexiana/framework/

This framework looks like an absolute nightmare to use.

This is my goto:

webserver: ring-jetty9-adapter[0]

routing: reitit[1]

html templates: hiccup[2]

never used an ORM, but happily used HugSQL for making composable queries[3].

[0]https://github.com/sunng87/ring-jetty9-adapter [1]https://github.com/metosin/reitit [2]https://github.com/weavejester/hiccup [3]https://www.hugsql.org/

Those all look great, including HugSQL, thanks!

Check out Biff, it's very thoughtfully made: https://biffweb.com

It's kind of surprising the most popular(?) web framework uses a weird/obscure db

I have no doubt that XTDB is good, it is just surprising as a first choice and is not going to be easy to get up and running compared to the conventional alternatives

(Is there even a hosted offering for XTDB? I like that it's open source but seems that you will have to grapple with all this stuff including a Kafka cluster https://docs.xtdb.com/guides/starting-with-aws.html)

Isn't it tiring to type so many parenthesis all the time? This is probably my first time encountering a Lispy language, other than Logo.

The number of parentheses is the same, they're just in a different place. Isn't it tiring to type so many semi-colons and commas all the time?

I think it's tiring because before every expression I have to type a (. It's not tiring to type semi-colors and commas because they are very well positioned on the keyboard and I don't have to reach out in the same way as I need to for the parenthesis.

Plus, there are not a lot of semi-colons and commas in JS and Python.

Replace in Python with 4-space / tab indentation.

I know a lot of people think that you write more parentheses in Lispy languages, but actually in most cases you just type them in a different order, e.g. instead of `foo(x, y)` to call a function, you type `(foo x y)` and you even save a comma.

Of course, there are constructs such as `let` and `cond` that are more parenthetically noisy (not so much in Clojure though), but on the flip side you don’t have to remember a lot of special syntax like in non-lisp languages.

Most Lisp-people also use structural editing tools like paredit[1], which make it really easy to write and edit s-expressions. I found that after some time I didn’t really think that much about parentheses anymore.

[1]: https://paredit.org

You're right about the order part and I didn't consider it initially. This is what Fizzbuzz looks like in Clojure:

  (defn fizzbuzz [n]
    (cond
      (zero? (rem n 15)) "FizzBuzz"
      (zero? (rem n 3)) "Fizz"
      (zero? (rem n 5)) "Buzz"
      :else (str n)))

  (defn print-fizzbuzz [n]
    (doseq [i (range 1 (inc n))]
      (println (fizzbuzz i))))

This looks overwhelming for someone who hasn't written any Lisp. My thought looking at this code was that I have to type a parenthesis before formulating any thought. Which is crazy because it's not some huge thing. It's like saying I have to press Enter before writing a line of Python.

<hot-take type="anecdata"> My Clojure experience was that basic dev experience things were shockingly behind where any other moderately popular lang is at. It's been some time though so all I remember clearly is bad error output. Stack traces are hard to read unless you install $random_lib. But worse than stack traces are type errors/"Java errors": if you give the wrong args to a function, the error output is completely inscrutable, generally a very short string like `java.lang.Foo does not implement IBar`, which is only helpful if you kind of know how the Java layer works and all your args are different enough types that you can guess which one it's talking about (bonus: anything function-like is just `IFn` so good luck). Ahhh and that made me remember: the doc situation even for stdlib is bad. Everyone around me used a third-party site clojuredocs.org which has broken-formatted auto-ingested versions of the plaintext official doc strings, because it is still the least bad option. No one has decided on a docstring format. No one has decided on code stylistic things either, which has mostly precluded the existence of auto-formatter tools.

The lang itself is good and I recommend folks use a LISP sometime. I was just genuinely surprised a 17-year-old lang was lacking in these areas, and I'd be pretty careful about setting out on a long-term project with it, unless all of those things have radically improved from 6 months ago.

(And like other folks said, you genuinely need editor integrations to not be wasting all your time on pren balancing. Not clj's fault, just LISPs in general.)

I'm an advocate for Clojure, and while I believe that the usability speed bumps are more than made up for, I completely agree with you. The awkwardness of Clojure's errors, REPL experience, and build tooling is a dealbreaker for many.

A couple years with Rust has taught me that intuitive errors and tooling will funnel you far enough into language to get you productive, and then you're much more likely to stay. There's just no way I would have stayed long enough to be a Rust professional if it hadn't been for cargo and rust-analyzer.

These "non-language" components of Clojure are just not easy enough to use, and its inhibited Clojure's growth. If, however, you do put in the time to grok these parts, the joy of using the language itself never fades.

Along the same lines with the docs, I also find it frustrating that a lot of the very most core basic abstractions and interfaces are left totally undefined in terms of documentation. Take `ISeq`'s definition. Surely, a candidate for the single most core interface.

https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

But like, where is the javadoc? What exactly is supposed to be the contract of these methods `first`, `next`, `more`, `cons`? What's the difference between `next` and `more`?

I really just don't like that. Are we just supposed to pick up the core contracts/abstractions through oral teachings and slack channel messages?

You don’t use the ISeq interface directly, you use them through the clojure.core API. The seq abstraction is documented at https://clojure.org/reference/sequences

It’s rare for an application developer to need to use ISeq, but library authors do use of when they want to implement custom seq’s right? For them, and also just for those curious to understand how the core interfaces work, it’s still better to be explicit and write what the contract is I reckon.

this is super neat! how did you set up your fonts folder? what tooling did you use?

Fonts included in the repo. [0]

Tooling is a combo of Shadow CLJS and Clojure CLI.

[0] See `resources/public/fonts` here: https://github.com/eliascotto/tryclojure/tree/main/resources...

[1] https://github.com/thheller/shadow-cljs

[2] https://clojure.org/reference/clojure_cli

Clojure is a really interesting and well designed language with bad error messages and bad official tooling. It feels very sloppy.

Compared to Go, it has a weak stdlib, is more memory intensive, and generally slower. You get beautifully concise code but it can be very hard to follow (or return to after time away).

Go can look completely idiotic or unbelievably focused and practical, depending on the light. It is painful to give up Clojure’s very strong selling points but I find alternatives to be more pragmatic.

"weak stdlib": You can use the Java ecosystem, most of the things you need are there

"it can be very hard to follow": I agree, if you are not a lisp developer it's really hard, but if you develop clojure everyday, it's as easy as anything else.

The answer is usually clean code when it comes to clojure. Keep your functions small.

"more memory intensive, and generally slower": yep, the JVM is more memory intensive than Go. No surprise there and Clojure adds up on top of that. Startup times are pretty slow too. But compared to python it's still fast. Apples to oranges.

I would say Clojure and Go are both great languages that tackle different problems so it's not a fair comparison.

Having projects that make significant usage of interop feels kind of gross, but I guess that is an option yeah. Pig-latin java is probably less fun to write than Go.

Regarding difficulty reading code, I'm not talking about syntax, I'm talking about the fact that many libraries define their own DSLs and you _cannot understand what they are doing_ by reading the code, you have to dig into the library internals to make sense of how they actually work, particularly when documentation is lacking or outdated.

Many problems can be solved by either language, and I wish it was easier to justify reaching for Clojure.

If you ever need a clojure boilerplate to start a SaaS product or a startup, there is https://shipclojure.com

I found the red over gray combination a bit hard to read, so I checked it with a color contrast calculator:

The contrast ratio here is 3.9:1 (text #DC2626, background #E5E7EB), and the minimum recommended for small text is 4.5:1.

Sorry to be that guy :) I am enjoying the tutorial.

I know many people will have problems with this post, but I am posting as information for clorjure-ophiles. Not reasons, but personal reasons why I don't do Clojure and will not try it.

1. When I read about Clojure (repeatedly) I like it. I am especially interested in transducers. I even built a half baked transducer engine in JavaScript using generators. There is clearly something here of value here. Any system that can produce transducers is worth learning.

2. I spent too many years of my life on Java. It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two. I understand the "good" of Java, but for me personally, the cost of that good is just incredible tedium. This is personal and I understand that.

3. However, as soon as I get to the part of installing Clojure where you install a JVM, I start hearing voices that say "It ain't me babe" and "Just say no to Java". PTSD?

For a while there was Clojure-script and I started working with that, but it seemed to fall off the edge of the world.

I will happily try Clojure again if it will compile itself or if it does not require the installation of a JVM. [ And last but not least of irrational reactions- anything associated with Oracle is to be avoided like the plague. sorry]

[Edit: then I saw the stuff about Babashka so I will give that a try]

Running on the JVM is one of the best things about Clojure. The JVM is an impressive piece of engineering where uncounted bajillions of man-hours were invested into making a good and performant VM with modern GC.

I've been using Clojure heavily for the last 9 years or so and I can't see any reasons to dislike the JVM. Also, I barely ever touch any Java. You don't need to.

I can hardly write a correct Hello World in Java. I can read it, I can probably write it, but I've never really used it. Yet I've been writing Clojure daily for the last 9 years.

This means that you really don't need Java in order to use Clojure.

Coming from a C++ background, I used to dislike the JVM out of principle just like yourself, especially since it needs to run on my local machine and it uses so much memory and is slow to start up.

However, once your app is started, you're in the REPL and that's the only time you need to start your app.. You can keep developing for days without restarting your app once.

Once I finished developing my app and I deploy it to a server, I'm kind of happy it runs on the JVM - that thing is super tuned, very fast and runs on a myriad of hardware platforms.. I don't have to spend one minute thinking about those details.

So while the JVM is somewhat inconvenient on the dev machine, it helps a lot when you deploy it to production.

Things became a lot simpler when I stopped worrying about it and just used the language for its power and beauty.

And if you do need to touch Java for reasons Clojure doesn’t impose, the interoperability story is really good.

I’ve done this with internal libraries - it’s easy to get them pulled into a Clojure code base, wrap them in such a way that the ergonomics of the rest of your code aren’t ruined, and still treat them as a first class citizen for stuff like your build system, artifact stores, etc.

Clojure 1.12 (which is nearly done) is going to add a bunch of interop support - method values, array class syntax, Clojure fn -> Java functional interface conversion, stream support, etc.

I also cannot stand Java (not the technology, but everything surrounding it - bean factories, J2EE, Tomcat, war files, maven, insane unhinged class paths etc) but honestly one of the reasons Clojure is amazing is that it allows you to exist inside of the Java ecosystem while also being pretty isolated and walled off from it. It's all the good parts of Java without all the bad annoying parts.

I would urge you to push thru the PTSD and give it another shot.

There is also Clojurescript, which runs on Javascript, and Babashka which is a lighter weight implementation of Clojure for fast startup times that is targeted at things like shell scripts or system programs. https://babashka.org/

Some dialects at various states of maturity:

CLR: https://github.com/clojure/clojure-clr

LLVM: https://jank-lang.org/

Erlang: https://www.clojerl.org/

Python: http://hylang.org/

> It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two. I understand the "good" of Java, but for me personally, the cost of that good is just incredible tedium. This is personal and I understand that.

You understand that this has everything to do with Java and nothing to do with the JVM, right?

It's everything to do with the libraries people pick and not Java the language. Java the language can be extremely concise and expressive. Stop picking Spring and Java becomes fun again.

PHP avoids many of the hassles of deployment that pretty much any other language does.

Slowly repeat after me... "Java and JVM are not the same thing." Do it ten times every morning.. jk. JVM always gets a bad rap because of Java. Matter of fact, JVM is an incredibly good piece of tech.

> I spent too many years of my life on Java. It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two.

Really curious to hear what that was, because I'm having a hard time believing that is true.

I love Clojure. My dream is to be a clojure developer, but there aren't a lot of jobs available and everyone wants 87 years experience.

i wish it was easy to make android apps with clojure. not sure if itd be easier with jetpack compose + clojure or react native + clojurescript.

There’s also clojuredart to do a dart / flutter app. I’ve been working on one, and it’s been pretty pleasant to work on.

The CLJS + RN route is doable. [0] Not familiar with the other approach.

[0] https://github.com/PEZ/rn-rf-shadow

I was hoping it would be longer, like the tour of golang.

As is it basically just shows you how to do arithmetic, which isn't interesting at all.

I love it! But is there a back button or key or command? I'm flaky and I need to re-read things a lot.

It should be trivial to add with all the promise of data immutability :)

(prev-step) ?

Whoa, hacks! Thank you.

Does this end at "Apply functions on lists"?? For some reason I can't get past that!

What's the recommended stack for doing front end development with clojure these days?

Here is where I'd start for the path of least resistance while still using the most modern libraries:

- Dependency management: https://clojure.org/guides/deps_and_cli

- Clojure->JS compiler: https://github.com/thheller/shadow-cljs

- React integration: https://github.com/reagent-project/reagent

- Global state management (optional): https://github.com/day8/re-frame

You might also want a CSS framework. There are some options to write CSS in ClojureScript, but I prefer TailwindCSS which isn't a Clojure-specific thing and it works fine out-of-the-box with `.cljs` files.

You can swap out Reagent for Helix, which is a lower-level and faster wrapper for React. That said, Reagent does work with React 18 just fine and there's tons of docs for it, so jumping to Helix first is a premature optimization IMO, especially if you're new to Clojure.

> (+ 1 2 '(1 2))

> "3(1 2)"

Yup, I'm out.

That's because this is actually ClojureScript (JS under the hood) running as a browser library.

If you try that in Clojure, you'll get:

> ClassCastException class clojure.lang.PersistentList cannot be cast to class java.lang.Number

If you try it in a "proper" ClojureScript dev environment (shadow-cljs), you get nil as a result with this warning:

> cljs.core/+, all arguments must be numbers, got [number cljs.core/IList] instead

Thats actually good to know, I thought this was reflective of Clojure itself.

Clojurescript compiles to Javascript and so inherits some of it's idiosyncrasies.

This is one of the real problems of clojure: you need some knowledge of the host language. It's also one of it's major strengths, and the only reason a lisp managed to get so much (relative) commercial traction.

That has more to do with Javascript being weird than Clojurescript. That would almost certainly throw a good exception when using Clojure / Java.

Fair. I don't mind dynamic typing so much, but I agree that getting clever with automatic type conversion is just plain wat.

(reference to: https://www.destroyallsoftware.com/talks/wat)

I wouldnt call that getting clever, its just a string of what you did

  > (type (+ 1 2 '(1 2)))
    #object[String]

That's JavaScript for you. Here's a talk about the (in)sanity of JS:

https://youtu.be/et8xNAc2ic8

The same under Clojure (on top of the JVM) shall throw a class cast exception.

And the classic “Wat”.

https://www.destroyallsoftware.com/talks/wat

The problem I see with clojure, isn't it missing autocompletes? You work with JVM/typescript libraries, but your editor isn't smart enough to pull types from those into clojure. That slows you down tremendously.

No. When working with JVM/typescript libraries you have their autocomplete information.

If you need method autocomplete scoped to a type you can use the `..` macro for more concise call syntax:

    (ns my-project.core
      (:import (java.util ArrayList Collections)))

    (defn example []
      (let [list (ArrayList.)]    ; ArrayList constructor can be autocompleted
        (.. list
            (add "Hello")         ; The .add method on ArrayLists will be autocompleted
            (add "World")
            (add "Clojure"))
        (Collections/sort list)   ; The Collections.sort method will be autocompleted
        list))

this other form will a also autocomplete everything after the dot (.) to call a method on an object:

    (.toUpperCase some-str)

but the trick with this arrangement is to write that variable some-str first, then if you write . in front of it the autocompletes will be relevant to that object. But I gratuitously used threading macros like .. or -> to make it match java-style code (in other words: (-> some-str (.toUpperCase))).

That's cool, I had no idea. In clojure itself I suppose you eval code and then get autocompeletes from the repl output? -- I mean for stuff with no types

Autocomplete also works for the functions and vars in the namespaces. You don't really use methods in Clojure unless you're doing interop with Java or JS.

Autocomplete works for me with jvm imports

As a Clojure editor tool smith it pains me that this is the case. Especially for ClojureScript where I spend most of my time. I really want to fix this.

For JVM interop, I think Cursive (IntelliJ Clojure plugin) is smart enough to help with autocompleting Java libraries.

Yea, Cursive is the best by far for doing Java interop. It is really good.

I use Emacs with Cider+clojure-lsp, and the autocomplete/refactoring tools are super good.

Clojure will get more adoption if they find a way to make it very easy to build cross platform mobile and web apps like React & React native. They need to keep adding libraries to make the eco-system bigger.

https://github.com/Tensegritics/ClojureDart/

> unlike full-JVM Clojure it has a very fast startup time

I can't believe that after all these years Java still didn't fix their startup time.

The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code generating hundreds if not thousands of classes and then loads them before starting up the Clojure program. Still, there's ongoing work on the JVM (Project Leyden [1]) to speed up both startup and warmup even of such programs by caching more state.

[1]: E.g. see https://spring.io/blog/2023/10/16/runtime-efficiency-with-sp...

>>The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms.

Im yet to reach the X-men level super qualities that can detect, and work in 40 ms chunks. Or at least even notice a 40 ms delays.

I envy the humans who can notice such small chunks of time.

Right, but the problem is that many programs do a lot more work when they start up than Hello, World. The Clojure runtime in particular does quite a lot at startup.

I don't like how this issue is constantly dismissed out of hand. It very obviously is actually a massive glaring issue which severely limits what clojure can reasonably be used for. Nobody would ever accept a 1 second startup time for CLI applications that we use all the time like git, kubectl, npm, docker, etc.

You still don't see many scripts or CLI apps in Java though. I was wondering if that would change now that you can run a source file directly, but then wouldn't the startup be slower, because now it's also having to compile.

Why can't you do some JVM equivalent of memcopy/execve the starting state of the program?

Isn't the initialization procedure (or at least the vast majority of it) exactly the same at each run ?

That's pretty much the idea behind Project Leyden's "premain" work. The tricky bit is that the program startup being almost exactly the same each time isn't quite the same as being exactly the same. The JVM already caches some things and the capabilities of that mechanism are being expanded to cover more, including JITted code as well as some program computations done at initialisation.

Back when I wrote Clojure professionally, using GraalVM to generate a native executable of things like clj-kondo basically eliminated the startup latency.

Right, but Native Image comes with its own tradeoffs. Lyeden's "premain" work aims to be somewhere between the situation today and Native Image.

It's a tradeoff. The startup time of Clojure on the JVM is slower than most, but the runtime is faster than most. It also needs a lot of memory to get going. This means it's optimized toward long-running programs like web servers. During development, you use the REPL interactively which makes this a non-issue, but it does take some getting used to at first.

That said, there are alternative runtimes that have different tradeoffs. For example, Babashka is a runtime for Clojure that uses GraalVM instead of the JVM as the foundation. Babashka scripts have about a 10ms startup time on my M1 MacBook Air.

My understanding is that this isn’t really a JVM thing, but I might be wrong.

Your understanding is correct. JVM startup accounts for a small portion of Clojure's startup time.[1] Most of the overhead is in compiling and loading clojure.core. Efforts have been made to remedy this issue[2] (e.g. direct linking, ahead-of-time compilation, ...), but this doesn't remove the fact that clojure.core is huge and virtually any Clojure program will be importing more than just clojure.core, so there is still a lot of var derefs to deal with, then code to compile, then classes to load, etc.

[1] https://clojure-goes-fast.com/blog/clojures-slow-start/

[2] https://clojure.org/reference/compilation

Well, it's still partially the JVM at play. For example, if your application has big classes, and many classes, the JVM will be slow to start. This is what is happening here. Clojure is like a large-ish Java project, it has big classes, and many of them, with static initializers, that need loading at the start, and the JVM does all that slowly.

In some sense it's Clojure's fault for having an implementation that causes slow JVM startup, but it's also the JVM's fault that the way Clojure uses it causes it to take a long time to start.

When you get into REPL-driven development, the JVM startup time (which is often under a second for me anyways) is a total non-issue. You don't continuously restart your program to see changes or run tests. You can refresh all your state instantly without exiting.

But before Babashka, that was indeed a barrier to using Clojure in shell scripts. Now we have it all!

Except in Babashka you can't use Java libraries.. Right?

I feel a good fraction of code will dip into Java libs at least a bit - so you're limited in what libraries you can use

I think the real solution is probably Graal native - though it's not part of the official toolbox/deps.edn

In Unix it is customary to invoke tools from the Bash shell or Bash scripts. That doesn't mix well with a separate REPL.

I see your point here... I was addressing to the feedback loop during development time. Babashka works well for Clojure in a Unix tool pipeline.

It's also possible to compile your JVM Clojure program yourself to a binary with GraalVM for even better performance than Babashka and even faster startup.

We detached this subthread from https://news.ycombinator.com/item?id=40445197.

I think, in a lot of cases when people still complain about "the slow startup time of the JVM", they're really just talking about how the big JVM GUI apps (like IDEs) struggle to get started on heavily-loaded systems. And this, I think, is mostly just due to these apps eagerly reloading the most recent workspace on startup, and so pre-allocating big chunks of memory on startup to be ready for that — which can ripple out, on systems with low free memory, as other, colder processes all bottlenecking together on the IO of having their own memory written out to swap; and/or to having dirty mmaped pages forcibly-flushed to disk en masse so that the page-cache entries they live in can be purged.

Much more rarely — mostly when talking about writing CLI tools in a JVM language — people actually are complaining about the single second-or-so it takes the JVM to start up. (Usually because they want to run this tool in a loop under xargs(1) or find(1) or something.)

This last second of startup lag is (AFAIK) quite hard to improve, as it's mostly not the JVM itself starting up, but the static methods of JVM classes being called as those classes are loaded — which can do arbitrarily much stuff before any of your own code gets control. (Due to legacy code expecting to read certain per-boot-dynamic info as static fields rather than as the results of static method calls, I believe the JRE runtime is actually required to do quite a lot of that kind of static initialization, to pre-populate all those static fields, just in case something wants to read them.)

---

You'd think that GraalVM could inherently skip most of this, because the Graal compiler does dead-code analysis. "If nothing in your code reads one of those static fields, then nothing needs to write that field, so let's not invoke the static initializer for that field." But that's not true: static initializers are exported and called by the runtime — so they're always "alive" from the compiler's perspective. The Graal compiler isn't doing full-bore data-flow analysis to determine which static members of which classes are ever read from.

I believe GraalVM does try to work around static initializers as much as it can, by pre-evaluating and snapshotting as much of JVM runtime's static initializer code as possible by default, converting it all into const data structures embedded in the class files before the native codegen step gets run on it (see: https://www.graalvm.org/latest/reference-manual/native-image...).

It's not possible to apply this pre-baking to 100% of classes, sadly — some of these data structures need environment data like env-vars or system network config threaded into them on boot.

(I wonder anyone on the Graal project is working on a fully-general static-initializer optimization pass, that does something like concolic execution to bake these initializers out into either fullly-constant data if possible, or if not, then constant "data templates" plus trivial initializer functions that just gather up the few at-boot context fragments, shove them into the "data template" using a low-level hook, and then memcpy the result out onto the heap and call it an object.)

They are working with PGO, and adding also AI based optimization algorithms, both can help.

The problem lies with Clojure implementation, not Java or the JVM.

It's not the JVM.

It's how much code you load.

I mean... That's not an issue in other runtimes, so it's kind of a JVM quirk no?

Those other runtimes also don't do half of the features a JVM usually has to offer, and most people complaining also don't bother to actually learn the Java ecosystem, the existing set of JVM implementations, and the optimizations features made available to them.

No, that's defiantly true in other non-native runtimes.

E.g. any Python project has to deal with this, like Mercurial.

Java projects tend to (insert stereotype) have a lot of code.

Cool site, I've never tried Clojure before. My first reaction though is that (+ 1 1) is a highly unconventional and possibly confusing way of writing 1+1, and I'm not sure why that design choice came about.

Using the same notation for function calls and math operators has many benefits that may not be immediately obvious, and which may (depending on preference) outweigh the unfamiliarity. For example:

No operator precedence rules to remember.

Use math operators in higher order functions:

    (reduce [1 2 3] +)
    (compose + \*)

Simpler parser in the language.

Use kebab-case variable names.

Use most symbols in variable names.

The last two are because of reduced ambiguity in the language. The benefits for readability can be huge. For example, I love question marks for predicates in Scheme.

    (vector? x)
    (filter [1 2 3 4 5] odd?)

I'm sure there are more benefits that I haven't thought of.

> Use math operators in higher order functions:

To be fair, there just needs to be syntax for passing infix functions as a "normal" function, like parens in Haskell

  (reduce [1 2 3] +)
  foldl' (+) 0 [1, 2, 3]

And to allow `?` in names, it "just" shall not be used elsewhere.

In prefix notation (which has been around for a very long time) the operation comes first. Think of it as the "addition" function being applied to the arguments following it. This matches how nearly all programming languages are broken down into their abstract syntax trees while compiling.

As an added bonus, you now know Lisp. This is how all Lisp syntax works: `(function arg1 arg2 ...)`. That's literally it.

Prefix notation isn't unconventional and it has many benefits.

The main one being if you want to add many many items together it's much easier IE (+ 1 2 3 4 5 6).

Instead of doing an operation between two numbers you are apply a function to a list of inputs. In the "+" function's case you are adding them together. With this in mind, it's no different than most other programming languages. You would never have your function be in the middle of your arguments/inputs.

In python its Foo(bar, bar) and not bar Foo() bar, which obviously doesn't make sense.

On the contrary - I think it's much easier!

The real advantage of this notation is that it's much, much easier to stack calculations.

Example:

(/ (+ 34 68 12 9 20) 140)

You can imagine how the first part of that could come about:

(+ 34 68 12 9 20)

And then the second part (pseudocode):

(/ sum 140)

In Clojure it's easy to mash them together, or for example to paste the first calculation in the second.

(/ (+ 34 68 12 9 20) 140)

Want to go further? Easy: add another enclosing parens.

(* (/ (+ 34 68 12 9 20) 140) 1.5 2)

Note how we're stacking in a more human-readable order - a new calculation starts on the left hand side, the first thing we see as we read it.

Compare how verbose the alternative is:

((34 + 68 + 12 + 9 + 20) / 140) * 1.5 * 2

I'd take the verbosity over having to count the operators from the start of the line to figure out which one are used at the end of the line "1.5 2"

The parenthesis highlight in any decent editor. So it always very obvious which operators apply to the operands.

> (* (/ (+ 34 68 12 9 20) 140) 1.5 2)

The problem with that is by the time I reach `20)` I have already forgotten what operation I'm in. I'd write it more like this:

    (* 
      (/ (+ 34 68 12 9 20) 
         140) 
      1.5 2)

actually I'd write this as

    (/ 
       (* 2 (/ 3 2) (+ 34 68 12 9 20))
       140)

> ((34 + 68 + 12 + 9 + 20) / 140) * 1.5 * 2

Why not (34 + 68 + 12 + 9 + 20) * 1.5 * 2 / 140?

A programming language should be first and foremost precise and readable, not concise. I can barely understand the clojure version but when I read the "traditional" one I don't even need to think.

If you work with clojure a lot, does it become natural?

I've worked with clojure for years, and it becomes pretty normal, but I don't think it inherently get's better than the alternative, just on par... although it's realllly nice not to ever have to think about operator precedence, especially if you have to switch between languages.

Where it really shines though is when you use the threading macro and inline comments to make really complex math a breeze to review:

  (-> (+ 34 68 12 9 20) ;; sum all the numbers
      (/ 140)           ;; divide by a quotient for some reason
      (* 2)             ;; multiply by two for it's own reason

Yes, especially because the language is so consistent.

99% of the syntax is just (foo arg1 arg2).

I would say yes, as someone who got used to it a few years ago.

Use the thread macro to make this easier to think about:

(-> (+ 34 68 12 9 20) (/ 140))

It resembles command language: + is the command, and 1 and 1 are arguments.

  mv foo.txt bar.txt  # rename a file in the Unix shell

Except there are parentheses to delimit the command because commands can be nested in each other.

(Some Lisps have interactive modes where you can drop the outermost parentheses, allowing you to type like this:

  prompt> + 1 1
  2

but usually the parentheses are part of the formal syntax; where this is just a hack in the interactive listener.)

The design choice came about because the syntax started as an internal representation for a symbolic processing (formula manipulation) system that was being designed by John MacCarthy. The internal representation where the operator is first followed by its arguments was convenient because you don't have to parse around to identify them. You know immediately that by accessing the first position of the formula, there is going to be a symbol there which identifies its operator.

The internal form, and its written notation came to be used directly, while the symbol manipulation system came to be programmed in itself, so that its own "formulas" (source code) ended up in that form.

Lisp is one of the oldest programming languages developed in the 1960, it came before and is very elegant actually. You can write incredibly powerful things with this pattern and it's also really simple to build an interpreter for it with the stuff they had at their disposal at the time.

See also: 'Recursive Functions of Symbolic Expressions and Their Computation by Machine' (1960) [1]

[1] https://www-formal.stanford.edu/jmc/recursive.pdf

When McCarthy was first working on Lisp he intended to migrate to an infix syntax (called m-expressions), but abandoned the effort because everyone came to really like the current syntax (s-expressions) after they got used to it.

I know it's really hard to see how. (And honestly it's sometimes a little hard for me to see what the big deal is, but one of my first programming languages was a dialect of lisp so I can barely even remember not being comfortable with them.) But many people find that, once they get used to them, and especially if they learn to use an editor with a paredit mode, they can start to feel even easier to work with than infix syntax.

Basically you are writing in Trees more on that here https://en.wikipedia.org/wiki/Polish_notation

+ is a function, there are no operators in Clojure.

That allows for some nifty tricks like:

(reduce + [1 2 3]) ; returns 6

Another neat thing is that these functions are n-ary, and that includes 0 args. So (+) => 0 (additive identity) and (*) => 1 (multiplicative identity). Little things like this are missing from languages like Python and make functional programming worse than it should be.

Oh wow, this is truly great! Would you have a link to the code behind `(+)` and `(*)` ?

(In my functional programming languages, `reduce` also requires passing an initial value, like `foldl (+) 0 [1, 2, 3]`. But surely it should get a monoid instead of two separate arguments for the operation and the starting value!)

Your comment is a highly unconventional and possibly confusing way of writing... to a Chinese person ;)

Because (+ 1 2 3) makes 6. This said, doing any kind of maths in clj, especially division and comparisons, is a PITA - I’d go as far as to say that’s the worst part of the language. Otoh, (< 3 x 4 y) is pretty cool.

That’s prefix notation [0] and not unique to clojure.

[0]: https://en.m.wikipedia.org/wiki/Polish_notation

See S Expressions: https://en.wikipedia.org/wiki/S-expression

Try 1 + 2 + 3 + 4 + 5 versus (+ 1 2 3 4 5) for one nice reason.

The way to think about it is that you're processing a list, where the first argument is an operation, and the subsequent arguments are numbers to add. Clojure, and other Lisp based languages use this structure (a list) for representing everything - both data and functions. It turns out to be a very simple yet endlessly flexible and extensible concept.

because lisp and consistency

(some-function-name arg1 arg2)

I'm happy with TypeScript, Go, and Rust. Don't feel like learning anything else.

Do you post this comment on every thread involving a language that isn't once of your Holy Three?

Personally I don't feel this strong urge to tell communities that I'm not interested in them. Waste of my time and theirs.

Then… don’t? No ones is forcing you to try it or even to comment with your close-minded opinion. What does this comment bring to the conversation?

> Don't feel like learning anything else.

If you need to do graphql in typescript, you still "learning a new language". If you're using Prisma or you doing css-in-js, or rxjs, or tRPC, or Cypress, you're still "learning a new language".

You're basically moving from having to understand one (seemingly arbitrarily composed) syntax to another (seemingly arbitrarily composed) syntax. While I learned Clojure syntax once, and now only have to learn paradigms and techniques - logic, pattern-matching, concurrency, reactive dataflow, polymorphic dispatch, metaprogramming, event-driven programming, state management, etc. etc.

My hope is that I never have to use TypeScript, Go, or Rust daily since Clojure already gives me everything I need to write programs. It simply makes much better sense for the type of programs I'm writing today. Someday that may change, but I doubt that any of those would suddenly start making better sense to use. It probably will be something else, not these.

I'm happy with Clojure, having progressively discovered better and better programming languages over the years, and yet I'm constantly on the lookout for new languages and approaches.

Don't feel like being the Blub programmer and missing out on new good stuff.

Weirdly appropriate that the first thing on the website is this quote:

> If you want everything to be familiar, you'll never learn anything new. - Rich Hickey

I'm with you. I'll even go a step further, since I haven't heard anybody else say this:

My hot take -- There are already too many programming languages in use and every engineers life would be easier and productivity would be higher if we standardized.

There is almost no situation where making an entirely new language is the optimal solution. And the worst reason of all to make a language is anything aesthetic (e.g. spacing, parentheses, notations) -- all of those cases should be handled via native transpiling in the IDE.

Hmm, maybe we could come up with a standard syntax? We could call it “Standard-expressions”, or perhaps “S-expressions”? That way an entire family of languages could use the same syntax. Now how do we get people to follow this standard?

If we were forced to use only selected, most popular languages to communicate and ban all others, everyone would have to speak Mandarin, Spanish, and English. And the world would never know the Quran, the Bible, Arabian Nights, the Epic of Gilgamesh, War and Peace, the Ramayana, or the Divine Comedy.

There are some good examples of applications that are specifically written in Clojure and would be quite difficult to replicate in other PLs - Roam Research and Logseq, XTDB and Datomic, Nextjournal and Precursor.

> And the worst reason of all to make a language is anything aesthetic

Interestingly, people avoid learning Lisp, because it doesn't look "sexy enough" the first time they see it.

https://xkcd.com/927/

I'm not sure if you meant this as evidence for or against my point, but this is exactly what I mean.

Every year dozens of people think they're going to make some holy-grail language and it's 1% different from the prior version but now every single library needs to be rewritten, a dozen years of patches/bugs/security-holes must happen, whole resumes get shined up rewriting tech stacks that were perfectly capable, all for it to be thrown for the next shiny toy in less than a decade.

A new language just fractures knowledge.

Reply on news.ycombinator.com