Live data from Hacker News

Julia, I Love You

r-bloggers.com

31–40 of 44 posts

Re: Julia, I Love You

#31
I find the example benchmark to be rather ridiculous. Recursion is slow in R because R is an interpreted language, and does not implement tail-call optimization.

If I wanted to implement the Fibonacci numbers in R I would do it like this:

xWhich takes about 1/10,000 the time of the recursive version (about .4 milliseconds on my machine).

So the conclusion I draw from the article is not that Julia is faster than R, but that you should know what your languages strengths are, and write code accordingly.

I'd love to see some examples of real statistical work were Julia's syntax is as easy as R, but the performance is superior.

Re: Julia, I Love You

#32
post #7
post #2

Edit: Title asks for downsides (but it seems like tue kind of title that might be changed) Disclaimer: I really like Julia, and loving it for some numerical stuff right now. That said... Potential downsides: - Very new, standard libs are still in flux - Matlab-like syntax, which I have mixed feelings on - Clustered parallelism uses ssh for transport, which I find slow (vs MPI) - 1-based array indices (for Matlab and…

Not to be pedantic, but Fortran 1-based array indices are from Fortran 66 and earlier. Fortran 77 and on include the ability to index from any arbitrary integer, including negative ones. You can declare a 21 element array indexed from -10 like so: real x(-10:10) So hopefully anyone familiar with Fortran isn't hung up on 1-based indices.

> "N̶o̶t̶ to be pedantic, [...]"

Re: Julia, I Love You

#33
post #3

I'm actually especially interested in taking the [web server]( https://github.com/chzyer/JuliaWebServer ) and building out a lean-and-mean MVC framework. Though it's designed as a scientific language, their goals of having C-like speed and yet Ruby-like beauty make it the perfect target for such a project. Anyone else interested in trying it out with me?

The idea of a dynamic Ruby-like language with C-like performance reminds me of Avi Bryant's talk "Bad Hackers Copy, Great Hackers Steal" : http://vimeo.com/4763707

He explains that dynamic languages are not inherently slow. It's their current implementation that's slow. Java is not fast thanks to static typing, it is fast thanks to the Hotspot VM, which builds upon the StrongTalk VM implementation.

Quote taken around the 13" mark (some trolling included ;) ): "Ruby has the dynamic part, and Java has the fast part. And this has led to this assumption that people have that the reason that Java is fast and Ruby is slow is because Java is static and Ruby is dynamic. And that's just not true, that's just a myth. Nothing about Java being fast has anything to do with it being static. It's simply that the papers that the Java people read were the ones that told you how to make it fast, and the papers that Matz read were the ones that told you how to make it usable."

Re: Julia, I Love You

#34
A lot of times, I really don't think there is a need for a whole new language. I use R and python for scientific computing all of the time. There are packages which have been well validated and a community of folks who support the software. Making a new language may be interesting, but if it doesn't really bring anything new to the table, it's just asking for a micro-niche user base (just think of the million and one web frameworks out there).

Julia looks interesting, but I don't see anything that makes me jump up and say, "I want to use that!" Everything I have seen so far can already be done with R, Python, or a combination of the two. If there are a few minor drawbacks to any process in R or Python, I would rather live with it than learn yet another language. Speed is not an issue -- if it is then I am likely coding incorrectly. If I have coded correctly, then it is worth taking the time to create a C library (and since everything else is in perspective, this is just "monkey coding" and never takes as long as we think).

I wish all of the folks who are bright enough to create their own language would voice their wants and needs to the existing coding communities to see if their needs can't be met rather than making something brand new. This kind of community interaction is crucial for a language to mature. Wouldn't you rather have a few very mature languages rather than a million young ones (each of which has its own pros and cons)?

Re: Julia, I Love You

#35

A lot of times, I really don't think there is a need for a whole new language. I use R and python for scientific computing all of the time. There are packages which have been well validated and a community of folks who support the software. Making a new language may be interesting, but if it doesn't really bring anything new to the table, it's just asking for a micro-niche user base (just think of the million and one…

Languages like matlab, R and Python (via numpy), let you do efficient computations as long as you can let them happen in the core, that is written in C and Fortran. This is very often possible, but in some cases you find that it is not, and then it will either be very slow or you need to write a C module for it. None of these languages is designed to make it easy to make a compiler/runtime that is from the ground up efficient. They are instead a rather inefficient interpreter with a really good library. This is where Julia differ. It is designed exactly to be efficient from the ground up.ground up.

Re: Julia, I Love You

#36
post #31

I find the example benchmark to be rather ridiculous. Recursion is slow in R because R is an interpreted language, and does not implement tail-call optimization. If I wanted to implement the Fibonacci numbers in R I would do it like this: x Which takes about 1/10,000 the time of the recursive version (about .4 milliseconds on my machine). So the conclusion I draw from the article is not that Julia is faster than R, b…

> Recursion is slow in R because R is an interpreted language, and does not implement tail-call optimization.

Javascript is interpreted and doesn't have it either, yet it's 145x faster.

Re: Julia, I Love You

#37
post #27
post #23

> " We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. " I've thought having it both ways was an insurmountable barrier, and one had to sacrifice the ease-of-use of familiarity to the power of homoiconicity. I guess a resolution is to cheat, and have both sets of constructs (redundantly). What's Julia's solution?

Disclaimer: I don't know anything about Julia, except from reading a couple simple programs just now, and seeing that it uses syntax that looks somewhat like Algol. I don't think there's any inherent contradiction between the two, depending on what you mean by "the power of homoiconicity" (1). Homoiconicity doesn't mean you need to use lists: you could make a language like C but with native structures to hold all of…

A DOM would give the benefits of homoiconicity, though the quote is We want a language that’s homoiconic. As an example, recent versions of Java include the compiler in Java, and therefore the classes for the AST (though undocumented). That's a DOM; you can use it to implement macros. (There's also ANTLR and BCEL to do AST twiddling - just consider them part of the standard classes of a Java variant).

