 Okay. Hi. See, like I said, fails. All right. Hi. My name is Rudraksh. I gave this talk last year at this other JavaScript conference. Essentially, back in those days, I used to do a lot of scientific computing, doing some defense work with the army, doing a couple of other projects with other people. And this was basically about figuring out how you could use a language like JavaScript for something as, you know, compute heavy as scientific computing. And at the end, you know, what we realized was that it's not really such a bad idea after all. Sure, there are some caveats, there are some quirks, and there are some major problems, but at the end of the day, it does work out. So I'm just going to quickly run you through what we did. You know, when you say scientific computing, what really comes to mind? It's stuff like astrophysics, biostatistics, cheminformatics, and, you know, it just doesn't stop there. So you also have something that are more closer to us than we realize, like computational finance, the stock market. There are some great companies in the U.S. that actually use scientific computing to make better money off the stock market. And currently, languages that are used heavily in this regard are Python, or there's Julia as well that's upcoming. Some of you may have attended Shashi's talk yesterday. So that's coming up really well. Now, the thing is that, why JavaScript? I mean, what's wrong with Python and R? So theoretically, there's nothing really wrong with them. They're great languages, and people have been using them for a while. R's been around for at least 20 years now. Python for about six or seven. But the thing is from what I realize is that they don't have the same advantages that JavaScript does. And those are async, and that runs everywhere. So Python, for instance, does have asynchronous extension. There's tornado that allows asynchronous computing, but it's not something that Guido von Rossum really thought about when he was designing the language. And JavaScript, unlike other languages, runs everywhere. I mean, it runs in cameras, it runs on drones, it runs on the server, it runs inside a browser. Inside the browser, it runs in different contexts. It runs everywhere, unlike Python or R. So the thing is, it feels like JavaScript's the phone gap for scientific computing. Now, a lot of us hate phone gap. A lot of us really think that phone gap didn't work. But what a lot of us don't realize is that phone gap changed the way people thought about mobile development. I mean, you just know HTML and CSS and JavaScript. And now, lo and behold, suddenly you can write mobile apps. You don't need to learn Objective-C. If you don't know Java, that's cool. You just need to know JavaScript. In the same way, JavaScript has that thing going for it. It can change the way scientific computing is done today. It gives us a powerful experience across servers, across clients, across embedded hardware. So you can take a scientific model running on the server and just port it to a little Arduino chip with minimal effort. So there are enormous applications like calculating airline ticket costs on the client side. So, you know, today when we book airline tickets on our computers, we don't really realize the kind of competition that goes behind, you know, how much we have to pay. But there's a lot of different variables that are taken into account. Now, when you try and do this on your phone, how many of you have tried booking airline tickets on your phone? And how many of you would want to say that it's probably the most terrible experience ever? Anybody? So, how is it? See, there you are. Now, the reason for that is because, you know, airlines have to calculate fuel costs if you're taking a transatlantic flight. There's great circle routes to take into account. All of this has to be done on the server because, you know, there's math that goes into it. Imagine if you could do this on the client. It will change the way we book tickets today. It's a very small thing, but then, you know, when you try and take into account that almost all of us are using cell phones for just about everything, booking airline tickets and doing it much better on the smartphone is going to change things. Then, you know, running clustering or classification or regression algorithms. So, these are all part of machine learning. Now, imagine if you could run them on the server and then just pass the results to a client as D3 visualizations. You don't need to deal with the mess of parsing JSON objects through and through. You just throw it to the server and it gets to the client and it gets done. And the last one is kind of my favorite. You write neural networks in JavaScript to say, I don't know, recognize images maybe and then just load the entire model onto a paradrome and let the drone go berserk. How many of you here like cats? Anybody? No, good. Then I'm in safe hands because I trained a drone to recognize cats and scare them away using JavaScript and it's a lot of fun. So, you know, but then again, is JavaScript really suitable? So, I believe that there are two very basic guidelines that you can use to evaluate if a language works for you in a particular scenario. So, the first is, does this language provide the right constructs for me to model my problem and to visualize the output or understand the output? And does the language also have a decent ecosystem of external libraries and packages to help me get my job done? JavaScript kind of wins out on the first one. I mean, it straddles the two seemingly disparate worlds of object-oriented and functional programming. So, you get the best of both worlds. You get to model the real world in a very easy way, but you also get to treat everything as a mathematical function. The downside is the ecosystem. JavaScript was not really envisaged with scientific computing in mind. So, unlike Python, which has five different packages for machine learning, R has 73 different libraries for just one machine learning algorithm, the random forest algorithm. That's a lot. That's a whole kill. JavaScript has nothing. So, I don't really think I have time for some demos, but these are just some very basic libraries that are great to get started with. So, there's numbers.js, which is very basic differential and integral calculus and some basic linear algebra. Think of it as a SimPy. SimPy for Python. It's kind of the same. Then you have numerical JavaScript, which is way more advanced. It uses, it gives you a really good matrix multiplication method, and it also gives you mathematical optimization. Optimization is really important in a lot of different scenarios called for it. Apart from airline costs, say you're Amazon, and you know, this is a real world problem. Amazon Europe is a bit of a mess because they have different fulfillment centers across different countries. Say you're a British customer and you order something off the UK website, there's a chance that a French fulfillment center will fulfill it for you. Optimization is making sure that you get the right stuff, you know, which is localized for you and not for another country. So, if you're ordering from the French fulfillment center, it's a book. It's not going to be in French. It is going to be in English. Optimization plays a huge role in that aspect. Then there's clusterfuck, which is great for hierarchical clustering. So, if you have disparate data points and you want to figure out trends between them, this is a great library for that. And then there's Brain.js. Brain.js is probably the most extensive library for neural networks, even if you've taken things like Torch or Tiano for Python or Lua. Brain.js is pretty simple to use, and it's really easy to get started training very basic deep learning networks using Brain. The best part, all these libraries, they work with Node, they work inside the browser, and they work on embedded hardware that supports JavaScript execution. So, you can literally just take a model that's running on the server, drop it in onto that embedded client, and it works. It also works inside browsers very easily. Of course, the performance will be degraded a lot, but as time goes by and as NACL, Google's native client comes online, I'm pretty sure that's going to change. But again, that's not really enough. I mean, these are just four libraries, right? R had 73. So, what do you do when you don't have an ecosystem? You can either drop the whole idea of using JavaScript considering that if somebody loves JavaScript, I don't really think they're going to want to drop the idea. So, let's put that off the table. You can start writing libraries for JavaScript. Good luck. It's going to take 300 years. Or you can compile existing libraries to JavaScript. Now, like I said, dropping it isn't a great option and neither is writing libraries. But compiling existing libraries kind of makes sense. And that's where M-script 10 comes in. How many of you are familiar with Asim.js and M-script 10 and the whole concept of compiling C++ based code to JavaScript? Great. So, have you played with it? Have you tried it? Okay. So, M-script 10 to give you a bit of an introduction is essentially Mozilla's implementation of the Asim.js specification. It's a GCC compatible module. And it literally translates C++ into runnable JavaScript. And that's through the power of LLVM, the lower level virtual machine. So, your C++ module gets compiled into LLVM bit code, which is highly optimized. And that is then translated into runnable JavaScript. It's not readable. It's runnable. That's a major difference that you need to remember. Again, there was a demo that I did. So, I essentially compiled this library called Laypack. Laypack is used for linear algebra routines in C++. And it also forms the basis for libraries like skypie, certain machine learning libraries for Julia. So, the idea was to show that any existing ML library could easily be translated into JavaScript and then used in any context. So, the code is up. You can always play with it. The thing is, with M-script 10, a lot of different possibilities open up. Now, if you combine something like Python, which is Python written using C declarative types, and if you combine it with M-script 10, you can easily compile libraries like NumPy and skypie for JavaScript. It's not been tried yet, but it is in the works. Then you have MLPack. So, that's a really good machine learning library for C++, one of the best. And then you have Intel's math kernel libraries. A lot of game engines, for instance, what is that game engine called? There's this really popular game engine whose name I can't remember. They use MKL. MKL is this highly optimized assembly level routine designed by Intel. Imagine compiling that for M-script 10. Then you can basically know what you're doing is you're piggybacking off existing ecosystems to create a one around JavaScript that just works without a lot of effort. But the biggest challenge is that, remember what I said about readability. The problem with readability is that you then have no idea what's going on. It becomes a black box all over again. So, what one needs to do is explore M-script 10's optimization methods and use them to make models more readable, more faster. The good part is that since M-script 10 is based off of LVM, it's extensively documented. Then again, there is more. There's another library called Duetto which kind of does the same thing. It's even more advanced so it allows you to write JavaScript within C++ and just compile it for the client side. It's not needed unless you're writing really high-performance code. Then yeah, a lot of the rings, shameless pitch, one language to rule them all. Imagine how you could restify scientific models using Express. You've got an ML, maybe not even an ML. You've just got statistical methods running on the server and you can spin up quick HTTP routes around them and consume the results anywhere. You could use math on the client, render more powerful scenes using WebGL, or as Shyam talked about famous yesterday, you could have better scene rendering in famous. Then there's NaCl, Google's native client. Essentially, it allows you to run existing C-based libraries and code inside Google Chrome itself. So, have any of you heard of the IPython project? Yeah, IPython is basically a scientific-oriented distribution for Python and it comes with a really cool notebook interface. It's been ported to NaCl, so it runs inside the browser, inside the browser's own process space instead of on your computer. Then there's Cylon. Cylon's this really nifty JavaScript library which allows you to write, control different embedded hardware pieces using JavaScript. You can use it for Raspberry Pi, Google Bones, Paratrons and a lot more things. Again, let's say you're into home automation. You could have neural networks running on a server which basically decide when your air conditioner should be switched off or when your percolator should switch on for your morning cup of coffee. You can use Cylon to hook into that neural network and easily get your home automated in a Jiffy. There was this microcontroller that was doing the rounds last year called TESL. Similar stuff, you know, intelligent neural networks that can be shared across the server and across that microcontroller for multiple things. So yeah, you can find the GitHub, some of the code that I wrote for this on that GitHub link and you can hit me up here and thank you for being a captive audience. Any questions? Or was I that, you know, dirty? Is not? That's a great question. So let's see, let's think about it. Let's assume that instead of... So it's not about sharing the actual visualization. Let's assume that you're running a recommender system. Maybe you're running a Spotify-like service or as Shashi pointed out yesterday, movie recommendations. Now, maybe your app is written in Node. The usual use case would be where you end up writing your scientific models using a language like Python or R and then try and export the results to JavaScript. It'll work. It'll work like a charm but wouldn't it just be better to write the model in JavaScript itself as a part of your Node application? That is one option. The thing about JavaScript is that it's going to be asynchronous. At the end of the day, if you're writing a machine learning model in Python it's not going to be asynchronous and if your code is designed to be asynchronous maybe not in the beginning, you're not going to face a lot of issues. But as in when you start to scale, then it's going to come back and bite you. I think that's when it makes a lot of sense to try and port an existing library. And even if it's really simple, say if it's a simple clustering task, you don't even need to port anything. You can always use a library like clusterfab, which is anyway a JavaScript library. Sorry. You can, you can. Like I mentioned, so there's tornado, there are a bunch of other extensions that allow you to write code in Python. But at the end of the day, it's about the language itself. The language is not meant to be asynchronous. At that point in time, nobody even thought about asynchronousity as something that is going to be really important in the future. JavaScript, on the other hand, supports async from the ground up. Now, again, like I said, in the beginning, when you're just say, serving 10 requests a second, it may not really matter much. The problem comes when you scale and that is what we recognize in some of our work that when you write code in Python, it's good. In the beginning it's all good. Yes, but again, Erlang, same problem with the ecosystem. So at the end of the day, those two guidelines. It's not just about whether the language constructs are enough. It's also about the ecosystem. And we've tried Erlang. Porting all this to Erlang is a massive fail. More questions? Okay. Thank you.