This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (30)
- # beginners (184)
- # boot (4)
- # cider (9)
- # cljdoc (1)
- # cljsrn (2)
- # clojure (208)
- # clojure-austin (1)
- # clojure-conj (4)
- # clojure-dev (20)
- # clojure-europe (15)
- # clojure-italy (66)
- # clojure-losangeles (2)
- # clojure-nl (32)
- # clojure-spec (64)
- # clojure-uk (80)
- # clojurescript (50)
- # cursive (2)
- # data-science (3)
- # datomic (17)
- # emacs (1)
- # events (7)
- # fulcro (3)
- # jobs (15)
- # juxt (5)
- # klipse (2)
- # leiningen (31)
- # nyc (3)
- # off-topic (34)
- # re-frame (2)
- # reagent (9)
- # schema (1)
- # shadow-cljs (52)
- # specter (5)
- # sql (3)
hey y’all, I wrote a blog post: Frameworks and Why (Clojure) Programmers Need Them http://flyingmachinestudios.com/programming/why-programmers-need-frameworks/
I had such a negative reaction to the first sentence, I can't bring myself to read it. Seems totally unnecessary.
hey Alex - thank you very much for this feedback 🙂 I’ve updated the post to use more neutral language and to not sound as if I can speak for the entire clojure community. I’ll respond more on reddit to keep the convo in one place
> I had such a negative reaction to the first sentence, Personally I didn't, maybe influenced by prior writing by Daniel (i.e. I know his writing is intended to be funny and lighthearted) But I also can see how that particular sentence might catch people off-guard.
Frameworks that emphasize breaking things down into common data structures that I can manipulate with simple functions are great. I feel where it gets messy is when they introduce bespoke vocabulary that only reflect the author's perception of the problem they are trying to solve. That's what lost my interest in Phoenix in Elixir. It may not have classes\objects, but it also introduces extra vocabulary like Plugs which share no principles and can only be learned through extensive doc reading. What I love about a library like Ring is that I barely had to read the docs. I also don't have to think about which version of ring a handler is using because it's just a function that receives a request hash-map and returns a response hash-map.
I think the it’s just a _ position is a reductionist posture that contributes little to a conversation like this. It rubs me as dismissive to the propositions being advanced without actually addressing them.
To be clear, the first portion of that remark is fine (with me). I’m just picking on the second cause I see it so often.
FWIW I think a better way to frame these discussions is with respect to specific contexts. It’s not “Why” it’s “When”.
the most striking thing to me about frameworks is that they’re so successful, in the sense that they’re widely used and people make a ton of money with the products built with the frameworks
I had a great experience with Ruby and Rails not too long ago at a Clojure/Ruby shop. Even though I’m equally proficient in both languages, I found that the process of updating application code in a Rails application was generally more efficient than a Clojure one. Personally, the value of “convention” is hard to devalue in a setting where you have to work with other people. Conventions are great for teams.
@U8WFYMFRU> it’s just a function that receives a request hash-map and returns a response hash-map This ☝️
@U06MDAPTP I see, what makes it reductionist though? What bigger idea am I reducing?
@U8WFYMFRU the structure of it. The appeal to the virtuous nature of a Ring handler being so simple because, look, it’s just these three simple bits.
@U06MDAPTP is that wrong? I am not suggesting frameworks are bad, I agree with the article that they shouldn’t be a dirty word. However, I do have some thoughts on what can make a framework more appealing to me. Perhaps a stronger point is that I prefer learning frameworks that apply to a lot more than itself. For instance learning Ring I learned how to setup a simple middleware pattern with composition and how to model a complex problem such as request handling, into pure, data-driven functions. That is drastically different than my ongoing 4 – 5 years with Django where most of what I learned only applies to Django itself. Some of which doesn’t even carry between versions of Django. For instance how you access headers from a Django request class instance changes between 1.11 and 2.0. In Ring, you don’t have that problem. If the community builds frameworks that play nicely with FP concepts and the principles Clojurians typically embrace, I think they may come around.
@U8WFYMFRU I do not think it is wrong. I felt like it was misplaced in the context and that statements with a similar structure in philosophical Clojure discussions [to me] are not contributive. I followed that up because I wanted to clarify that I thought your other remarks were fine. I mean no harm.
@U06MDAPTP I don’t feel you were trying to cause harm. Was curious if I misrepresented what I was trying to say, if I said something stupid, or there was room to refine it into something more meaningful. After talking I do see your point and will be more mindful of that in the future. 😀
To the topic at hand, I think another benefit of using a framework is that it often alleviates you from having to make some decisions up front. For someone that wants to build an MVP that can be huge (suspending for the moment the disasters an emphasis on an MVP can bring about). Of course, a framework isn’t the only thing that can do that right?
lein new <template> can do this but I’m not talking about that. I’m talking about structural decisions and conventions.
Take re-frame for example. At its core, its really just an event handling and state management library. We could put those bits together in a number of different ways, sure. So what? Its the conventions of re-frame which make it so useful to the community at large. It gives people an opportunity to get to the part where they can start building shit without having to hack together their own architecture while they build their application.
And its that last part that really resonates with me and why I think frameworks organized around conventions are nice. I’ve now worked for 4 companies seriously using Clojure to build both back and front end applications and I can tell you that, apart from the common libraries they use, I’ve seen many of them architected similarly but each with subtle twists. Those differences are so annoyingly common that think at this point in my Clojure career, I would love to see a framework with broad support in the community.
I think something vastly under-appreciated by experts is how much frameworks offer a gradual ramp to learning. you can start doing meaningful things immediately without having to make a billion choices that you'd probably make poorly as a beginner
and yet the experts are the ones most in a position to provide these sorts of ramps