On an Atmel AVR with 2K of RAM, I found C++ works well. Of course you have to be conservative about using language features.

I can see how with multiple programmers at different skill levels its dangerous.

In principle with C++ you don't pay for what you don't use.

I was astonished when websites started asking for your login credentials for *other* websites in order to scrape your contact info.

The continued erosion of privacy is starting to look like the proverbial frog being boiled alive.

Google would love to have the Facebook and Linkedin social graphs. It seems credible that they would use your credentials to scrape your portion of the graph.

Of course they would put this in their next privacy policy, in suitably nice language, which would cause minor discomfort going down.

So I'm curious why you find the idea ridiculous. Do you not agree that Google desperately wants this data? Or do you think they have some ethical barrier to acquiring it?

But, alas, the second part of that equation â" Google Apps continuing to get better â" just isn't happening as fast as we'd like.
Seems to be a common syndrome. I think the root cause is that Google Apps is a weapon pointed at Microsoft's heart. Google and Microsoft probably have a lot of private conversations. Keeping this weapon pointed gives Google one more bargaining chip when dealing with MS.
Same syndrome when a big company talks about "switching to linux", if I remember correctly from years ago. They don't really switch to Linux, but Microsoft probably becomes more accomodating in their negotiations.
I imagine that inside Google, people developing Apps may be frustrated and wonder why management seems to be sabotaging them. This is often the case when management does the seemingly irrational for strategic reasons.

Actually, an Excel workbook can contain multiple sheets (or tables, as we say in database-land).

And Excel can connect to a database such as MySQL and become just a GUI front end. But when I saw this done around 1999, Excel crushed the DB with horrible queries.

> I take that to mean it is a public domain performance, too.

It means the vendor lets you have unlimited use of the music in exchange for a one-time fee. It's common in film production.

Yes, this is an ongoing problem, and it is what made Python the more popular solution. Perl is easy to write, but harder to write well -- the whole point of the language is that it is rich and expressive, without a lot of imposed structure. People who write Perl as they learn tend to write crappy, unmaintainable Perl. The result is that most students' first experience with Perl is of crappy, unmaintainable spaghetti-Perl. Those students often grow up to become Perl-haters.

Python is more novice-friendly but harder to to be expressive in for experts, so grizzled longhairs (like me) tend to scoff at it.

That sort of pattern happened before: there was a time when Pascal attracted a lot of mindshare and people scoffed at the woolier "C". Entire OSes were written in Pascal (gasp). But in the long run people migrated back to C and (when it was invented) C++, because, well, Pascal is easy to learn but it sucks for experts.

There are lots of solutions for getting one's work done. PDL is superior for some tasks, Python/NumPy is arguably superior for others (like learning). I wish people would get over it and code, instead of tribal hating. But that is what people, well, do.

Oddly enough, PDL has more "computing power" than NumPy, in the sense that its threading engine works faster and it is less of a memory hog. It is also older than NumPy, having been first written in the late 1990s.

A lot of those puzzles fall into a small number of categories:

• Fermi estimation - how many piano tuners in L.A?
• Church problem - gardeners who may have dirt on their forehead, pirates dividing coins - generally, recursive reasoning about other rational actors
• Discrete Measuring - dividing water or gold or whatever given inconveniently sized measuring devices.

Once you master the solution to one category, all the variations in that category are trivial.

"Freezing up" is precisely the problem; you can solve a lot of these puzzles by following your chain of logic to its end instead of abandoning it when it looks difficult or sketchy.

Whether these puzzles are good for hiring is another matter.

I asked to him to write a certain program on the laptop, using the language of his choice. He chose C++.

He looked up APIs on google and an in man pages.

I'm pretty happy with the program. It's correct, no slower than necessary, reasonably readable. A few minor improvements can be made, and he started to find these before we ran out of time.

Unfortunately he did badly with other interviewers in classic whiteboard situations, so I don't think he'll be hired.

This is the second time I've interviewed this way. I learned that a small task takes much longer to code than I think. Also, that this measures something quite different from whiteboard questions.

