Marc Fasel

That's what I thought t first as well: Android has introduced voice actions in 2.2, which is what you are describing. That is in essence voice recognition plus text parsing. Nothing intelligent about than. What Siri is doing is voice recognition plus Artificial Intelligence. It is going beyond mere text parsing by processing the commands to a machine-useable form. In Android you might say "call Angela", while in Siri you say "call my wife". Siri is processing the "my wife" and uses information about what that means to find the name of your wife in the address book. It then replaces "my wife" with "Angela". Now it just continues to do what Android would do as well: text parsing. It parses the text to retrieve the command and the recipient, and calls a contact name Angela. Even though this is just a small step it makes the experience much more natural. If you just put in enough little gimmicks like that in the voice recognition just becomes easier and more fun. I think the is just the tip of the iceberg, though. Siri was part of the SRI CALO project - "computer assistant that learns and organises". So learning and organisation skills should be part of what Siri can do. Let's see how Siri will use those skills to help us. Maybe Siri will ask "who is you wife" once and learn this rather than look up this relationship in the contacts folder. And possibly add this info herself once she knows. I think there will be a lot more coming from Siri!

Awesome!

Funny writing, but I find it a bit off-target. The author basically says Node.js is not fast because if code is run that blocks the only thread the server cannot do anything else during that time. This is true but pointless. The argumentation of Node.js is that applications spend most of their time waiting for slow I/O operations to finish. Instead of having many threads waiting for slow I/O, Node.js doesn't block (wait) on I/O, so there will be less waiting. Point here is that Node.js uses non-blocking I/O. Everything else blocks, and the programmer needs to take that into consideration. Long-running code that does not wait for I/O will block. The Fibonacci example is such long running code, and therefore blocks execution. If you are calculating results for extended amounts of time you must move these off the main thread in Node.js. This is presented as some kind of eye-opener, but in reality it is a well-known fact. Also a bit pointless is it to run a benchmark of 5 concurrent users on a single-threaded server calling a function that lasts 5.676 sec. Whether you have 1, 5, or 50 concurrent users the result of the benchmark will always be the same: It is 1 request/5.676 sec = 0.17 req/sec. This number says nothing about the performance of Node.js, it just shows the code is blocking for 5.676 sec.