181–190 of 246 posts
The only mantra about code organization I subscribe to is that it should be as simple as possible. Sometimes it means using several layers of abstraction like in this article. Usually it means just writing the damn thing in the most straightforward way because simple implementations are easy to adapt for future changes.
I prefer the first example. It’s more straightforward and avoids accidentally creating dependencies (for example some other code calling pluck_definition) that will be make it harder to modify when you need to add features or the API changes. Testing pluck_definition by itself is completely pointless since it does nothing on its own. This is the “test public interfaces, not private implementation” principle. Similarl…
> I also dispute that it’s hard to unit test the first function—-you would simply mock the api response and then you have a great test. How many times have you seen a test pass or fail when it shouldn’t have because the mocks didn’t match the actual code? It’s a useful technique but it has drawbacks which are not easily prevented.
It has similar conclusions, but does it from the frame of the "story of the code" rather than abstractions like "functional core" vs "imperative shell"
https://softwareengineering.stackexchange.com/questions/4160...
The premise is the imperative shell can become pretty riddled with decisions if your application contains a lot of I/O.
Some like the "Free Monad" solution, but I found that too be too coupling.
Earlier quoted context omitted.
> every reference to another object is injected via a DI framework And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.
> only to eventually discover that there's only one class that implements that interface I mean, in this case it's literally: * right click on "someInjectedService" * select "Go To Implementations" and you'll be there. Generally I do relate to the complaint though. DI makes your project feel like a "system" as opposed to a "program" (not that this is a bad thing or unnecessary).
So applied Onion Architecture. I agree with this part. However, the functional part of the discussion, while I agree with its benefits, is highly depending on the domain within the onion.
Generally, to those of us who apply the functional approach everywhere, it comes naturally whatever the problem. There are idiomatic ways to program in particular languages (even in Python or JavaScript) which are strictly against the functional approach, even though nothing in those languages prohibits it. It gets trickier with external dependencies which are "forced" on you too. Do you have a concrete "domain" exam…
Now, there is a place for pure functions in that environment. But making decisions based on state can run so thoroughly through the code that "functional core" leaves very little core.
Earlier quoted context omitted.
> Use mostly functions, try to make most of them pure. This reminds me of: > Eat food, not too much, mostly plants > > -- Michael Pollan My new mantra: Write software, not too much, mostly functions.
"Not too much" is interesting. If I understand you correctly, you can write "too much software". I can think of at least three ways - bad architecture, too little abstraction forcing repetition, and just bad writing. Did you have something else in mind here?
It ends up with a lot of typing but I think it is worth the trouble. Down the road it is easier to maintain and it already saves you time anyway.
Earlier quoted context omitted.
Are you actually a programmer? You sound more like an academic with no real life experience on large software. You do realize that within those "neatly separated layers of yours" there will be an insane amount of complexity which will be impossible to separate in layers?
> Are you actually a programmer? Why, yes I am. > You sound more like an academic with no real life experience on large software. Well, I do work as a software engineer for a FANG, so that does fit the bill I guess. > You do realize that within those "neatly separated layers of yours" there will be an insane amount of complexity which will be impossible to separate in layers? Well, there really isn't you know? I mean…
You on the other hand still belive you can make everything totaly managable forever and always and in any situation.
Your academic tone betrays you: you obviously believe you can always split things into neat little parts and then write books about it and how even in production this is so easy and always "just a bit of layering and it will work".
Anyone who worked on real production systems over years knows that unless your company has infinite money for developers and infinite time that you will sooner or later get parts on which complexity starts getting layered on.
But hey, "just add a few layers".
Also being a FANG developer means nothing. I've heard stories about FANG company developers, they are not very FANG-like to say the least.