Comment by clusterhacks | Hacker News Reader

Comment by clusterhacks | Hacker News Reader

Parent Full thread

I believe what you see with multiple web frameworks may more often be the misguided attempt of Clojure newbies to reimplement what they already know instead of kind of stepping back and understanding what they actually already have available via Clojure.

I can't find the reference anymore but I think Stu Holloway once said something along the lines of there is a tendency of new devs picking up Clojure to try and rewrite Rails. And that it was a mistake.

The real concern you express about Clojure having "missing or rotting" libraries is harder to quantify. I will say that has this has not been my experience at all. I actually find that I write one-off programs very frequently with Clojure - to call web services (REST or SOAP), serve a http-friendly API via liberator, and other similar work. Grabbing an older library that works seems to be quite easy most of the time.

I do think in the early years of Clojure some groups were looking at Clojure as if it could become what Ruby was to Rails. Meaning, could you use it almost as a marketing tool, e.g. "our devs use Clojure and thus are more powerful." It isn't/wasn't a terrible idea from that perspective but I do think that is one that has somewhat fallen by the wayside. The motivation behind some of the multiple "Rails-like" Clojure libraries may more have been an effort to build a new 38 Signals and not so much fix a real need for a web framework in the Clojure community.

Rich Hickey was looking at Clojure as a better tool for thoughtful software development and maybe even planning for what he might build (like Datomic) with it. I remember at the first Clojure/conj conference he gave a talk and expressed some amazement that other devs were already using Clojure to do production-like things. Everything since that time may have been an interesting side effect of Clojure being a lovely language for devs who were already strong with Java or Javascript so the interop was not a big deal. And its in the interop where maybe most devs should look for these "missing or rotting" libraries?

For posterity, I found the quote I was thinking of from Stu:

"what we would quite often see is that people would write a Java app in Clojure, or people would write a Ruby on Rails app in Clojure. And not surprisingly, it would have weaknesses that you associate with idiomatic Java apps or idiomatic Ruby on Rails apps because that's, in fact, what they are."

https://www.thoughtworks.com/insights/podcasts/technology-po...

Most of the Clojure web frameworks I've seen have been designed and built by fairly experienced Clojurians -- but I'd have to go read each of those frameworks' rationale docs to see _why_ they actually built them.

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 . . .

Can you share how you approached calling SOAP services from Clojure?

Just library-driven-development.

I used the paos library (https://github.com/xapix-io/paos). Mainly followed the quick start examples on the github page. Fetched the wsdl from the API provider, pulled out the SOAP envelope which translates into a Clojure map. The API provider has a bunch of soap services that each provide a large number of keys in the envelope but many keys in many services aren't capable of actually doing anything server-side. This was . . . documented poorly.

We have dev and test environments for this specific API provider so I hacked around and made calls until I had everything working.

This is a perfect example of the kind of one-off stuff I often use Clojure for. Quick prototypes to get work done. There are many groups in my larger organization and a common experience for me is to have groups tell you "X can't be done because Y." In this case, a vendor was charging 5 figure fees per data migration effort for each planned migration. The plan was to roll out by group and there are many groups. My immediate question was "can't we do this with the API and save these fees?" The answer was "no, not possible." About three days later I had a working version for this admittedly simple use case, demo'd it, rolled it into production. The cost savings will be in the low six figures. Of course, once it was working the original internal group came back to re-implement the project in another language because "bus factor" but tbh there is lots of weirdness in my larger employer organization about who gets to do what. Once I had shown we could do it relatively easily, teams come out of the woodwork to grab it so that they can add the cost savings to their yearly brag results.

I could write for days about this type of thing . . .

Reply on news.ycombinator.com