Preferred knives? Probably. But I've seen comments from chefs that they wouldn't take their good knives to work, where kitchen help would borrow or ruin them.

"He can do more with a candlestick than most men with a pistol. But he is pretty sure to have the pistol, too."

I run Ubuntu. With every upgrade, they break something and I have to spend time researching it.

Mostly this breakage is someone trying to "improve" things.
For example, pulse-audio. I suffered with it for a long while, then finally found how to rip it out by the roots.

I do not want unix to be like Windows.
I do not want my expectations broken on every release. Let it be. Make it stable.

This is compatible with progress. I want great new applications like Chrome. New apps and libraries don't disrupt the platform. I wish these guys would understand how much of other people's time they are wasting.

I rather think that it means you're looking at the data too late. Of course MSIE was the dominant browser when it didn't have any real competition, but that was after the competition had been killed off. Before that, there was healthy competition between Microsoft Internet Explorer and Netscape Navigator.

Although it is impossible to say for certain, many believe that MSIE came to have ~90% market share through a combination of being bundled with the operating system and having become good enough that it wasn't worth the trouble to get a different browser. Netscape went under and it would take years for Mozilla to produce something that people would actually prefer over MSIE, but all this time, there had been Opera, who have made a very impressive browser at least since their 3.x days. Why is it that they never managed to sway a large percentage of users? Could it be because Opera, other than Netscape and IE, was never included on ISPs installation disks, included with shareware magazine's distributions, or bundled with operating systems on large scale?

Recent history also tells some interesting stories. At some point, Microsoft apparently got worried enough about the competition on the browser front that they created an Internet Explorer team again. Yes, they had actually disbanded the IE team after the release of IE 6. So what did the competition have to do to get back in the game? Well, take a look at Firefox, Opera and Safari from around Firefox's 1.0 release, and you will find that they are light years ahead of MSIE 6 - which really isn't all that different from MSIE 5.5. Let's also not forget that Firefox had a stable base on *nix, and Safari on Mac OS X, so they would continue to be improved regardless of adoption by Windows users.

Does bundling a browser with the operating system (or ISP service) give that browser a huge advantage over the competition? I think it is clear that it does.

``maybe this should be taken as a sign that the problem NX solves needs a different solution. Like, oh I don't know... maybe revising the X windows protocol so it doesn't suck so hard it has its own event horizon?''

Yeah, maybe. Of course, this has been tried many times before, and not with much success, I believe.

The truth to the matter is that the X protocol is actually pretty good. It's the software that implements it that could be better. That at least used to be true of both servers and Xlib (range checks, anyone?), as well as clients. If you think X is slow, it is almost certainly because you are using a client that causes a lot of network round trips and waits for them. There is absolutely nothing in the X protocol that forces you to do so. But if you do so, then, yes, your app will be very slow over a moderate-latency link.

Indeed, usually, the slowness in X is caused by network latency (the exception being if you are rendering a lot of pixels, e.g. for movies). Moreover, the slowness is often not inherent in the X protocol, but rather caused by how an application uses it. Some X clients are amazingly fast, even over moderate latency links.

This is also why you often get a more responsive UI by using something that just pushes pixel data, like VNC, instead of X. They work faster, even though they are less efficient in terms of amount of network traffic. It's not the throughput, it's the latency.

You could actually do the same thing with X: just render your whole app to an XImage, then render that to the server. This will be faster than synchronously performing all your drawing operations over the network, if you do lots of drawing operations. On the other hand, if you have lots of images that you tend to reuse, store them on the server as XPixmaps, and then you can render them faster than you could by pushing the pixels each time. X offers you this choice, and when used well, can actually be _faster_ than other technologies over any kind of network. The only thing I haven't found is a way to compress pixel data, but perhaps that is just because I haven't looked hard enough.

Perhaps I don't remember it right, but in my recollection, NoMachine has always been a bit possessive with their (definitely impressive) technology. To the point that lesser alternatives have continued to be used and even developed.