[dmitriid]

One thing I don't like about all articles on clojure is that basically all of them say: ah, it's just like lisp with lists `(an (example of) (a list))` with vectors `[1 2 3]` thrown in. So easy!

But then you get to Clojure proper, and you run into additional syntax that either convention or functions/macros that look like additional syntax.

Ok, granted, -> and ->> are easy to reason about (though they look like additional syntax).

But then there's entirely ungooglable ^ that I see in code from time to time. Or the convention (?) that call methods on Java code (?) with a `.-`

Or atoms defined with @ and dereferenced with *

Or the { :key value } structure

There's way more syntax (or things that can be perceived as syntax, especially to beginners) in Clojure than the articles pretend there is.

    (defn ^:export db_with [db entities]
      (d/db-with db (entities->clj entities)))

    (defn entity-db
      "Returns a db that entity was created from."
      [^Entity entity]
      {:pre [(de/entity? entity)]}
      (.-db entity))

    (defn ^:after-load ^:export refresh []
      (let [mount (js/document.querySelector ".mount")
            comp  (if (editor.debug/debug?)
                    (editor.debug/ui editor)
                    (do
                      (when (nil? @*post)
                        (reset! *post (-> (.getAttribute mount "data") (edn/read-string))))
                      (editor *post)))]
        (rum/mount comp mount)))

[cr__]

Not sure how you’re supposed to find this page, but it’s pretty useful: https://clojure.org/guides/weird_characters

[dmitriid]