But I think to be homo- (same) iconic (symbols), the language has to be those symbols. By this strict definition, it has to be a lisp. Maybe there's a looser definition possible, between a DOM and Lisp. I think a parallel lisp-syntax would do it (i.e. you can write everything using a lispy syntax; but there's also a friendlier syntax.

hmmmm, you could do this for any language, provided a AST representation (i.e. lispy) syntactically unambiguous with the rest. That subset of the language would then be homoiconic. e.g. add a first-class AST syntax to Java. Is that the kind of DOM you were thinking of?

Re: Julia, I Love You

#38
post #31

I find the example benchmark to be rather ridiculous. Recursion is slow in R because R is an interpreted language, and does not implement tail-call optimization. If I wanted to implement the Fibonacci numbers in R I would do it like this: x Which takes about 1/10,000 the time of the recursive version (about .4 milliseconds on my machine). So the conclusion I draw from the article is not that Julia is faster than R, b…

Agreed, one should know the strengths of your language, and avoid the pitfalls. Every language has its share of both. But the effort, I suppose, is to increase the surface area of the strengths.

So one of the claims of Julia is that you write code in the most natural manner, and depend on the compiler to make it fast. So, for example, the claim is that adding the optional type parameters do not necessarily make your code faster... type inference is good enough in most cases (there are obvious counterexamples, eg with global variables, but its true in the majority of cases). Also, unlike for eg. Matlab or R, vectorising your code does not necessarily produce performance gains, arrays are good enough. One of the side effects is that the standard library is implemented in the language itself, and thus extending built-in types is a breeze.

Therefore, I think its a very interesting effort in itself. Whether it is good enough to displace any other language is a completely separate issue. As said below, the base of useful libraries in languages such as R is phenomenal. But that should not, I think, preclude admiring a very interesting new language, for the possibilities that it hints at, if only as a highly engaging mental activity.

Personally, and subjectively, I think the combination of the above, and multiple dispatch, causes the language to have a highly pleasing sense of elegance.

Re: Julia, I Love You

#39
post #2

Edit: Title asks for downsides (but it seems like tue kind of title that might be changed) Disclaimer: I really like Julia, and loving it for some numerical stuff right now. That said... Potential downsides: - Very new, standard libs are still in flux - Matlab-like syntax, which I have mixed feelings on - Clustered parallelism uses ssh for transport, which I find slow (vs MPI) - 1-based array indices (for Matlab and…

1 based array indices are indeed a very opinionated decision. But I must say it isn't a very difficult thing to switch one's mental models around. Its very easy to get used to.

Re: Julia, I Love You

#40
post #3

I'm actually especially interested in taking the [web server]( https://github.com/chzyer/JuliaWebServer ) and building out a lean-and-mean MVC framework. Though it's designed as a scientific language, their goals of having C-like speed and yet Ruby-like beauty make it the perfect target for such a project. Anyone else interested in trying it out with me?

Count me as interested. And be warned, i have less than an hour of experience with julia though. please post the repo link once you flesh out the basics.
Post reply on HN