"This will teach them a lesson they'll hopefully never forget".

Most individuals learn, not everybody. Some organizations learn, not all of them. Humanity almost always repeats past mistakes.

The same forces that made people use the "IE-6 only solutions" will always exist. New MBAs and engineers will keep only these forces in mind and will not even consider the impact of their decision on the "potential" distant future. It is not that they will not be aware of the dangers, it is just that feeling the pain in person is not the same as the theoretical knowledge about pain.

A document can still be shared, via URL and still be private as follows:

As a dropbox user I want to share a file with you, but you are not a registered user. Dropbox generates and sends you a URL. Once you open the URL from a browser you get a cookie and the URL is no longer valid without this cookie. After this, no one but you can use the URL.

Disadvantage: you can open it only from a specific browser on a specific machine.
Solution: If you open the URL from a different browser you get the option to get a new URL (to the original mail-box).

Not perfectly secure if someone (e.g. NSA) reads you mail, but good enough.

Sounds quite simple and reasonably secure to me.

I should have patented this great "invention". Clearly it is not trivial which is "proven" by the fact that dropbox did not implement it.

You are right that the basic concepts of SAT solving can be understood by a smart person with high school math experience. But I don't agree that this is as simple as that for the fine details of modern SAT solvers. Some solving steps are non-trivial and look weird some times. Especially the steps that the solver takes to simplify the problem, in the middle of the run.

Today, SAT is not only about binary resolution. Some of the stuff is difficult even for Grad students. There are hundreds of non-trivial papers describing proven and effective algorithms, and thousands more with a good potential. I know only a small fraction of this as this is not my main field of research, but occasionally I read a research paper on SAT when it catches my eye.

As someone nearing the completion of his Ph.D. in a subject close to SAT I can say that SAT does not resemble "one big for loop", not a bit. A modern SAT solver can solve problems with millions of variables and hundreds of thousand clauses. In contrast, a brute force for loop would require O(2^N) iterations where N is in the millions, which is like eternity. As an exercise, please try to write a trivial solver that can handle even 100 variables.

Also, unlike what you may think, a SAT proof is not a list of "I tried a=1 and it did not work out, and this is the proof that a=0". A standard SAT proof deduces new clauses from the original problem by applying the resolution rule repeatedly. The newly deduced clauses reduce the search space and, if the problem is unsatisfiable, the solver ends up with the empty clause, which is always FALSE. The proof is a collection of resolution steps that lead to FALSE.

SAT solvers are AI at least since:

• 1. They employ search (not unlike chess game).
• 2. They have non-trivial heuristics (not unlike chess game).
• 3. The heuristics evolve and improve over the course of a run.
• 4. They are able to deduce new clauses from the original problem.
• 5. Many solvers employ a lot of smarts to simplify the problem even before starting search.

SAT is clearly NP complete, and clearly the existence of good SAT solvers is not a proof that P=NP. This means that there will be relatively small problems that SAT solvers won't be able to solve. On the other hand, most real-world problems have a hidden structure which SAT solvers are able to find and use to their advantage.

How much energy it takes to switch 0/1 states? What voltage? As I am not in the field, it would take me too much time to extract this information from the article (what is "trimeron annihilation" and how/does it relate the classical hole-electron recombination?).

I assume that it is possible to be 1000 faster only if it takes considerably less energy to switch states. It means that even if the latency constrains the speed, it would still produce less heat and will allow simpler clock/power lines.

As I understand it, one of the major factors that slow the speed of today's electronics is power. Be it in the form of routing constraints (possibly wider metal lines and possibly wider minimum distance between them), power dissipation, battery capacity in mobile devices, or cooling in servers, all are constrained by power. If this technology can lower power requirements then there will be a significant speed-up either in the form of more cores on a chip, or newer computation models that work better with deeper pipelining or with wider SIMD operations.

