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.
I'll add to your alternate take: technology like this starves of oxygen the singular argument (disingenuous as it is) which has proven tractable in the public sphere against robust E2E encryption. With this technology in place, never again will the Government be able to wail "think of the children" when claiming E2E needs a Government sanctioned back door.
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.
> 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
He didn't say it was a bigger problem, he said the problem is bigger than just the government. In other words, it's all part of the same problem.
Governments are not Other. They are part of a society's self-regulatory machinery. Democratic governments in particular are a reflection of society at large. If a government is behaving badly, the root cause has something to do with the society.
That's how I read GP and I can't disagree.
> Socially acceptable behavior is always changing as generations come and go.
Legally acceptable behavior is also always changing as generations come and go. From a sociological perspective laws are simply the formalization of very strong social norms.
reading between the lines this sounds to me like an attempt to kill the bill the amendments were added to rather than sneak the amendments into an easy bill.
seriously. the home secretary authorising every journey in and out of the UK with one or more schemes..... never going to happen.
Honestly, I think something like Ocaml's module system would be better for large teams than objects, and I think it's also just a better way to organize code.
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?
I work remotely and I would say that communication is much better and easier when working remotely for many people such as myself. Tapping someone on the shoulder is a LOT more intimidating than highlighting someone in chat. I don't want to bother people, I just want to be effective. Highlighting allows me to hit someone up with questions and they'll be able to respond depending on how urgent the task is in relation to their other tasks.
I will say I get more solo work done when I'm around people. It's hard to stay on task if you don't have the ambiance of people with expectations. I go to coffee shops, because even though they aren't my co-workers, if they see me working, they still have expectations. If they look over my shoulder and see me on social media, I've failed their expectations, and just that subconscious feeling does wonders to motivate me. I want to be a people pleaser and remotely that can be tough.
Thanks, I was wondering how to solve this very problem. I over-perform only when people are expecting something of me, to please them. Else I do simply nothing.
>I also know that working remotely can hurt communication and collaboration if extra effort is not given.
You've hit upon the key point that many remote workers neglect. It doesn't hurt, and oftentimes greatly helps, to consciously make the extra effort to relentlessly, while appropriately, seek out moments for personal bonding time between team members. Remote staff may need to take this to gentle professional extremes to glean tidbits of personal information on their teammates (i.e. small talk).
Examples:
- Few minutes early to conference calls? Don't always let the line remain silent.
- Schedule formal 1-1 calls and purposely build in some "meandering" time into the agenda (especially for managers of any team who should be scheduling 1-1s with their directs anyway on some cadence).
- Jump on rare lulls, pauses or other appropriate moments during phone calls or IM chat conversational flows.
- Reach out and IM somebody during a known break period (admittedly, this has a low success rate for me due to differing timezones).
Remote staff are starved for information about their teammates. Some remote staff don't care. Others are clueless, in which case they should be classified as-such and you may adapt your style of interaction. From my personal experience[NB] managing remote technical consulting teams, most people do in fact crave more personal connections across teams, but they need to make continuous, concerted (and sometimes disconcertingly) conscious effort.
This type of cognitive overhead is fair to classify as "extraneous" and "bothersome" by certain people, and some extreme cases of successful remote teams (examples: interacting almost entirely via mailing lists, high ratio of long form vs. short emails) do not seem to maintain or require this overhead.
However, for the rest of us working in 99% of other organizations, remote staff can generate the same type of buzz, high-energy and high-performing team outcomes that Dr. Pentland studied, iff the remote team members are collectively willing to build personal relationships with each other.
I've worked remotely my entire career and one shared aspect of the most successful teams was a chat room named "watercooler" or similar where people were free to chit chat. Everyone knows to ignore the room if busy, so there's not that worry of IMing someone and distracting them. Some times people may reply back hours after you say something, but when a few people have spare cycles at the same time nice conversations can break out.
It's curious to me how when a lot of discussions on remote workers, especially those negative to the idea, I rarely see mention of chat rooms, when I've used them at every single place I've worked remotely. Most of my career success is due to connections I've made on IRC. I don't think this is that rare of a scenario, see the #w00w00 folks.
In the era of "catfishing" where people can fall in love with people based solely on chat and online relationships, I think it's hard to deny it's possible to form meaningful connections online. Emails, conference calls, and video conferences aren't going to do it. If you spend 8+ hours a day "talking" to some one in a chat room, you can learn more than 15 minutes at a water cooler now and then. As well, the whole team/group can read the backlog and know what's going on with everyone else. No need to repeat the same story to x, y, and z.
I agree with what you've said about having some informal conversation during lulls on calls. Those moments can be very valuable. Another thing I've done on some teams is after a major release or milestone achieved, everyone grabs a drink of their choice and joins a group video chat and virtually goes out to the bar to celebrate as a group.
Lastly, one of the things I've done is occasionally send small gifts to other team members. As an example after explaining rubber duck debugging to a team member who solved their own problem immediately after asking me and wasn't familiar with the term, I sent them an awesome rubber duck overnight. (Total cost <$10 via prime)
The watercooler is a great idea for distributed teams who lean more heavily towards chat as their communication medium.
Because my teams are typically customer facing, we have enough team conference calls (both internal and external) that there are enough moments for people to perform a similar function, albeit most of the time truncated or abrupt.
I share your enthusiasm for chat rooms ala IRC but as you've already noticed this only appeals to a certain subset of [technology] people. #w00w00 is more of an exception in my mind; most IRC channels aren't exactly the hotbed of singularly driven participants, but then maybe the channels I frequented had a low SNR.
>Another thing I've done on some teams is after a major release or milestone achieved, everyone grabs a drink of their choice and joins a group video chat and virtually goes out to the bar to celebrate as a group.
This is a good idea! When a sufficiently important milestone is completed I endeavour to have geographically close clusters of folks fly/drive to meet up, if possible. However, joining a group video chat (hell, video chat in general) would be interesting to introduce. I think video goes a long way to closing the personal gap because you can immediately pair a face with a known name and voice. Sadly (in my view anyway), there are a few folks I still haven't met in my organization face-to-face despite working over 8 years together.
I was interested in this aspect as well. I'm a big believer in the ability for teams to work remotely and asynchronously at the same level of effectiveness as in-office teams; I wonder what the research would look like for those types of teams.
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.
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.
Lua also have hybrid array, maps and object. It does work well when implemented in a sane way. Lua has different way of iterating the table if you want an array or maps.
... though I wouldn't necessarily call Lua's way of doing things "sane". E.g. if Lua encounters a `nil` somewhere in your table, it will stop iterating.
It's certainly sane in the sense that it was an intentional, if perhaps unusual, design decision. I personally like it since it results in an efficient implementation of sparse arrays.
In any event, Lua 5.2 will respect the __len, __pairs and __ipairs metamethods, so you can tweak this behavior if you need to store nils in your tables and iterate over them.
The world would be a beautiful place if everything intentional were sane :-) It's bitten me a couple of times (e.g. when unpacking arguments in a function to feed them to another function, where one of the arguments is nil) but I can see how it could be the desired behavior in some cases.
Javascript's arrays cannot be used as maps or associative arrays. Arrays require numeric, consecutive keys. Otherwise it's an Object.
--
Clarification edit: Creating a new key on an array using arr['key']=1 creates a property on the arr Object but does not add an element to the standard array.
The array prototype functions are only specified by the standard to deal solely with numeric keys, but the lines between and object and array are still pretty blurry. The use case for each is different, but the original question far above was "array/map combo. Have you ever seen anything like that in another language?", and clearly JavaScript is very similar even if not exact.
var x = {};
x[0] = 1;
x.length = 1;
x.map = Array.prototype.map;
x.map(function(y) {return y;});
//[1]
No, it doesn't. The only magic per spec is about the "length" property (which is essentially a getter/setter pair, despite being a data property and not an accessor pair). That's the only thing special about arrays in JS.
While I agree with you, Erlang for instance has collections as primitives (lists/tuples), but then offers more complex collections (such as gb_tree) as part of the stdlib.
"Tuple" tends to refer to fixed-size collections where each element may have a different type. The tuple type is the (cartesian) product of those types. For example, the type "a tuple containing 3 Booleans" can be written as `Boolean * Boolean * Boolean`.
Since Boolean is type 2 (ie. it contains 2 elements, `True` and `False`), this makes our 3-Boolean tuple `2 * 2 * 2 = 8`. True enough, it has 8 elements: `(True, True, True)`, `(True, True, False)`, `(True, False, True)`, `(True, False, False)`, `(False, True, True)`, `(False, True, False)`, `(False, False, True)` and `(False, False, False)`.
Likewise, a tuple like `(1, "hello", True)` has type `Int * String * Boolean`.
That's why tuples are "composite types", they're the product of other types.
Arbitrary-length collections are more complicated, since they require recursion. The simplest is a singly-linked list with all elements of the same type `T`, which is given by the equation `list(T) = 1 + (T * list(T))`. `1` is the unit type `void`, which has one element (`NULL`), which represents the "nil" at the end of the list. The `T * list(T)` is a tuple containing a `T` and a `list(T)`, ie. it's a "cons cell". The `+` is a (tagged) union.
For heterogeneous collections, where the element types can differ, things get more complicated, since we need to establish the (potentially infinite) structure of the type, and where each component type fits in.
Dynamic languages use one big recursive type, so all of these types just-so-happen to be the same, and we get tuples-of-tuples(-of-tuples, etc.) via the "top-level" recursive nature of that single type.
In contrast, a "primitive type" is one that's not made up out of other, simpler types. We can usually treat the empty type 0 and the unit type 1 as "primitive", since we can't define them out of simpler types. We don't have to use those as our primitives though, since we could choose some 'larger' type, like 5 (the type with 5 elements) as primitive, then use quotients and subtraction to define the others (eg. `5 / 5 = 1` and `5 - 5 = 0`) but it's much more elegant to take 0 and 1 as primitive.
Particular languages may choose to make other types primitive, eg. Int32 or Float64, eg. if they want to treat them specially with hardware optimisation and such.
> 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.
"[...] most uses will treat it either as an array (list of items) or as a key/value store (map from key to value, or sometimes set of values), but rarely as both at the same time. [...] In this vulnerability, the programmer expected a sequence, and was handed a mapping. [...] all uses of a single variable should be consistent (never use a sequence method on a mapping variable or a mapping method on a sequence variable). As shown in this vulnerability, "foreach ($data as $i => $value)" is a mapping method; it should never be used on a sequence, even if it works."
> It would be nice to have separate types for arrays and hash tables 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.
By using a doubly linked list, where the first element in the "bucket", contains the next pointer to the next element in the hash table. Read zend_hash.h & zend_hash.c It is fairly complicated and explaining it in depth is beyond the scope of this comment.
This "bucket" also handles the collisions by using separate chaining. There is actually two "next" pointers, one for the chains, and one for the next element in order of insertion. Very confusing and requires reading through the code and playing with it.
You put things in order by memory address and they stay in order when you access them. An array is just a special case of a hash map -- one with a trivial hash function.
That's why the lend themselves to the same syntax so well.
> arrays (aka maps) are basically used for everything.
This is interesting. In fact, I believe object properties share the same mechanism as associative arrays, that is, $a->b will actually lookup the hash of "b" in $a. Does this new hashtable layout influence object properties/methods too? That would be huge!
> Does this new hashtable layout influence object properties/methods too?
Not sure, but I don't think so. Ppl often think object properties and arrays are much alike, but the array's HashTable struct and the object's store struct are very different. The main performance gains are not about the buckets (which are simple and quite alike) but the array's hashtable idea.
Often objects (php>=5.4) have a better performance than arrays; arrays have an undefined length while with good code, all object properties are defined at compile time. Because of this, you don't need to store the data in a hashtable. Nikic has a post about this subject too: https://gist.github.com/nikic/5015323
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.