Structuring Clojure applications
yogthos.net
Structuring Clojure applications
1–10 of 67 posts
Re: Structuring Clojure applications
#2A similar post, also mentioning protocols and integrant, was posted here a few days ago and may also interest some:
Re: Structuring Clojure applications
#3It's interesting to see a lot of FP communities independently arriving at the same architectural structures. See e.g. Haskell's "handle:" https://jaspervdj.be/posts/2018-03-08-handle-pattern.html
Re: Structuring Clojure applications
#4For me, protocols i tend to not use it, because it makes it harder to understand the code and Cursive cannot find instances that implements the protocols.
For testing purposes is easier to redef a function than implementing a full new test protocol.
Re: Structuring Clojure applications
#5It's interesting to see a lot of FP communities independently arriving at the same architectural structures. See e.g. Haskell's "handle:" https://jaspervdj.be/posts/2018-03-08-handle-pattern.html
Convergent design is certainly a thing, but it's also quite possible that communities are cross-pollinating ideas. Either way, when you see those recurring patterns that's certainly a strong indicator that one should pay attention.
Re: Structuring Clojure applications
#6I'm an experienced developer and I'm getting the feeling that advanced languages are getting less relevant for most applications, since you usually just need a little glue code to glue together mainstream solutions or managed services. I don't need the power of Clojure to connect SQS to Lambda with some extra custom logic.
But Clojure does look amazing :)
Re: Structuring Clojure applications
#7For me, protocols i tend to not use it, because it makes it harder to understand the code and Cursive cannot find instances that implements the protocols. For testing purposes is easier to redef a function than implementing a full new test protocol.
I agree that in most cases with-redefs works fine, and I tend to use protocols sparingly myself for the same reasons.
I thought it was worth mentioning that you can use them to encapsulate any effectful code since they can be used as a tool to help enforce a bit of discipline. If you're just calling functions that can cause side effects then it can get tricky to figure out what all the functions that need to be redefined are. You basically have to read through all the code to know what you need to mock. If you stick all the side effects in a protocol, then you're being very explicit about what needs to be mocked out.
Re: Structuring Clojure applications
#8I'm an experienced developer and I'm getting the feeling that advanced languages are getting less relevant for most applications, since you usually just need a little glue code to glue together mainstream solutions or managed services. I don't need the power of Clojure to connect SQS to Lambda with some extra custom logic. But Clojure does look amazing :)
For me it's mostly a quality of life issue. I find Clojure workflow is far more pleasant than most languages because it's interactive, and I like Clojure as a language because it's small and focused. I find the main feature of Clojure lies in its simplicity as opposed to advanced features. Clojure code tends to be very direct where you're just passing data through a series of transformations, and you apply a few common patterns to solve a wide range of problems.
Re: Structuring Clojure applications
#9I'm an experienced developer and I'm getting the feeling that advanced languages are getting less relevant for most applications, since you usually just need a little glue code to glue together mainstream solutions or managed services. I don't need the power of Clojure to connect SQS to Lambda with some extra custom logic. But Clojure does look amazing :)
Interesting point. I've recently taken on a client who insists on using C# with their cloud solution. It's killing me. Though you're calling Clojure "advanced", what I'm missing is its simplicity.
Re: Structuring Clojure applications
#10I'm an experienced developer and I'm getting the feeling that advanced languages are getting less relevant for most applications, since you usually just need a little glue code to glue together mainstream solutions or managed services. I don't need the power of Clojure to connect SQS to Lambda with some extra custom logic. But Clojure does look amazing :)
Interesting point. I've recently taken on a client who insists on using C# with their cloud solution. It's killing me. Though you're calling Clojure "advanced", what I'm missing is its simplicity.
Maybe a better classification would be "amazing languages" vs "good enough ubiquitous languages" :)