If that's the case then why is it so heavy? In comparison The Gimp consumes about 80MB of memory and burns a trivial amount of when not being actively used.
I don't really know Java, but .flatMap(...) seems to be equivalent to C# .SelectMany(...) which famously can be interpreted as a monadic bind operator.
The C# query syntax
from x in xs
from y in GetYs(x)
from z in GetZs(y) ...
which is similar to monadic do-notation in Haskell.
So since there is monadic Scala code elsewhere in the project, I wonder if this is a result of someone thinking in Scala and translating it into Java in their head.
I think there was always a similarity or homology between DRM and many privacy scenarios that people care about:
Party A sends information to party B intended for use in a specific context, but wants to limit the risk of it being stored or forwarded for use by other parties or in other contexts.
DRM typically connotes that party A is a media company and the information is a movie or something, but - as in the case the article is about - party A could also just be a regular person and the information could be private personal info.
You might trust Windows and even actively want Recall and simply not want private Signal messages, specifically, to be captured by it. For the same reason that Recall already tries to exclude browsers in incognito mode, as mentioned by the article.
Yes, I can see why the feature would be valuable. But the blog post is an emotional rant against Recall. Signal is lacking a lot of valuable features, I doubt this is high on the list of most users, yet time and effort has been spent on it. If you don't want Recall, then don't use it.
Yeah, technically this seems like exactly a DRM scenario: Party A sends information to party B intended for use in a specific context, but wants to limit the risk of it being stored or forwarded for use by other parties or in other contexts.
The last comment thread by agocke is interesting. I've thought before that it's unfortunate that LINQ and expression trees were implemented before the move to Roslyn, because if they'd been implemented afterwards they could maybe have just directly used the same object model that the compiler itself uses, which could make it more sustainable to keep them in sync with language changes.
IIRC it was to implement a constraint solver, which I couched in monadic terms somehow, don't remember the details. Not sure if I'd do it the same way again, but I did get it to work.
If it's some small isolated part or personal project I guess it doesn't matter - but I've seen a mature codebase that was started that way - and it was among the worst codebases I've seen in 20 years (of similar scale at least).
Few people even knew how to use it or what monads were, it was a huge issue when onboarding people. When the initial masochist that inflicted this on the codebase left, and stop enforcing the madness, half of the codebase dropped it, half kept it, new people kept onboarding and squinting through it. This created huge pieces of shit glue code that was isolating the monadic crap everyone was too afraid to touch. Worst part was that even if you knew monads and were comfortable with them in other languages they just didn't fit - and it made writing the code super awkward.
Not to mention debugging that shit was a nightmare with the Result + Exceptions - worst of both worlds.
It's basically writing your own DSL by repurposing LINQ syntax - DSLs are almost always a bad idea, abusing language constructs to hack it in makes it even worse.
Back when REST was a new hot buzzword and people were debating its true meaning, I remember thinking that some of the arguments for HATEOAS only really made sense if your client apps were going to be some kind of AI graph navigators. So I wonder if being particular about HATEOAS makes more sense now?
reply