rck

Using complex analysis to study generating functions that describe time complexity is definitely interesting, and there are some cases where using generating functions can make a complicated analysis a bit easier to deal with, but I don't see any reason to think that analytic combinatorics is more practical on a day-to-day basis than big-O notation. Analytic combinatorics is much closer in spirit to the techniques that Knuth uses to analyze performance in The Art of Computer Programming, and I don't know many programmers who prefer Knuth's style of analysis to big-O.

All of your complaints are spot on, but for your #5 you can hit alt-` to cycle through multiple windows of one app.

For my own part, I just decided to switch back to Slackware when my roommate wanted to play Sword & Sworcery and Ubuntu kept trying to sell her a katana. You can only tolerate so much...

You're right that a lot of the most useful AIs won't (or don't) need to think like humans, but one large class of AIs that will at least need that capability are the ones that have to interact with people in social settings. I'd be surprised if that didn't become common.

As for simulating emotion, there's a bit of evidence that such abilities may have therapeutic applications:

http://abcnews.go.com/Health/robots-children-autism/story?id...

One possibility that the article seems to ignore is that in the future, robots may be explicitly programmed to follow laws of war and rules of engagement. There's already been some research into this [1], and some people argue that autonomous robots could eventually be better than humans at following international law in combat. It does seem like a stretch given the present state of AI, but in the future there might be treaties that specify the algorithms that autonomous systems have to implement if they're going to be deployed to combat situations.

[1] http://www.cc.gatech.edu/ai/robot-lab/online-publications/fo...

You might try the 99 Prolog problems:

https://sites.google.com/site/prologsite/prolog-problems

The Scala version was fun and useful.

You're right that an event-driven style is useful for programming mobile robots, but a lot of the time the tricky part is actually generating events (usually from sensors) in the first place. I haven't seen anyone use libuv for this sort of infrastructure, but ROS (www.ros.org) provides everything you need for mobile (and other forms of) robotics: publish-subscribe message passing, client-server, wrappers for common robot platforms. I think it has essentially the functionality you're talking about.

I think part of the issue might be that HBase is designed for lots of data. The architecture overview says that if you only have a few thousand or million rows, then a relational database may be a better choice:

http://hbase.apache.org/book/architecture.html#arch.overview...

Even if you plan on scaling to billions of rows of data, it may be easier to start with something else that works well for smaller data sets.

If the two sides of the comparison have different types, JavaScript tries to coerce the values using rules that are pretty strange. The recommendation I've heard most often is to always prefer === and !==.

I believe that in this system, "deep neural network" just means a regular feed-forward network that has a larger number of hidden layers. There is a relationship to DBNs though, because they initialize the weights of the neural net by doing unsupervised pre-training with a set of DBNs.