Another potential advantage of the fast switching is that it enables or enhances other computing models. Maybe we will move farther away from a pure CPU programming model to an FPGA/CPU hybrid programming. It's time to brush up your VHDL/Verilog capabilities, or to teach your pet language (compiler/interpreter/JIT) how to emit an efficient HDL. The advantage of FPGA programming is that you can define your own pipelines according to the computing task at hand. Another thing to consider is that with these switching-speeds it could be profitable to time-share an FPGA. Finally, it may be possible to reprogram an FPGA in less than a second.

Now my 7 years old daughter wants me to teach her programming, and I don't know what to do. She is so eager, and I really like to see her eyes shine when she understands one more thing. But if she will start to program she may have the same fate as I, no interactions with the opposite sex before the end of high-school.

I wanted to joke and say "maybe that is a good idea, she would not meet boys!", but that is so untrue. To be a healthy adult, one must have interactions with the opposite sex in earlier years. Not all interactions are positive, in the short term, but with the right parental support they can build a stable personality. It does not mean that it is easy, but I do believe that it is the right thing to do.

My love to programming had ruined my adolescent fooling around with girls, which I regret, and I don't want her to do the same.

When I was in 7th grade, a friend of mine went to a course. He showed me flow-charts and how to program PL/I. These were the last days of punch-cards where you had all your best to write your code bug free from the start, and flow-charts really helped organize your thought. I was so excited about it that I would draw floating-charts for almost every daily operation, such as using a public phone.

Every day, on my way from school, I would pass near an electronics store with a VIC20, and later a C64, on display and stare at the window. After saving all the money I could, and after two summer-jobs, I managed to buy a C64 with a floppy disk-drive. Quickly I realized that Basic was too slow for almost anything, so I started programming in assembly. Assembly was great, a bit ugly but fast and compact. Once I knew assembly, I was ready for the next step.

Both C64 and the floppy-drive came with a basic schematics, so I learned to program both at a very low level. I liked the ability to control the things in an accuracy of one cycle. I remember that C64 had a single-colored frame at the edges of the screen, and using the cycle-accurate documentation I was able to draw stuff on the edges of the screen by flipping the color in-sync with screen's ray. It was very low-res, yet impressive. When my friend demonstrated my program to our computer class teacher, the teacher would not believe him that I wrote the program.

Nowadays the CPU and the memory units are so complicated that it is impossible to be cycle-accurate like with the 1MHZ C64. Today, with all the abstraction layers and pipelines you never really know what is going on the inside of your hardware. I miss the fun of the old days, but I wish I would had the drive, back then, to meet girls or to hang-out with friends. Instead, I was stuck in front of my computer most of the day trying to write a compiler. I was trying to convert a bit-map to a sequence of assembly instructions that would draw it on the frame, but then era of the IBM-PC clones exploded into existence.

No, the logic problem is with sugar free cans. Many obese people drink sugar free sodas, hence no calorie intake
and my argument fails. However, in the case of sugar-free drinks the correlation != causation is reversed:

Who drinks sugar-free sodas? Obese people probably more than others. So if you are obese, my guess is, you have
a greater chance to drink soda with or without sugar. The paper talks about calorie intake, but with sugar-free
sodas you practically have no calorie intake. And yet, you get BPA for free.

I can think of dozen other things they did not account for. They are simply measuring the wrong thing.

Did they consider the timing of soda drinking? During lunch at school (more likely cans), or
while watching TV (more likely bottles). There are studies that correlate drinking at lunchtime
with weight issues.

How about 2L bottles being used by other member of the family and visitors, making it difficult to estimate the caloric intake of soda for any family member. Caloric intake is very easy to get wrong unless you perform complicated
measurements. Counting calories according to what you think you ate is only slightly better than guessing.

Some people forget to add up the calories of the huge amount of calorie-loaded sauce they add to the salad,
or the obscene amounts of oil and butter in almost everything they eat.
So maybe the lack of BPA is correlated with overestimation of caloric intake for the drinkers of L2 bottles?

Also, obese people like to drink soda during lunch (canned). If they somewhat care for their body they hope that
drinking sugar free soda will save them. So they are more likely to get a lot of BPA without additional calories than
people with a healthy weight. So, maybe they are obese because all those artificial sweeteners? Did they check
the urine for that?

