5 ms·

I still view JS as a UI-oriented language, and I really don't know why would you want to implement processor-heavy algorithms in a browser environment, which ne

I still view JS as a UI-oriented language, and I really don't know why would you want to implement processor-heavy algorithms in a browser environment, which need a lot of data and don't use the networking. I would still stick to python. Or java. Or anything else which has a clear syntax and can run at a useful speed (I'm not mentioning C++ because of the coding overhead and dirty tricks which makes it a bit unfriendly for learning an algorithm)

xd 13y ago
"Through this series of articles, I’ll teach you the fundamental machine learning algorithms using Javascript"
dangoor 13y ago
Clarity of syntax is a matter of opinion (personally, I agree that Python is clearer than JS... Java, not so much.) Implying that JavaScript can't "run at a useful speed" is wrong, using modern implementations. This is especially true for code that runs through lots of repetition as the just-in-time compilers in the JS engines do a remarkable job. Not to mention that viewing JS as a UI-oriented language seems a bit out of date given the 40k or so packages for Node.js that are in npm. JavaScript of today is pretty different than JS of 2007, and there are more changes coming with generators, iterators, destructuring, class syntax, arrow functions, promises, etc.
- Joe8Bit 13y ago
  While I disagree with the comment you're responding to, and agree with yours, there are some interesting problems doing resource heavy operations in ML/NLP in an environment like Node that's inherently single threaded. I'm actually adding multi-threading to classifier training in node-natural as we speak [0] so it's something I'm recently familiar with. Multi-threading in JS isn't new or particularly exciting (even less so is multithreading in ML/NLP applications) but the marriage of the two has led to a few interesting problems in JS's asynchronous/event based view of the world! [0]: https://github.com/NaturalNode/natural/issues/124 https://github.com/NaturalNode/natural/issues/124 -- Edited for clarity
  - dangoor 13y ago
    That's a good point. Of course, the problems with shared mutable state are well-documented and I'm glad that JavaScript hasn't headed down that path. But you're right that Node doesn't have good, mature solutions for that yet (short of your central data store option)

xd 13y ago

"Through this series of articles, I’ll teach you the fundamental machine learning algorithms using Javascript"

dangoor 13y ago

Clarity of syntax is a matter of opinion (personally, I agree that Python is clearer than JS... Java, not so much.) Implying that JavaScript can't "run at a useful speed" is wrong, using modern implementations. This is especially true for code that runs through lots of repetition as the just-in-time compilers in the JS engines do a remarkable job. Not to mention that viewing JS as a UI-oriented language seems a bit out of date given the 40k or so packages for Node.js that are in npm. JavaScript of today is pretty different than JS of 2007, and there are more changes coming with generators, iterators, destructuring, class syntax, arrow functions, promises, etc.

Joe8Bit 13y ago
While I disagree with the comment you're responding to, and agree with yours, there are some interesting problems doing resource heavy operations in ML/NLP in an environment like Node that's inherently single threaded. I'm actually adding multi-threading to classifier training in node-natural as we speak [0] so it's something I'm recently familiar with. Multi-threading in JS isn't new or particularly exciting (even less so is multithreading in ML/NLP applications) but the marriage of the two has led to a few interesting problems in JS's asynchronous/event based view of the world! [0]: https://github.com/NaturalNode/natural/issues/124 https://github.com/NaturalNode/natural/issues/124 -- Edited for clarity
- dangoor 13y ago
  That's a good point. Of course, the problems with shared mutable state are well-documented and I'm glad that JavaScript hasn't headed down that path. But you're right that Node doesn't have good, mature solutions for that yet (short of your central data store option)