I had a bedbug problem in a place I rented. The landlord used heat, and it seemed to work. I also just used common sense and got a mattress liner and used Permethrin around the perimeter of my room, and it cleared up.
People who grew up in the Web 2.0 era are obsessed with trends and influence. Posit A#1 of these people is: The more people who think something, the truer it is. Therefore, you must be in the biggest group of people possible in order for your groupthink be true. A small group that tries to disagree with a big group is wrong. Therefore, their ideas will die, and there is no point in being a member of such a group. You might as well just think for yourself, which, as they all know, is insane.
Practical CRUD app architectures still exist like always. You just wouldn't know it anymore from social media. The engineers who understand it got exhausted of explaining the obvious over and over again. Just let the beguiled play with their insane contraptions. It's of no concern.
I feel like this is part of the problem, we keep trying to find the right abstractions, but it seems to me the ones that generalize well enough are tend to be very difficult for most to understand.
I've been down a rabbit hole for the last five years researching this, and I am converging on Clojure. I don't understand why transducers aren't used everywhere, they seem to solve a gigantic class of problems that I see everywhere.
I'm also getting the feeling that Haskell folks have really done a lot of great work, and plan to learn more about their typing system next. Monads seem to be a fundamental building block.
If I try to bring this up with engineering teams, I don't get any traction because nobody wants to learn any of this stuff. It takes too much time to ramp developers up, and management is skeptical because there aren't enough large-scale communities or companies built around the concepts from their perspective. Bottom line is, it takes too much investment for too much risk.
Instead we get a lot of half-baked and wrong abstractions incrementally invented for the latest pain point instead.
Sorry, but no. If that or transducers are the things you think about on this context, you are going on the wrong direction.
Not that those aren't useful. Whatever software solves the OP's problem will certainly make plenty of usage of interpreters and lambdas (what monads and transducers are), and any developers should be able to use both of those. But those are completely removed from the problem, they aren't an attempt to solve it.
The apps that I write pull data, process it, and write it to another sink.
There are many different sources and sinks, but the processing pipelines tend to be the same.
Based on my research these abstractions are designed for this. Feel free to elaborate why I'm incorrect, or better abstractions.
I brought it up in the discussion relating to CRUD, because it's very similar to the code I used to write for straight CRUD. In fact both ends of the processing pipelines are identical to CRUD.
I'm somewhat into FP concepts, and here is how I de-jargon these terms:
> transducers
Just a function composition operator. Notes: is aware of iterators like `reduce`, and merges multiple consecutive of such loops into one. (should optimizing compilers not strive to do this anyway?)
> monads
Literally just an "interface". For instance, you will be able to .map() it.
> algebraic effects
Resumable exceptions (you can go back to the "throw" with the corrected data)
At about the 20 minute mark, they show the Foucault testing of the mirror, and actually put a camera at the test focus, so you can see a Foucaugram of the mirror. It's of poor quality, but still. You see the donut. To anyone who was into amateur telescope making, ground their own mirror, used the Foucault test, and was as interested in mirror metrology tests as I used to be, this is absolutely fascinating.
