Let's consider them as market forces. Likes are internet currency. In that context dislikes are a secondary currency that doesn't have a clear value. Dislikes tend to depend on the content and current cultural norms to determine why the dislike was added. Their value is not easily determined. For a controversial creator a dislike may actually be a badge of honor. For a DIY creator it's a major negative. Due to this apparent ambiguity in the value of dislikes and what they mean I don't find them worth while.
I wonder what the secondary consequences will be. The gig worker law had some nasty secondary consequences for musicians and such. These regulations really seem to hurt the little guys.
That said, the law is short and doesn't even go to deeply into what an "agreement" is. So maybe it's ok?
well, the gig worker law never got to do it's intended thing, first cause the stays, then cause prop 22, so now it should just be repealed. Had it, at least the distortions for musicians that are also Uber drivers would have been the same.
I would by the other's argument that this is about preventing misrepresentation. In fact, perhaps it should have already be covered by trademark protections anyways.
I agree. A downvote has more chance to be done as a result of our disgust response. As I understand it, the disgust response preempts our reason center. Obviously, that does not lend itself to a better discussion. Reasonable and rational dissent to an idea seems like a better idea than a knee jerk response.
It could a number of reasons. We are human, after all, and as such we cannot be trusted to logically and fairly evaluate anything. Better to let the computer stop us from suppressing speech simply because we (insert emotional response here).
None at all, except that a contributor who participates in the project, but objects to a position or practice of the advocated organization is presented with an ethical dilemma that is avoidable. BLM is not alone in being controversial in some of it's positions. Lots of other advocacy groups (Autism Speaks for instance), have a polarizing affect on people. I think it is better to avoid these ethical dilemmas in favor of cooperation. It is easy to condemn and exclude based on ideas, it is much harder and more worthy to find ideas we all agree on and build useful things for everyone.
But most people seem to have no such ethical dilemma. The dilemma only exists for those whose political views are already opposed to those of the project owners, and who refuse to contribute on that account - neither a neutral or apolitical position, but one of intransigent political opposition.
So rather than simply avoiding ethical dilemmas in favor of cooperation (because plenty of people are cooperating) what's being advocated here is concession to anti-BLM advocates exclusively as a prerequisite for their participation, and those are the only people condemning or demanding exclusion of anything (specifically, the political views of the project owners.)
Because again, no one is saying that people who don't support BLM aren't allowed to participate.
It's open source software, and as is often mentioned when someone objects to a project owner's right-wing views, software is apolitical, and contributing in and of itself is not advocacy. And forking is always an option.
All of that is valid, and I don't disagree on most points.
However, we have a stupidly polarized political climate right now. It makes "agree to disagree" pretty tough since the press and social media tend to stir people up.
I think it's better to rise above the noise and focus on building things. I know people on both sides of the political spectrum that are good people and good engineers. I'd rather focus on common ground.
You sorta proved the point inadvertently. Sure, if you don't support equal rights you are a bit of an ass hole, but BLM and other organizations can and should be legitimately criticized. If they can't be then they are in danger of corruption without those checks and balances. Exactly 0% of that is in a technical project's wheel house.
Politics being as divisive as it is I'd prefer it stay in the political arena. In America that stuff is pretty toxic right now. I'd rather not git pull that mess into other parts of my life.
Right now I'm prefixing variables I don't want external actors to change with underscores, which doesn't actually do anything, so is arguably more of a hack. :P
Closures in JS are basically objects that have only one public property (called apply).
Modern JITs are good at optimizing static objects (provided props are never added or deleted and the types never change). There is still (from what I remember) a small performance increase to normal objects, but it only becomes significant if you are creating hundreds or thousands of them.
I'd say that in typical cases though that closures should be faster because devs tend to use them in ways that are easier to optimize (Closures don't ever add/remove properties and types are much more likely to stay the same).
> Closures in JS are basically objects that have only one public property (called apply).
Never heard it explained this way. Can you elaborate a bit? I'm not sure I follow. Couldn't a closure have any of the same properties that other functions have? Call, apply, bind, length, etc, etc.
When you execute a function, you set the program to execute the new function, but first, you take care of the related bookkeeping. A very important part of that is the function scope(s).
I'll first explain prototypical inheritance (because the two have close parallels). When you access a property in an object, a method runs behind the scenes. It does something like: search all the keys in the given object. If there is a matching key, return the value. If no such key exists, check for a __proto__ key. If it contains a value, call this function recursively on that object (and return whatever it gives back). If there is no __proto__ value, return `undefined`.
Let's assume an interpreter (to make it easy). Before we call a function, we need to setup the closure. The closure is an object with the names of all the variables you defined plus a few builtin things.
As we parse the function, any params, `var` or `function` statement creates an entries in the object. The values for the params are then pre-defined from the stuff provided by the caller. All the function statements are also pre-compiled. We add internal values for the return value, the parent closure (we'll call it __closure__), and some other things.
As the function runs, we come across a variable name. We then call a method to get it. That method searches the current scope for the name and returns the value. If none is found, it returns the result of calling itself on the __closure__ object. If no such object exists, it returns a `ReferenceError`.
Modern JITs do many fancy things with closures (just like they do with objects), but this basic mental model should cover most things.
There are solutions, but people want a syntax solution for it. Personally, I think that private instance properties should be a separate proposal from static and instance properties. That way, people could decide if they want some of it, or all of it.
