Alternate take and apparently unpopular opinion: the US government can simply force Apple to give them a back door to access iCloud photos directly.
What Apple has done here is both way more complicated and way more visible than necessary, while being less useful to a government. The slippery slope and capability to exploit is cloud storage.
The article makes it sounds like they are replacing PageRank. According to the paper it's orthogonal to PageRank. It's just another signal to consider. The other assumption seems to be that this will cause site authors to fact-stuff. However it sounds like they more interested in using wrong facts to penalize a site than using correct facts to promote a site.
"...but it's society as a whole causing this rather than government(s) specifically"
It sounds like you are claiming that state surveillance is actually a subset of social pressure surrounding what's socially acceptable behavior. You claim the latter to be a bigger and more serious problem. Perhaps you did not mean to claim that, but that is how it sounds.
Socially acceptable behavior is always changing as generations come and go.
For everyone's well-being, governments must always trend away from oppression, not toward.
Whatever you think about equality issues, surely we can agree that these things are not really the same, and government oppression certainly is not a subset of social norm issues.
This is correct. OO codifies the pattern of having a struct and a set of functions that operate on it. The syntax does help humans reason about that pattern. But my understanding is that the goal is more about the human limitations of managing large code bases than the human limitations of language.
OO is all about encapsulation. We tend to decompose a program into chunks for different teams and individuals to work on. Software development is a distributed task. Encapsulation means when you code against components written by other people, you only have to understand the public API that they provided. You are supposed to be guaranteed that that API will continue to work even as the code behind it is updated. As component users we can focus on our own task and not worry so much about the details of the component. As the author of a component, we can hide state from the users. That can't be done with structs. we can make updates and switch out implementations without (as much) fear of breaking the code that depends on it.
It's really all about being able to modify code more safely on bigger teams.
In my mind the issues that OO introduces are:
* Encapsulation results in more verbosity for the same functionality.
* Inheritance takes more thought.
* OO as a whole is more complicated and has a bigger learning curve.
* OO used incorrectly will magnify the first two points greatly. Given the learning curve I imagine a lot of people don't use it fully correctly.
"For example, we now know that 35% of the variation in a team’s performance can be accounted for simply by the number of face-to-face exchanges among team members."
As someone who lives in a rural area I see a distributed team as the way to go for hiring talented individuals. I also know that working remotely can hurt communication and collaboration if extra effort is not given. It would be interesting to see a similar study on distributed teams and a comparison of how effective their different strategies and communication tools are. Do any remote workers here have any observational evidence on this?
Well, yeah, I agree that the SPL types are nice to have. My complaint is that PHP's only first-class array type is a weird array/map combo. Have you ever seen anything like that in another language?
The SPL types are definitely a welcome addition to the language, but they feel like add-ons. Definitely not first-class. The standard array functions don't work with SPL types (array_map, etc.) even though the SPL types are iterable.
More to my point, missing from SPL is a dynamically-sized array that's not based on linked lists. Linked lists don't have O(1) lookup. This type of array really should be first-class, but it’s completely missing from the language. Please correct me if I’m overlooking something!
That said, I believe having separate, first-class, dynamic arrays and maps would strike a better balance of dynamism, performance, and predictability compared to the single existing first-class array/map.
This is great news. PHP doesn't have many structured data types, so arrays (aka maps) are basically used for everything. Any improvement to them will impact the entire application.
It would be nice to have separate types for arrays and maps though. I don't understand why they were combined to begin with. Simplicity? Seems like there are more edge cases and gotchas the way things are now.
What Apple has done here is both way more complicated and way more visible than necessary, while being less useful to a government. The slippery slope and capability to exploit is cloud storage.