Also the Clojure language had a huge growth period around 1.1-1.5 which sparked a lot of excitement and spurred a lot of community growth. But since then, most of the exciting features have been adapted to other mainstream languages either as features or libraries, and most senior developers I know prefer to take the path of least resistance, which includes avoiding less-mainstream languages and frameworks. So instead of using Clojure with Compojure, it's common to move to Java with Dropwizard, or slightly less analogous, JavaScript with Express.js. And instead of using ClojureScript with Om, people mostly jumped to JavaScript + React.

Edit: Removed comment about Om, since I must be misremembering something. Om uses React and has since the first commit.

What are you referring to by "instead of using ClojureScript with Om, people mostly jumped to JavaScript + React, which the Om team later praised as being the same concept they had in mind, but with a simpler and better API"?

Om uses React, it didn't predate it or anything. Many of the things Om tried are more relevant to things like Redux, not React proper, so I'm not sure what your comment is referring to.

And as a counterpoint, React just introduced the State and Effect Hooks, but those are both things that Om and reagent (the most-used Cljs React lib) have been able to do for years.

> What are you referring to by

Apparently I was remembering Pedestal. See my other comment.

> Many of the things Om tried are more relevant to things like Redux

> And as a counterpoint, React just introduced the State and Effect Hooks, but those are both things that Om and reagent (the most-used Cljs React lib) have been able to do for years.

These are great evidence for my point, that Clojure has worked as a testing ground for features which more mainstream languages and frameworks then adopted.

I don't think I was clear enough. Yes, React (and others) has adopted things from Clojure/script, but to me, that's a sign you're using inferior tools that are several years behind.

E.g., I used to do a lot of PHP, and my last PHP project was in Laravel, which is heavily influenced by Rails, and PHP 7. Many people touted "Modern PHP is just as good as Python/Ruby/Js!" but missed the point that they'd been using tools with inferior capabilities for years.

Re. your edit, which erased "instead of using ClojureScript with Om, people mostly jumped to JavaScript + React, which the Om team later praised as being the same concept they had in mind, but with a simpler and better API": I’m pretty sure that the coment you mention referred to reagent (which builds on top of React as much as om).

My memory is apparently failing me, but I remember it being one of the very first "reactive" web frameworks, before React came out, and being made by the makers of either Clojure or Datomic (before they were Cognitect) and possibly also David Nolan. And I remember them discontinuing it after React came out, saying something along the lines of "We had this idea before React came out, but our method involved explicitly changing UI when state was updated, whereas React does that automatically for you and in hindsight that was a great improvement over our idea. So we're discontinuing this and going to change the focus of the project to work with React instead." I'm pretty sure the project had a slightly longer name than Om, and was a big thing for a total of a year, where everyone jumped on board and jumped off again. Unfortunately I think I mixed this up with Om / OmNext.

---

EDIT: Oh! Just figured it out: Pedastal. Yep, originally made by Relevance Inc.

Here's the link of its discontinuation which mentioned React as a big motivator: https://groups.google.com/d/msg/pedestal-users/jODwmJUIUcg/6...

> "But unlike in Pedestal App, you don't have to worry about how fine-grained changes to your App model map to the UI."

That's the part I was remembering.

> "So there is clearly conceptual overlap between Pedestal and ReactJS. Further, David Nolen's work on Om has shown that ReactJS and ClojureScript work very well together."

That's probably why I got this mixed up with Om. This all happened about 4 years ago so I guess my memory isn't as fresh.

> he Om team later praised as being the same concept they had in mind, but with a simpler and better API.

is this in public? cursory search did not return any hits.

Um, Om is React. React came first and Om interfaced with it.

>>A misspelled keyword results in nil accidentally flowing through your app.

Some dynamic languages, worked around this issue in the 90's. Perl for example, if you use 'use strict; use warnings' will catch most of these misadventures.

Having said that, only the most novice programmers make these kind of mistakes. Like the absolute beginners, in the first day or two of exposure to programming.

As a rule almost any shop these days write unit test cases, so that should flush out these kind of bugs.

EDIT: Why the downvotes? People seriously work with programmers whose biggest incompetence at work is typos? Or you think writing unit test cases is bad?

With all due respect, I think your argument is a little silly. Typos are the one mistake that programmers never stop making no matter how experienced they are, in my experience. For the same reason, you can pick up a book by an experienced, established writer and find typos in it as well.

It's useful for your tools to help you catch basic mistakes like that instead of just saying you should work with programmers who are competent enough to never write typos.

I don't think we are talking about that kind of typos. But there is a often a big dip in quality of people, who routinely struggle to write a half decent working program without making these kind of mistakes.

Sure every once in a while its possible for any one to drop in a spelling mistake, but those are rare situations in code. Mostly because code is often not a dead piece of documentation, which is read and auto corrected in the human brain. Code works on a computer with well defined interfaces and protocols.

Think of it this way, would you hire a programmer who often makes typos, to write shell scripts that have 'rm -rf'?

If you wouldn't, how often do you trust these people to execute DROP DATABASE <typo_database_name_which_happens_to_be_real>?

There is a big difference between programmers who can put in typos in a sentence in a code comment, and the kind of ones we are talking about.

I've deployed tens of thousands of lines of Clojure for a company over several years, and I still find that I occasionally destructure a map with the wrong keyword and I end up with nil accidentally. It's frustrating as much now as it has ever been. Because the app just crashes instead of a simple compiler check that most languages would offer to capture simple stuff like this.

You don’t have to be an absolute beginner to make this mistake. You just need to be on a project with inadequate test coverage.

They just disagree without explaining why. Anyways, I sometimes have typos in my Clojure code, but once I follow through with your mental model and just reproduce the problem in REPL it is easy to find these sort of bugs.

I'm not sure, but if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names, write functions hundreds of lines long, can't modularize code, write 3 nested for loops, or write nested if's where '&&' suffices.

Then you are having far bigger problems related to project management, hiring and overall direction in which you are running your team/company.

Clojure as a tool doesn't aim to fix these kind of problems. And it can be argued no tool will fix these problems.

> if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names

Those are the kind of things that the computer is best suited to. It's better if the programmer's brain is left to other, more challenging tasks.

One wonders what kind of challenging tasks a programmer who can't even indent code, can solve.

By the way indenting code happens to be the most basic of code review checks.

Code indentation has been automated away since like 10 years or ago or maybe even more.

Vim, Emacs, Atom, Sublime Text, Visual Studio, Eclipse, IntelliJ, NetBeans can all auto-indent code for you. Combined with linters they can also automate stylistic checks and coding convention.

I don't know anyone who indents code themselves. The editor/IDE does it for them.

Indenting code is certainly not a code review check. No sane workplace should waste a senior developer's precious time commenting about indentation problems during code reviews. It is a tooling check that is part of CI/CD.

Why waste human time on what can be done by a machine?

In my experience, a compiler would be wasting my time interrupting me with errors that are easily catch later, playing with the clojure REPL.