3 ms·

In a nutshell: it combines the modern language features a CS person expects with the numerical excellence of Matlab. Is it a better language, from a pure CS pe

In a nutshell: it combines the modern language features a CS person expects with the numerical excellence of Matlab. Is it a better language, from a pure CS perspective, than Python/Scheme/pickyourfavorite? No, not really. If your job is writing web pages, Julia will be fine but it won't excel. But if your job is writing trajectory planning routines for robots or climate simulations or so on, you aren't coming from those languages. You are coming from Matlab. Matlab has great libraries -- every numerical method under the sun. It has a very shallow learning curve. It's good for prototyping. But the actual Matlab language, as opposed to the toolboxes, is absolutely painful for writing programs longer than a few pages. As a numerical methods guy with a CS background, it literally makes me want to tear my hair out. It feels like writing in BASIC, circa 1989. Julia can also have a shallow learning curve. If you want to prototype a couple of pages of numerical methods, it works nearly as well as Matlab does. But if you then need to expand that code into production, it can do that too.

vanderZwan 8y ago
> Is it a better language, from a pure CS perspective, than Python/Scheme/pickyourfavorite? No, not really. Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps? Because if anything I find Julia's type system a lot more interesting from a computer science point of view than Python or Scheme. If I want to get things done, I'd stick to Python for now though due to sheer momentum.
- GlenTheMachine 8y ago
  "Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps?" Yes, sure. Julia is an interesting language, CS-wise. My only point, inasmuch as I had one, was that there are other languages out there that have those same features. "If I want to get things done, I'd stick to Python for now though due to sheer momentum." I tried python, because you're right, it has the momentum and is the obvious first choice for numerical computing after you've had your fill of Matlab. Unfortunately, for a lot of the code I write, speed matters. In large part I'm prototyping my own numerical methods, not totally relying on numpy/scipy. The last time I tried python for numerical code development I ended up with a routine that was two orders of magnitude slower than it needed to be. I rewrote the entire thing in Julia, with little to no effort towards optimizing it, and it was immediately 50x faster than python and within a factor of two of what I needed. I put a couple of days of effort into optimization and I got it down to 2-3x faster than required. You could argue that I should have gotten better at optimizing python, and maybe you'd be right. I'm no python expert. But in my limited interaction with the python community, the answer to faster python seems to be, at the end of the day, to write the parts of the code you really need to be fast in C and call them with the python FFI. Which is what numpy does, if I understand correctly. Whereas I can write that same code directly in Julia and it's generally fast enough. For a lot of use cases speed doesn't really matter. But for robotics (my field) or self driving cars or machine vision or a lot of other embedded applications, it does matter.

vanderZwan 8y ago

> Is it a better language, from a pure CS perspective, than Python/Scheme/pickyourfavorite? No, not really. Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps? Because if anything I find Julia's type system a lot more interesting from a computer science point of view than Python or Scheme. If I want to get things done, I'd stick to Python for now though due to sheer momentum.

GlenTheMachine 8y ago
"Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps?" Yes, sure. Julia is an interesting language, CS-wise. My only point, inasmuch as I had one, was that there are other languages out there that have those same features. "If I want to get things done, I'd stick to Python for now though due to sheer momentum." I tried python, because you're right, it has the momentum and is the obvious first choice for numerical computing after you've had your fill of Matlab. Unfortunately, for a lot of the code I write, speed matters. In large part I'm prototyping my own numerical methods, not totally relying on numpy/scipy. The last time I tried python for numerical code development I ended up with a routine that was two orders of magnitude slower than it needed to be. I rewrote the entire thing in Julia, with little to no effort towards optimizing it, and it was immediately 50x faster than python and within a factor of two of what I needed. I put a couple of days of effort into optimization and I got it down to 2-3x faster than required. You could argue that I should have gotten better at optimizing python, and maybe you'd be right. I'm no python expert. But in my limited interaction with the python community, the answer to faster python seems to be, at the end of the day, to write the parts of the code you really need to be fast in C and call them with the python FFI. Which is what numpy does, if I understand correctly. Whereas I can write that same code directly in Julia and it's generally fast enough. For a lot of use cases speed doesn't really matter. But for robotics (my field) or self driving cars or machine vision or a lot of other embedded applications, it does matter.