Live data from Hacker News

Try Julia

forio.com

61–70 of 105 posts

Re: Try Julia

#61
post #59

A lot of the comments I see about Julia (and other trendy high level languages) are of the following form: "I can do things I needed C to do before, and almost as fast" which leads me personally to ask, If you could do this in C before, and faster, then why are you switching? Most people will say "because C is bad/difficult/clumsy for doing X" which leads me to say, why are you using C to do X? I sincerely believe (a…

You can see it as an alternative to Matlab/R (sorta)/numpy not C.

People only ever used C when speed was crucial and depending on what you were comfortable in or what you had learned maybe Fortran for speed instead of C.

Julia is meant for scientific computing with some nice features. As I see it it is similar enought to Matlab to be easily learned by those who use Matlab but has enough goodies that it can be a viable alternative.

Programming isn't about being specific it is about accomplishing a task and many times yes you don't want to have to worry about the details as long as it works the way it should.

Re: Try Julia

#62
post #58

Earlier quoted context omitted.

Removing loops or mutability from Julia would be a terrible decision. There's nothing inherently wrong with mutability or imperative programming.

I just was answering the case for the advantage of Clojure over Julia as a general purpose language. And pervasive immutability is an advantage in that case. I agree Julia needs mutable arrays, I think for the domain it is targeting mutable arrays are a must but that should not mean that it needs big old imperative loops absolutely everywhere either.

Imperative and mutable isn't inherently wrong, even in a general purpose language like Julia.

In Clojure it's hard to write imperative code, which was one of the reasons I've left. Sometimes, imperative programming is the best way to code something. Sometimes it's best to do it in a functional way. Julia can do both.

The same is true for mutability. I understand the advantages of immutability but I think it's overhyped. Besides the obvious advantage of mutability - performance - it sometimes makes for more readable and shorter code. And what if you have some complex nested state and need to change a small part of it?

BTW - what do you mean by functional programming exactly, how does it differ from imperative programming in your view?

Re: Try Julia

#63
post #59

A lot of the comments I see about Julia (and other trendy high level languages) are of the following form: "I can do things I needed C to do before, and almost as fast" which leads me personally to ask, If you could do this in C before, and faster, then why are you switching? Most people will say "because C is bad/difficult/clumsy for doing X" which leads me to say, why are you using C to do X? I sincerely believe (a…

You can see it as an alternative to Matlab/R (sorta)/numpy not C. People only ever used C when speed was crucial and depending on what you were comfortable in or what you had learned maybe Fortran for speed instead of C. Julia is meant for scientific computing with some nice features. As I see it it is similar enought to Matlab to be easily learned by those who use Matlab but has enough goodies that it can be a viabl…

I agree with what you say. More and more though as I get on in my career as a scientist I realize though that the details turn out to matter, sometimes a great deal.

Anyway I'm all in favour of an open, fast MATLAB alternative

Re: Try Julia

#64
post #59

A lot of the comments I see about Julia (and other trendy high level languages) are of the following form: "I can do things I needed C to do before, and almost as fast" which leads me personally to ask, If you could do this in C before, and faster, then why are you switching? Most people will say "because C is bad/difficult/clumsy for doing X" which leads me to say, why are you using C to do X? I sincerely believe (a…

> I sincerely believe (as a computational scientist) that a combination of a high-level language for real-time interactive exploration and prototyping with a fast language like C for doing the actual gruntwork, is the best.

Converting to C can take a LOT of time, and is an order of magnitude less enjoyable than Julia. What about maintaining the code, making improvements, integrating with other code? And what if the prototyping needs too be fast too? It can become a massive pain in the ass. Why should I undergo that if I can just use Julia?

> Attempts to combine the best of C (speed) with the best of scripting languages (easy to do things fast without having to pay attention to what you are doing) in my opinion end up merely joining the worst of both worlds rather than the best of both worlds.

I've used both Julia and C and I think it's the exact opposite, it combines the best of both worlds.

Re: Try Julia

#66
post #57

Julia appears to be a perfect fit for much of what I do at work. I tried it, got very excited, and then facepalmed earlier today. Let's define two functions in the REPL: function foo() return 42 end function bar() return foo() end Evaluating bar() gives 42, just as one would expect. Now let's redefine foo(): function foo() return 69 end Evaluating bar() still gives 42! Not getting something so basic correct tells me…

That annoys me too but it isn't a big deal, it'll probably get fixed in the future.

You change a function, and that change doesn't get reflected in upstream calls—this isn't a big deal? Are you kidding me?

Re: Try Julia

#67
post #66

Earlier quoted context omitted.

That annoys me too but it isn't a big deal, it'll probably get fixed in the future.

You change a function, and that change doesn't get reflected in upstream calls—this isn't a big deal? Are you kidding me?

I don't see it as a big deal. You do, so my advice is to wait for 1.0.

Re: Try Julia

#68
post #39

Earlier quoted context omitted.

round(x) only works for a few specialised types of x. help(round) tells you that it will return the same type then. Of course for a type of MathConst{:π}, that won’t work. For generic types, you need to at least specify the number of digits (round(pi, 3)). (See also: methods(round))

Weird that they have round(pi) as an example.

It may have worked at some point. The language evolves pretty quickly at the moment.

Re: Try Julia

#69
post #42

Earlier quoted context omitted.

+1 Besides libs and ecosystem in general, I don't see any advantage Python / Ruby / Clojure have over Julia.

Eh, in the case of Closure pervasive immutability, I don't want to write imperative code anymore. I am sure you could write in a functional style in Julia but all the code I have seen seems to rely pretty heavily on explicit stateful loops. At that seems to be a design choice not just for speed but, from what I have read elsewhere, to be familiar to Fortran and Matlab people, seems like a bad trade off to me.

I also really like Clojure (we use it exclusively at work) especially thanks to its referential transparency. But I don't think I'll ever want to exclusively write in a Clojure style. Sometimes I prefer imperative stateful algorithms.

Re: Try Julia

#70
post #66

Earlier quoted context omitted.

That annoys me too but it isn't a big deal, it'll probably get fixed in the future.

You change a function, and that change doesn't get reflected in upstream calls—this isn't a big deal? Are you kidding me?

I think everyone involved with Julia agrees that this is something that eventually needs to work, although it is not as big of a deal if you are loading code from disk, as opposed to writing functions at the REPL. See https://github.com/JuliaLang/julia/issues/265.
Post reply on HN