There are a lot of .thing configs piling up in a project root; the convention .config/thing would be better (if all would follow it, not some).
If you mean in general for all software, that’s a big ask. Some use such dotfiles to discover project root as well
In linux ~/.config dir became more established in recent times. Good point on discovery; but I'd guess if the folder is hidden (starts with ".") is less relevant to such use (at least compared to, say, deps.edn).
Also, on discovery & such, .config/thing can still act as an indicator
it would definitely be cleanlier
I guess if you have strong feelings about it, you must create a blog-post and get hype on hackernews and similar for people to start adopting the convention
Hi, I have a question that is not related to Clojure but more to functional programming in general. How can you make dependency injection? And If you have 2 modules, how will you make the first one to use the second one with dependency inversion? I haven’t covered this topic with clojure yet (I’m studying the basics) but I’m sperimenting something with Spring and Java Reactor with Functional interfaces. In a OO world I usually inject an interface in module 1 (defining a Bean that returns an instance of Module 2) and then I implement that in the module 2. I cannot use Suppliers, Functions and Bifunctions instead regular methods in this way in Java. I can’t use the interface. So What is the right approach based on your experience with func programming in general? Thank you a lot
in general, pass function as a parameter 🙂 this might give you some ideas, if you are new to FP http://mishadoff.com/blog/clojure-design-patterns/
if you need to manage stateful things look at https://github.com/stuartsierra/component (and its alternatives)
Ok, but if I don’t want module 1 knowing module 2, if I pass a function as parameter it has to know that module, or not?
I’ll look for clojure design patterns, thanks :)
@mircoporetti You can pass a function or a piece of mutable state or whatever you need. Your modules don’t have to “know” each other. They just assume that the passed in arg is e.g. a function and therefore call it as a function. In OOP you typically bundle functions and state as an object. In Clojure, you might simply use a map or a record instead of an object if you need to conform to some kind of complex interface. Clojure Spec (or malli or schema) can be used to describe the shape of the data if you also need to validate it.
Interesting!
A lot of Clojure-style functional programming is enabled by decomposing what you are used to with objects into data (mutable and immutable) and functions operating on the data (side-effecting and pure). It is much more useful to have this separation.
So the pure functions operate on immutable data, while side-effecting functions (often marked with a !
) operate on your mutable state. You generally want to expose the smallest possible surface area of your data as mutable state. Less mutable state leads to fewer side-effecting functions.
@mircoporetti Maybe this code example will make sense
(ns user.persit
(:require [next.jdbc :as jdbc]))
(defn for-id [db id]
(jdbc/select "users" {:id id}))
first, you have functions that take what they want explicitly as parameters
then
(defn create-system []
{:db (connect-to-database)
:redis (connect-to-redis)})
you have some procedure that returns a map of all the stateful "system like" stuff in your app
(there are a few approaches to this, but for now just imagine you do it manually in one place)
then at the service level you have functions that take this map
(possibly wrapped in some context for stuff like http)
(defn figure-out-first-user [request]
(let [{:keys [db]] (:context request)
{:keys [user-id]} (:json-params request)]
(p-user/for-id db user-id)))
and functions at the top level take out the parts of the system that they care about
"declare their dependencies"
the wiring changes depending on how you structure your app, but thats the gist of it
"look for the keys in a map that you care about"
That is the clojure specific answer
As far as statically typed functional languages go,
Scala uses "implicit parameters" for DI
Haskell uses the power of imagination and something something partial function application
looking at this john hopkins map of the US coronavirus infctions. How come the big around the middle west ish seems to have got away with relatively few infections? Is this infections map starting to be like a representation of population density? (I'm not from the US) Is the east coast and eastern middle far more densly populated, or something going on?
are people in the west of the country generally more careful or maybe those states tend to have tighter controls?
Yeah, it’s looking a lot like a population density map lately. The Plains states are generally more sparsely populated.
That map looks a lot like a population density map of the USA. There are very few people living in the Rocky mountains compared to the west coast
Depending upon what kind of info you are looking for, a map that showed different colors for percentages of local population with some property you are interested, might be more useful.
@qmstuart There are honestly too many conflating factors in infection data
a lot of states artificially make getting tests hard for either everyone or just certain populations
and looking at absolute numbers won't tell you much specifically because its just a population density map at a certain point
covid deaths per capita by state might be more useful
https://www.beckershospitalreview.com/public-health/us-coronavirus-deaths-by-state-july-1.html
but even that is somewhat inaccurate and won't tell you much without more specific time slices
the most accurate data will be excess deaths
or if your locale has something similar to this
which can work as a proxy for testing for determining the relative magnitude of community spread
since everyone poops
Folks, we have a #covid-19 channel where aspects of that can be discussed. We'd rather folks "opted in" to that discussion rather than have it in a big channel like this.