652 karma · joined September 11, 2022
This is not sustainable anyway, the scale at which they want to control data flows. Time was money, now data is money and they are too greedy for it.
All this agitation is just a silly attempt at constraining competition. The danger is not the AI, it is having all your systems connected. Overreliance on networked tech.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain. Except playing chess has side effects. A mere snapshot does not encode those.
I understand the mistake.
Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
Just as I speak, it is reworking a UI compositor design, after I told it to use the reactive framework I have built for damage restoration, because in the end, this is a reactive problem. The implications, it drew on its own. But I had to nudge it.
They care but then it has been made very difficult to find privacy preserving services. Or convenience takes over.
It is like replaceable batteries. Everyone cares but we are not given the choice.
Or the headphone jack...
I think it is different here. First it is easy to build. Second that is too much information that should remain private.
That is how I think it should be done.
No wonder I failed this sht, kind of.
I just can't tinker for the sake of tinkering. Too goal oriented I guess.
Just me? (that is also why school started to bore me right before high school and why I learn better on my own, I did go too College but thank god I didn't do CompSci or that would have disgusted me...)
(half joke aside, it is finally coming in a couple days.. which I have been saying for quite some time to the extent that my peeps don't even trust me anymore.. 3 things are coming and it is genuinely research grade apparently, for the amount of research I am aware that is released publicly. I really don't know how people ship things, the tooling I see is terrible, or maybe I have NIH syndrome...)
What you do not seem to understand is that with a normal Android distribution, you expect a phone home tied to the manufacturer of your phone.
Matter fact, as I pointed to you but you conveniently ignored, it does not have to be an 'Android' phone. It is the same for Apple and their iphones and pretty much all off the shelf phones. Not need to single out Android if your point is not about the fact that I said 'bootleg' Android...
With a bootleg Android, you forego any security, beyond the phone home. ANd you wouldn't even find someone to speak to about it. What is so difficult to understand?
If your worry is about phone-home, no need to mention Android specifically. This happens with all off the shelf phones. Point is about a phone that has an OS that looks like what you would expect and just doesn't do what you expect. Obviously you didn't understand what I had written so I had to call you on that. You may feel insulted, does not mean that I am insulting you.
Anyway, just so that it is clear. Probably should end the conversation here so no one feels insulted any further.
Besides, depending on the actual OSI license, you can definitely have bootlegs if you really care to argue.
A bootleg does not need to be exploited commercially. It can just be counterfeit.
I am not insulting you. I am telling you that you are being overly pedantic while being wrong at the same time. You might find this difficult to accept but I'm just calling it.
So even if generics were there from the 'get-go', I am not sure this exact feature would be added anyway. In fact, it is mostly contrary to Go's structural polymorphism, let alone parametric polymorphism.
Typically what you want would be defined as a function, a specific wrapper type... If it is not already a common method of each shape.
So far, I don't feel like the design of Go's generics suffers from any real issue. The implementation is not 100 percent done yet. But the plan looks sound to me.