This would be great if it wasn't for the fact that during the last decade(s) people have been fitting multi-socket halogen fixtures instead of single bulb standard socket fixtures in their homes. I'd definitely love having an app-controlled lighting system, but it would have to be much more flexible than just a bulb or single socket solution. For light fixtures with several low power halogen lights I'd have to hide the control unit somewhere before the power is split to the individual halogens, i.e. somewhere in the fixture or as a special lightswitch (essenially then a controllable dimmner switch). All the light fixtures that already have dimmers would have to go the same way: the wheel dimmer would have to be replaced by one that can be controlled by the app.

As long as I can dim 3 out of 4 lights but still have to get off my ass to go turn down the fourth light (at the same place where I could dim them all), there is very little gain. As soon as someone offers a simple solution that is expandable to existing switches, multi-socket fixtures and so on, i.e. beyond standard bulb/socket then I'm in.

I use windows 8 and don't get what the fuss is about. I basically don't use the metro interface and don't intend to ever do so until I can do ALL my work in it. That is, I don't dislike the UI per se, but dislike having to switch back and forth. I don't really care if MS gets a share of what I pay for applications either, but here is the chicken and egg problem: I won't buy any metro apps until I use that interface. I won't use that interface until I can use it exclusively. I won't use it exclusively until all my applications are there.

They will never, ever be able to remove support for the legacy desktop apps that is what keep customers from moving away from windows. What they WILL do however, is realize that home users don't really provide as much income as they should for microsoft. Apple is a shining example of a company that makes money from consumers, not business. Microsofts cash-cow is income from people using workstations and servers in offices around the world. So the question: How can microsoft make good business from consumers, without risking their revenue stream from business? Answer: by separating the tiers further. Make desktop/legacy a "premium" product, and sell the consumer OS cheaper by forcing users to adopt apps that give MS a piece of the revenue. I predict that the desktop will live forever, but only in the higher SKU:s of windows. Meanwhile, microsofts "Home"/OEM offerings of windows will steadily become cheaper and slowly move into an apps-only ecosystem.

Assume the server has a database of hashed passwords, using one of the now vulnerable hashing algorithms. What the client is sending is for example a https encrypted password, not a hashed password? if you are the man in the middle, you are dealing with encryption not hashing? The https request is decrypted on the server, the plaintext client password is then hashed and compared to the hash in the database. I don't see how a man in the middle is related to hashes? (Then again I'm not a security guy in any shape way or form). As far as I know hash vulnerabilities are mainly a concern when the password (hash) datbase is compromised, which happens sooner or later.

Thus not only proving they didn't read the article, they didn't even properly read the title. "restore GAINS of moores law". Which is perfectly correct.

This research doesn't change that. What parallel programming is about, is currently three steps 1) find parts of code that can execute in parallel (reasonably simple), 2) make sure there is no shared mutable state (hard), 3) make correct threading implementation (tedious

The problem with todays (OO/imperative) languages and tools is that it is exceedingly hard to make sure that state isn't shared. It is also very hard to test for, and find bugs related to shared state. This research helps with step 2. You still have to figure out where these boundaries are, but you can make sure it is correct, by letting a compiler check this for you. It can also help you with step 3, but if your assumptions are correct that isn't hard in current tools, just tedious. Things like TPL and PLink have greatly simplified step 3), but what I assume MS have found out is that with such power to parallelize, developers are spending more and more time in step 2, thus gaining very little.

Maybe read the article? Maybe just the title? "Help restore the GAINS of Moores law.". That is, since these days the extra transistors we put on cpu:s just go to more cores and not faster cores, we don't gain as much as we used to until 2004. These days to actually GAIN from Moore's Law, we need code that actually use these transistors, i.e. parallel code.

Shorter article:

Installing huge enterprisey things SAP and Oracle software is harder than using a package manager to install Apache.

Funny the article/link/source didn't show up now that you mentioned it, either.

For a long while I thought Mitt's official twitter account was a parody account.

Quite a few things, for example less sword rattling in the Iran/Israel region (A war would reduce US purchasing power and affect global economy just like Iraq did). Less of a "trade war" with China (calling them a "currency manipulator on day one" certainly doesn't help trade & relations.

Apart from these things that actually may affect me, I'd enjoy seeing that the greatest power in the world can hold an election that can't be bought or stolen by special interests. Would also be refreshing to see that the greatest democracy in the world have policies on reproduction/abortion/education/science that can't be mistaken for Taliban policies. That, and watching Fox News pundits heads explode for a week.

Let's just say that however flawless the language, you will still make countless simple mistakes in *logic* that will be an order of magnitude quicker to diagnose and fix with an integrated debugger than with any non interactive means (logging, exception stack traces, command line debuggers).

I would argue the opposite. If you execute code it will invariably do things you didn't expect, regardless of language. You either debug or guess. I saw no argument as to why guessing is preferable to interactive debugging? I agree that "null" is a language smell, but there are concepts like code contracts that lets you have non-null enforced etc. There are a million other things you can debug regardless of language.

Most bizarre conclusion I have ever seen. Of course you can have highlighting and other editing tricks (autocomplete, etc.) in a text editor. But once you add things like unit test integration, deployment, and most importantly an interactive debugger where you can step through your code, you have a proper development environment. Running tests can be done at a shell prompt, but debugging not so much. And if your text editor ticks all these boxes, including interactive debugging (I'm sure emacs can for example), then your text editor IS A FREAKING IDE ALREADY. I'd like to make the inverse conclusion of TFA: since we have proper IDE:s we can now allow the code in modern languages to be structured an way we want. A good IDE should never have you worrying about files, just code.

The use of modern tech does not imply better code, but it certainly helps your work environment. A company that is quick to adopt new technology (e.g. Update to new language versions) has a better possibility than a company that doesn't. Make sure you talk to the guys involved with the technology. Interviews and screenings with recruiters are quick affairs, save your questions until you meet real developers. If the company doesn't have the actual developers and team leaders doing interviews, that is not a good sign. Third, make sure you find out how fast the crew is being replaced. A team of ten should have at least a few that have been there virtually forever, and you don't want to join that team if it has recruited 20 developers over the last 5 years. This is the most important thing: you want the same as every other developer out there. So a company where people work 1-2 years either has a technology problem or a serious pay/environment/cultural problem. Either way, you don't want it. Ask how many have left the last few years, and try to find out why. If you can't get this information, leave.