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

Julia: A fresh approach to numerical computing

arxiv.org

Post reply on HN
Print view View original

71–80 of 146 posts

Re: Julia: A fresh approach to numerical computing

#71

Post by grayclhn »

4ad wrote: post #14
amelius wrote: post #8

Earlier quoted context omitted.

What I'd like to know when learning a new language is: why can't this be done in an existing language? Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.

Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions. Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this. Now, is there any other language with Lisp-like macros and static typing?

R is actually homoiconic. It's somewhat awkward and not a language feature that many packages exploit, but it's there. I wouldn't describe R as having Lisp-like macros, though... maybe "macro-like functions."

edit: and _definitely not_ static typing.

Re: Julia: A fresh approach to numerical computing

#72

Post by grayclhn »

one-more-minute wrote: post #15
RivieraKid wrote: post #11

Earlier quoted context omitted.

One of the few things I don't like is that it lacks a bit for object-oriented programming. Specifically: - It doesn't use the object.method() syntax, which is often more natural and readable than method(object). - Support for interfaces but I'm not 100% sure about that.

Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.

I've seen julia described as "functional" a lot, but is that accurate? There are first-class functions for sure, but the "idiomatic julia" approach to a lot of problems is to allocate a large block of memory, pass around a reference to it and mutate it in place. i.e. all side effects. My terminology might be off, but that's not usually what I think of when I think of functional programming.

Re: Julia: A fresh approach to numerical computing

#73

Post by grayclhn »

RivieraKid wrote: post #22
one-more-minute wrote: post #15

Earlier quoted context omitted.

Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.

I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.

That seems like a pretty decent description of python, right? :)

Re: Julia: A fresh approach to numerical computing

#77

Post by dagw »

Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations helped but I never got closer than 50% slower than Octave. In earlier test I've seen cases where Julia was literally 12 times slower than python/numexpr in real world code.

I really want to love Julia and everything I read about it makes me think it's the language for me, but every time I try to write non-toy code the performance is always worse than python.

Re: Julia: A fresh approach to numerical computing

#78

Post by jostmey »

dagw wrote: post #77

Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations…

I've observed a huge performance boost over python -- I wrote a simple artificial neural network trained using backpropagation in both languages and my Julia code ran orders of magnitude faster. Something is clearly screwed up with your implementation of Julia. There is no way octave should be running faster.

Re: Julia: A fresh approach to numerical computing

#79

Post by one-more-minute »

grayclhn wrote: post #72
one-more-minute wrote: post #15

Earlier quoted context omitted.

Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.

I've seen julia described as "functional" a lot, but is that accurate? There are first-class functions for sure, but the "idiomatic julia" approach to a lot of problems is to allocate a large block of memory, pass around a reference to it and mutate it in place. i.e. all side effects. My terminology might be off, but that's not usually what I think of when I think of functional programming.

I think there's a distinction between idiomatic code and code written for performance. Performance-conscious code looks a lot like C in most languages, not just Julia. Julia just happens to have a lot of that kind of code because it makes it easy to write.

But look at the high-level, user APIs and you tend to see the more functional side – `fft(x)`, `plot(y)` etc., all pure functions which return expressions. Mutation is possible but discouraged via the `!` modifier.

Functions are the primary unit of abstraction – larger programs tend to be designed as collections of functions as opposed to object hierarchies. Higher-order functions like map and filter (aka "functionals") are encouraged.

So I tend to view Julia as a nice functional language which lets me drop down easily when I need to.

Re: Julia: A fresh approach to numerical computing

#80

Post by grayclhn »

dagw wrote: post #77

Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations…

Did you read the performance tips?[1] The mailing list is pretty good at helping with problems like that. Using global variables is a pretty common performance killer.

[1] http://julia.readthedocs.org/en/latest/manual/performance-ti...

edit: As a direct reply to your question, yes, lots of people fail to find performance improvements when they first port code to Julia. But they often discover those improvements 10 minutes after someone with more Julia experience looks over their code :)

Post reply on HN