If I really wanted to "prove" that artificial sweeteners are the cause for obesity, I would probably would find a way which
would look as convincing as this study. I would also be able to "prove" that people who eat a lot of quinoa are more likely to get smallpox, despite vaccination.
[hint: the link is vegetarians/new-age/vaccination level of friends]

I don't say that they did it, they almost certainly did not, but cooking-up wanted results is significantly easier than
detecting it in a review. Similarly, if the distance between the alleged cause and effect is too big, as in this case,
it is almost impossible to rule-out causation!=correlation errors.

Many, if not all canned drinks contain bisphenol-A.
Don't people who, instead of water, drink substantial amounts of canned and sweet beverages become obese?
Hence, if you get a lot of BPA in your system you are have good chances to be obese.

So what's the news?

(There is a small problem with this logic, which can easily be fixed ; I was lazy)

The stricter the US internet laws are the bigger the chance it will be cut off of the rest of the internet. If the most of the internet users live in freer countries, they will use a different set of DNSSEC resolvers. This means that internet addressing will become fragmented between the US and the free world such that the same address means one thing in the US and another in the free world.

The economic impact on the US, of such a fragmentation, will be considerable. It will be a natural continuation of US economy's decline. As usual the brilliant politicians will blame the situation on pirates and will continue to draft even stricter free-speech (anti-piracy) laws.

I am glad that I do not live in the US, but this situation may change. Unfortunately many countries tend to copy the worst US practices (laws and behaviour), over time. We may end up in the US fragment of the internet and not where the rest of the world is.

Being a fast typist I don't mind writing a lot of comments that I intend to delete at the end of the day. I don't mind writing 2 or 3 variants of the same code just to see what approach is more understandable and maintainable. I don't see the slow typists writing comments describing every parameter, pre-condition, and post-condition. When one argument of a method changes its meaning, I don't see the slow typists rewrite method's description when it is much clearer to do so.

From their website they are solving a simpler problem:

9x9 Sudoku problems that you find in magazines or online are trivial Constraint Satisfaction Problems (CSP). Trivial CSP solvers can solve thousands of these in one second. By solving such a trivial problem I am not sure that their work can be scaled to more complex variants. Their 4x4 variant is so simple that it can even be solved efficiently by a trivial program which can be written from scratch in a couple of hours. This is in contrast to the general problem which is in a completely different class.

Assume that your kid forgets/loses house keys every other week, in which case your neighbor sends an urgent e-mail titled "Your kid can't find his keys, again!", which happens the only e-mail he/she ever sends you. Now assume that you never reply to this e-mail but rush home, instead, to open the doors.

Is this Google feature going to downgrade this repeating e-mail, just because I never reply to it?

For you single nerd types, how about an automated "XXX system is going down for reboot". You may want to look at it in time, especially if you try to analyze this XXX system recurring issue. (I guess that most people would not use Google for this due to privacy concerns)

Injecting random, but smart, inputs and automatically checking the outcome is much more stimulating than the boring stuff you are talking about. This will stimulate your mind and your code much more than going over a list of events one by one.

In my experience around 80% of the bugs that my random tests detect happen in a combination of events that I would have never thought of testing. I also make sure that the simple events, a tester would think of, would have a reasonable chance of being tested.

So, what's the magic? Pure random testing does not work, it has almost zero chance of hitting bugs. Instead, think of corner cases in your input and give them a higher probability (e.g. zero sized string, MAX_INT, MAX_INT-1 and so on). Finally, generate different tests with a different "entropy" otherwise you are testing the same thing over and over again. This "entropy" thing is tricky to explain and to notice. For example, if your input is a bool[1000] and you randomize your elements independently (half True and half False) then, practically, you'd have a zero chance of getting 1000 elements of the same value (which could trigger something interesting)

The final thing is to check your outputs by validating invariants in your code, either both from inside by using assertions and from outside, finding good invariants is like a riddle. The details are too complicated for one post.