Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript for Data Science

js4ds.org

Post reply on HN
Print view View original

31–40 of 83 posts

Re: JavaScript for Data Science

#31

Post by tyingq »

11235813213455 wrote: post #7
danpalmer wrote: post #3

I don’t want to repeat the old and tired JavaScript hate, but this just isn’t a great idea. I’d suggest that there are 3 important primitives for data science: flexible numeric types, fast math/algorithm libraries, and data manipulation being easy. JavaScript doesn’t really have any of these. Numbers are 64bit floats only - no integers, no big numbers. There aren’t equivalents to Numpy/Pandas/Scikit Learn, and the la…

I don't see JS as less powerful than Python for data science, it's faster than Python, or can use bindings just like Python. JS is maybe less commonly used than Python in data science nowadays, but I wouldn't be surprised if this changes in next years. There are equivalent libs like tensorflow-core, there are native features like BigInt, and there are libs for 64bits floats (decimal.js, big.js). I'd be glad to spend…

>it's faster than Python

Is that generally true for data science type tasks, though, where the "fast" in python is really numpy, pandas, etc?

>or can use bindings just like Python

But there's not really anything like numpy/pandas for it to bind to at the moment, is there? Meaning anything as broad in functionality, fast, mature, etc.

Re: JavaScript for Data Science

#32

Post by genrez »

I am a noob to Javascript, so if someone knows better, than please correct me about this, but arrow functions aren't meant to replace normal function syntax, right? From [1], it seems like the main point of arrow syntax is to allow you to inherit the "this" parameter if you are inside a method. Meanwhile, you need normal function syntax if you are creating a constructor, making a method function for a prototype, or making generator functions. (I didn't even know javascript had generator functions until just now :))

So it seems a bit weird to me that they advocate using arrow function syntax instead of the regular syntax. They seem to be advocating using the new class syntax instead, so I guess they don't need the constructor or method creation features of the normal syntax, but I still don't see why they would specifically advocate for arrow function syntax. Is it faster? They say it interferes with other features, but which features?

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: JavaScript for Data Science

#33

Post by __jem »

genrez wrote: post #32

I am a noob to Javascript, so if someone knows better, than please correct me about this, but arrow functions aren't meant to replace normal function syntax, right? From [1], it seems like the main point of arrow syntax is to allow you to inherit the "this" parameter if you are inside a method. Meanwhile, you need normal function syntax if you are creating a constructor, making a method function for a prototype, or m…

Not changing `this` is a huge benefit that shouldn't be ignored. Especially when you're programming in a more functional style, it makes sense to default to arrow functions because you never want to engage in `this` shenanigans anyway. So, yes, I'd say it's a pretty common idiom in the JS community to replace "normal" function declarations.

Re: JavaScript for Data Science

#34

Post by __jem »

uryga wrote: post #24
11235813213455 wrote: post #7

Earlier quoted context omitted.

I don't see JS as less powerful than Python for data science, it's faster than Python, or can use bindings just like Python. JS is maybe less commonly used than Python in data science nowadays, but I wouldn't be surprised if this changes in next years. There are equivalent libs like tensorflow-core, there are native features like BigInt, and there are libs for 64bits floats (decimal.js, big.js). I'd be glad to spend…

> libs for 64bits floats (decimal.js, big.js) both of those libraries are for arbitrary precision decimals, not floats.

If it's arbitrary precision, what's the difference, besides slightly more bookkeeping on your end?

Re: JavaScript for Data Science

#35

Post by heresie-dabord »

danpalmer wrote: post #3

I don’t want to repeat the old and tired JavaScript hate, but this just isn’t a great idea. I’d suggest that there are 3 important primitives for data science: flexible numeric types, fast math/algorithm libraries, and data manipulation being easy. JavaScript doesn’t really have any of these. Numbers are 64bit floats only - no integers, no big numbers. There aren’t equivalents to Numpy/Pandas/Scikit Learn, and the la…

> repeat the old and tired JavaScript hate, but this just isn’t a great idea.

There is absolutely nothing wrong with coders/analysts/scientists building solutions in any language. The "hate" that you mention -- and then proceed to echo -- is a narrow way of asserting the superiority of $mylanguage and the inferiority of $yourlanguage.

> flexible numeric types, fast math/algorithm libraries, and data manipulation

Your point b) is usually written in a performant, compiled language, and your point c) can be built from robust primitives in any language. However, I will add a point d) about speed and memory usage.

I do data analysis with the simplest set of performant tools: sqlite, bash-awk-sed-grep, Perl, Python, C++, SVG, and a browser to render. Any kind of glorified REPL beyond a terminal creates fragile complexity and dependency Hell.

My kit doesn't include Node.js or ECMAscript but I'm willing to open my mind enough to think it might, one day. The current tooling for data analysis (or "data science" if we want to be faddish) is a mess and I look forward to better tools in the future.

Re: JavaScript for Data Science

#36

Post by mLuby »

genrez wrote: post #32

I am a noob to Javascript, so if someone knows better, than please correct me about this, but arrow functions aren't meant to replace normal function syntax, right? From [1], it seems like the main point of arrow syntax is to allow you to inherit the "this" parameter if you are inside a method. Meanwhile, you need normal function syntax if you are creating a constructor, making a method function for a prototype, or m…

I've seen a majority of sources abandon the function keyword entirely in favor of const arrow declarations (and shorthand method syntax).

FWIW I personally like the function keyword, since it's clear what it is to non-JS readers, but primarily because it hoists to the top of its file, so unimportant utility functions can sit unobtrusively at the end of the file, thereby letting readers encounter more important logic earlier in the file.

Re: JavaScript for Data Science

#38

Post by jhbadger »

beforeolives wrote: post #2

I know that data science is a broad and somewhat vague term but this - We will cover: Core features of modern JavaScript Programming with callbacks and promises Creating objects and classes Writing HTML and CSS Creating interactive pages with React Building data services Testing Data visualization Combining everything to create a three-tier web application - this isn't data science.

The book does cover a lot of basic Javascript material, as its target is actual natural scientists who may not have much experience with the language, but towards the end it does cover things like Data-Forge (which is a data science library in Javascript)

Re: JavaScript for Data Science

#39

Post by genrez »

__jem wrote: post #33
genrez wrote: post #32

I am a noob to Javascript, so if someone knows better, than please correct me about this, but arrow functions aren't meant to replace normal function syntax, right? From [1], it seems like the main point of arrow syntax is to allow you to inherit the "this" parameter if you are inside a method. Meanwhile, you need normal function syntax if you are creating a constructor, making a method function for a prototype, or m…

Not changing `this` is a huge benefit that shouldn't be ignored. Especially when you're programming in a more functional style, it makes sense to default to arrow functions because you never want to engage in `this` shenanigans anyway. So, yes, I'd say it's a pretty common idiom in the JS community to replace "normal" function declarations.

I agree that inheriting the `this` for arrow functions is beneficial. To me it seems like you would want to use the normal syntax for global functions for hoisting and to prevent unintentional re-definitions, the arrow functions where you would use lambda functions in other languages, and the class method syntax for methods.

side-note: Most of my JS experience is writing userscripts for myself, so I definitely do my share of 'this' shenanigans.

Re: JavaScript for Data Science

#40

Post by mark_l_watson »

I thought of writing a Javascript + tensor flow.js + NLP + web scraping + linked data + etc. book about a year ago. tensorflow.js is especially very cool: well documented with great examples. In fact, it was the great tensor flow.js examples and demos that convinced me to not write the book because I didn't feel like I could do much value add on that subject.
Post reply on HN