3 ms·

> Suitable for scientific programming How's that possible? JS does not have a good reputation in sci prog, why would clio have?

• capableweb 6y ago
  Because Clio is not JS, it compiles to JS? There is plenty of ways of making JS handle any "scientific programming" you can throw at it. It'll probably run slower than what you can do by default in python-land or Julia, but since Clio seems to automatically parallize your code, it might have a chance.
  • cies 6y ago
    Sorry that's just an unfair claim. With this explanation every general purpose programming language handles "scientific programming".
    • capableweb 6y ago
      No, that's a weird conclusion if I ever saw one. What can be claimed though is that any general purpose programming language "can be made to" handle scientific programming. I'm not saying you should, but it's possible for sure. Libraries like big.js for example make arbitrary-precision decimal arithmetic possible on JS, which many considered impossible to do in JS.
  • mgerullis 6y ago
    V8 is quite a lot faster than python (in most comparisons, not all)
    • Garlef 6y ago
      isn't python fast because it uses specific c++ (or c?) modules in the background? for example keras is a wrapper for tensorflow (c++). numpy relies on c if i understand this correctly.
      • hctaw 6y ago
        I think it's more apt to say that Python isn't fast, but it has FFI that can be used to interface with things that are fast. The same is true of JS though, and most interpreted languages that have an escape hatch for FFI. The difficulty of getting it to work may vary.
    • cies 6y ago
      We're talking specifically about sci prog here. I think for one the ecosystem is just not there on JS.
  • hctaw 6y ago
    I'd be interested to see at what scale parallel evaluation in Clio beats serial evaluation that has been compiled to native machine code with basic compiler optimizations, for scientific computing (say, solving nonlinear differential equations). My guess is it's enormous, but I could be wrong since contemporary JS engines do quite well with numeric computing. But there's a wealth of scientific computing that can't be magically made to be parallel and the parallel equivalents are often slower due to duplicated arithmetic and overhead in setting up the computation (recursive computations are particularly bad about this) - finding a parallel evaluation strategy that is actually faster is nontrivial. It's really not a safe assumption that parallel = faster.
• vmchale 6y ago
  It sounds way too slow too.