Nice! I missed it (or it didn't exist) when I last looked at Clojure a few years back

[roenxi]

You missed it, it has been there forever. But it says good and bad things about Clojure that its reference documentation is one of its weakest points.

The Guide/Reference split obscures a lot of information (do I want guidance on Deps & CLI or do I want reference on Deps & CLI?) and the guides where that gem is hidden randomly mix advanced topics (eg, how to set up generative testing), beginner topics (how to read Clojure code) and library author topics (eg, Reader Conditionals).

When you think about it, there is nearly no trigger to look at the guides when the information you need is there. Clojure is a weird mix of both well documented and terribly documented. All the facts are on the website, very few of them are accessible when required. The people who make it past that gauntlet are rewarded by getting to use Clojure.

[dmitriid]

In my case it was even worse, as I started with ClojureScript, and official documentation was simply abysmal then.

[hcarvalhoalves]

    {:pre [(de/entity? entity)]}

is "syntactic sugar" for

    (hash-map (keyword "pre") (vector (de/entity? entity)))

while

    (.getAttribute mount "data")

is calling the method `.getAttribute` on the `mount` object – since it's a Lisp, it's in prefix notation. It also highlights how methods are not special and just functions that receive the object as first argument.

Finally,

    @*post

is the same as

    (deref *post)

and the `*` means nothing to the language – any character is valid on symbol names, the author just chose an asterisk.

Most of what you believe to be syntax are convenience "reader macros" (https://clojure.org/reference/reader), and you can extend with your own. You can write the same code without any of it, but then you'll have more "redundant" parenthesis.

[dmitriid]

> Most of what you believe to be syntax are convenience "reader macros"

And yet, you need to know what all those ASCII symbols mean, where they are used, and they are indistinguishable from syntax.

Moreover, even Clojure documentation calls them syntax. A sibling comment provided a wonderful link: https://clojure.org/guides/weird_characters

[lvh]

Minor point of order about the atoms: they're not defined with @ nor derefd with . If you're referring to earmuffs* that's convention not syntax (specifically for dynamically scoped variables, which could be atoms or anything else), and @ is indeed deref. (More specifically @x is a reader macro ish that expands to literally `(deref x)`.)

[dmitriid]

Thank you! I never seem to remember this (but I don't use Clojure, so it's not an ingrained knowledge)

[ronnier]

Single engineers will pick clojure at companies , build a project in it, later that engineer will move on, now nobody can maintain this code so it’s rewritten in some normal language. I’ve seen that happen a few times. That code is hard to read and understand. This is why clojure will remain niche.

[mollusk]

You need a team that wants to use Clojure. I wrote Clojure professionally for 2 years, and everyone at the company was excited about it and sold on the language. Even after 3-5 years of programming in it. Now, at a different place, we write in a different language, and even though I still love Clojure, I'm not gonna write some project in it, even if Clojure might suit it so well, because I know these people are sold on different language, and I'm not going to preach and I'm not going to make their lives more difficult by having to maintain some obscure codebase.

[taeric]

That is possible with all languages. I've seen java, scala, clojure, perl, python, etc.

Usually this is made worse by bespoke build tools and optimizations that make the system punishing to pick up.

[sramsay]

You've seen a case where someone wrote something in Python that later devs could not understand and then rewrote it in . . . what? And you've seen that with Java?

There's a big difference between a developer going off and writing something in one of the top five most used languages in the world and doing so in Scala.

[lostcolony]

Both are strange and alien to Javascript developers, who can be full stack.

Python may seem simple once you know it, but going in blind there's plenty of traps to bite you. Significant whitespace for one.

[chrsig]

I think there's two different issues:

1. picking a language/tool that a company doesn't have personnel with experience using it

2. picking a language/tool that is esoteric, which generally implies #1 as well.

#1 on its own isn't great, but generally when sticking in the java/python/ruby/javascript/php/etc...mainstream languages, there's a lot more documentation, and there's a higher chance that _someone_ in the company will have some familiarity. If nothing else, it'd be easier to hire a replacement for.

[lostcolony]

A higher chance, yes, but it doesn't matter much; what is tricky with most applications is the domain. Certainly, it's faster to go learn a language than to learn a new domain. To that end, you can get the whole team trained faster in a language than you can hire someone with experience and train them to the domain.

[taeric]

Yes. I've seen and contributed to dumpster fires in all of those languages. I would love to say it was all some rogue developer that crapped on things, but it is often just new developers. The more, the more damage.

[achikin]

It could have been Go and Java programmer trying to understand it. Or it could have been some clumsy tool written in node which Go programmer finds hard to read and understand. Clojure's main advantage is that you can you can learn it very very quickly up to the point when you understand most of the code, the language is very very small compared to "five main languages".

[outworlder]

> Single engineers will pick clojure at companies , build a project in it, later that engineer will move on, now nobody can maintain this code so it’s rewritten in some normal language

"Normal language"?

You mean, whatever language is most popular at the company. What's "normal" at one would be completely alien at another. Even things like Java. If you don't have anything in the Java ecosystem, the oddball Java app will be alien and will likely get rewritten into something else.

The reason Clojure remains niche is that some people somehow think it's not a "normal" language, for whatever reason.

[agumonkey]

is it really hard to read (could be) or is it just that the average coder never saw lisp or sml and doesn't want to bother bearing the responsibility to learn something alien on duty ?

[girishso]

Agreed. These days I'm really fascinated by clojure and trying to learn clojure. Other than the project setup and repl and the editor (which I had considered), these weird characters are throwing me off.

What clojure really needs is some kind of opinionated framework or starter template, something like create-react-app. That has all these things figured out so a beginner like me can start playing with actual clojure, which documents all the steps to setup the repl and editor and what not. The last time I asked for this I was told about lein templates, they help but there's no documentation to go with those.

There needs to be some push from the top level. create-react-app was produced by facebook. Elm reactor (which lets you just create a .elm file and play with elm) was created by Evan the language creator himself.

tldr: There's a huge barrier to start playing with clojure that needs to come down and the push needs happen from the top level.

[uDontKnowMe]

There is the widely used Luminus framework https://luminusweb.com/

[girishso]

Yes, of course and I've got the book as well. The problem with the book is I got stuck on the very first code example in the book. I know there's a forum for the book where (hopefully) I can get my query answered.

My point is: these are all individual attempts (the book i mean) and there will always be something on page xyz broken and it can't be solved by individuals. To solve these problems, there needs to be constant time and money investment from someone serious (like facebook in case of create-elm-app).

[uDontKnowMe]

Yes I agree there is a problem of a lack of institutional funding in the Clojure world. Luminus is a great tool but it is a bit sad that it is arguably the most production-ready web toolkit in the ecosystem and it is mostly the work of a single person.

There is some community effort to better fund the core infrastructure in Clojure through https://www.clojuriststogether.org/, hopefully they can continue to attract more funding developers and companies.

In general a lot of these issues could be alleviated if the community was just in general larger with more contributors. I think the Clojure community is quite welcoming to newbies in the sense that people are quite responsive, kind and helpful around the internet, in Clojurians Slack (try asking there btw, if you haven't yet and are still stuck at the start of the book), etc. But in other ways people seem averse to criticism or suggestions from outsiders. I think the Clojure world needs to do a bit of self reflection to understand why adoption is so low right now and honestly consider what needs to change to attract more developers and contributors.