That's a good point about experienced Clojurians creating some of these frameworks. I jumbled up the idea of new Clojurists writing "ruby-like" code in Clojure vs experienced devs writing differing web libraries for Clojure.
I think the focus on "Clojure's Rails" muddies the waters - the original article's point was non-web framework/library development suffers because so much effort has been poured into various Clojure web frameworks. My response was more to say that from my perspective, hey, not so much.
I do think, especially in the early years of Clojure, that there was more than a little bit of not-invented-here syndrome that rationale docs won't capture. Clojure is so expressive that there is always a bit of pull to "roll your own" for Clojure developers.
This pull is maybe even true in Ruby - I remember liking Sinatra more than rails because it felt more clean to me or maybe was simpler for me to understand. Heck, for that matter there are like 13 web frameworks that show up as supporting the Ruby rack http interface/api. I don't think anyone would claim that 12 of those are redundant because of Rails . . .
I think the focus on "Clojure's Rails" muddies the waters - the original article's point was non-web framework/library development suffers because so much effort has been poured into various Clojure web frameworks. My response was more to say that from my perspective, hey, not so much.
I do think, especially in the early years of Clojure, that there was more than a little bit of not-invented-here syndrome that rationale docs won't capture. Clojure is so expressive that there is always a bit of pull to "roll your own" for Clojure developers.
This pull is maybe even true in Ruby - I remember liking Sinatra more than rails because it felt more clean to me or maybe was simpler for me to understand. Heck, for that matter there are like 13 web frameworks that show up as supporting the Ruby rack http interface/api. I don't think anyone would claim that 12 of those are redundant because of Rails . . .