> Consider the following example:

  if (cond) {
    A[1] = X;
  } else {
    A[0] = X;
  }

> A total license implementation could determine that, in the absence of any undefined behavior, the condition cond must have value 0 or 1.

> If undefined behavior occurred somewhere in the integer arithmetic of cond, then cond could end up evaluating to a value other than 0 or 1

I don't even follow this very first example. Neither C nor C++ have any requirement that their condition statements be given 0 or 1.

In C:

> the first substatement is executed if the expression compares unequal to 0.

In C++:

> The value of a condition that is an expression is the value of the expression, contextually converted to bool

Where conversion to bool is defined as:

> A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true

I'm sure such a thing could occur if cond had a boolean type but contained uninitialized data. That would be similar to the situation talked about in this link: https://markshroyer.com/2012/06/c-both-true-and-false/

I, too, scratched my head over that for a while, and eventually realized that I had probably misunderstood what the authors are trying to say.

I think what they mean is that if the compiler has analyzed the code, not shown in the example, that comes before the if statement, and concluded that unless something undefined happens, cond can only be 0 or 1, then it can optimize out the condition.

They are not saying that the code actually shown is enough to conclude that cond must be 0 or 1.

Yeah re-reading the wording now I think you're right. It's this part that throws me off:

> could determine that, in the absence of any undefined behavior

"could determine that" based on the code example shown

vs

"could determine that" based on static analysis performed on some preceding code

It would have been a lot easier to wrap my head around if it were an example where cond could be 0 or 4 or something along those lines. It would really underscore the compiler's desire to reuse the cond as the index.

I found it odd that the author seems to think that empathy for the individual is somehow at odds with caring for the many, instead of being closely correlated. As if removing empathy would somehow get people to care more about each other, rather than less.

What I think wikipedia needs more than anything is a new way to propose an edit without actually committing it, and to be able to solicit feedback or have others fix it for you before having it finally approved and submitted. It needs to be something where an inexperienced editor can make a good edit proposal without having to be completely versed in wikipedia's editing policies.

Talk pages are a horrendous way to implement this. Making an edit proposal should be extremely new-user friendly.

I think a proposal and dialog format would do a much better job at absorbing new content than what happens currently, which seems to be a revert if you run afoul of any editing policy.

Yes, this is an idea we definitely want to try at Wikimedia.

Right now, some of our most popular articles in English are perpetually semi-protected, meaning anonymous or brand new contributors can't edit. That means millions of pageviews are on articles that don't even have an edit button visible. :(

Some Wikipedias, like German, Polish, Russian and others already use a system called "Flagged Revisions", which is an obtuse name for software that instead of protecting a page, delays edits and makes them subject to approval from someone experienced. Unfortunately the workflow for this software is clunky and it doesn't seem to be helping German and other Wikipedias stay vibrant.

I'd really like to A/B test a very easy "suggest an edit" as an alternative. I think it could work, because Wikipedians are already pretty good at staying on top of the request queue, if you manage to make a request on the Talk page. One thing we'd need to be careful of is not garnering suggestions by cannibalizing the people who would otherwise have just edited.

I would keep all the normal editing methods in place, but just add this as a friendly alternative for new users.

This is a fabulous idea. More experienced WPedians could then offer advice as to what would make the change acceptable (must be cited to an actual policy) and the person doing the edit could keep working until they fulfilled the requirements, automatically completing a valid edit. There would be no possibility for immediate revert and any edit made this way would have to persist for some time.

Making self-driving cars safer than people-driven cars is trivial. The hard thing will be handling the tidal wave of FUD when the inevitable happens and someone dies as a result of one. Google or Nissan or whoever will need a mountain of good PR and safety statistics to be able to push it back. That alone is enough reason to motivate the creation of "hyper-efficient safety mechanisms".

I think an interesting implication of this is that people may feel satisfied having purchased something useless that seems to have enough "stuff" in it.

I think the idea is that if the manufacturer was the only one selling, that they could inflate their prices higher than what the middleman overhead would be since they're the only one offering that product.

Why he thinks competition between brands isn't enough to counteract this I have no idea.

> I think the idea is that if the manufacturer was the only one selling

But aren't they the only ones selling tesla cars to the dealers anyway? Couldn't they just inflate their prices to the dealers?

Exactly. Price differences for the very same product is not competition, its market inefficiency.

He gave a sincere followup. It wasn't sarcasm.

I really think Android should add another layer of protection here, similar to the "This app wants to use your location" prompt in iOS. I'd like to be able to install an app that might need to access my phonebook in some use case but be able to deny it when it attempts to access that information when I don't want it to.

For example, I'd want to be able to use the facebook app and many users might even want to have it scan their address books in order to find friends. However, if the app attempts to read my address book when I'm just checking someone's status update that is clearly not okay and I want to be able to block it.

The free pass to pillage my phone upon installation doesn't sit well with me.

> I really think Android should add another layer of protection here, similar to the "This app wants to use your location" prompt in iOS

Most definitely. This has always been my argument against the whole system: installing apps that need excessive permissions is basically blackmail. Just like "Do you agree to the terms of service?", you hardly have a choice. I was very surprised to see people not even glance at the permissions before clicking Accept.

But as I said, it's blackmail anyway whether you look or not. You don't want them to have all your contacts, your exact location, all data on your sdcard, and full network access? Fine then, you won't get [whatsapp] (or pretty much any other app), that what everyone else has and that you're almost socially obliged to have (at least in my age category).

It even goes so far that the android user has no permissions to use the permission manager to deny or allow permissions for apps. There are commands ("pm grant x" and "pm revoke y") that lets you change apps' permissions... but you can't use it by default, even as root ("java.lang.SecurityException: Neither user [your uid] nor current process has android.permission.GRANT_REVOKE_PERMISSIONS"). It's totally messed up.

On a rooted android phone, it is possible to install apps but not give the the permission. Of course, that usually means they will crash then they try to do something, but it gives you a layer of protection if you want to try the app out or something.

If the author wants us to discuss the point he should get to it faster rather than droning on about apple stock and product pipelines.

300 words isn't so much that it's cumbersome to read, but it definitely primed me to think that his point was somehow specific to apple and investing when it wasn't at all. I'm not surprised that people have decided to nitpick it.

Yes but instead of nitpicking to criticize maybe we could use the same skill to filter out the bad parts and get to the good parts. I'm not saying I agree with the way the author presented the information, he thought it was the best way but that doesn't mean I have to completely ignore what he wrote based on that fact. It's pretty obvious to see in this post the relevant part to HN.

I think Machinarium is a good example of how you can preserve the fun frustration of adventure games without pushing people to cheat. They would allow you to play a mini-game in order to reveal some extra hints which would push you in the right direction enough to figure out the rest on your own.

In Monkey Island I would sometimes get annoyed and google for what to do out of angry frustration. It was easy for me to throw my hands up and say "I don't give a shit any more, time to move on!" Lots of times the solutions made zero sense to me. In Machinarium I still got a sense of frustration and puzzlement, but I would try to forego the hints out of pride for as long as I could which made for a much more enjoyable experience.

You mean Altavista?

Machinarium's gameplay could (and should) be pretty much copy pasted onto lots of adventure games, both remakes and new ones. It's just perfect. I hope Amanita goes back to that franchise, there's still a lot that could be explored there.

I really liked the puzzle difficulty with Machinarium. I think I had to use the hints system once for one of the particularly difficult puzzles. Great game.