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

Why Julia

ucidatascienceinitiative.github.io

Post reply on HN
Print view View original

71–80 of 257 posts

Re: Why Julia

#71

Post by enriquto »

coldtea wrote: post #68
enriquto wrote: post #19

Earlier quoted context omitted.

> I think it requires a jvm mindset, warmup once and iterate inside rather than outside. I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful! For example, imagine I have a collection of a few hundred images with their projection matrices (in text files). I want to crop them and apply a simple imagemagick operation (which is not available from inside julia). The elementary…

> I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful! Yet you picked a specialized tool "imagemagick" (made for working with images), and want to drive it by another specialized tool (the shell, made for file and process management). Since you want "mindset oblivious" tools why not write everything from scratch, in C?

> Since you want "mindset oblivious" tools why not write everything from scratch, in C?

Because imagemagick, julia and other specialized programs already provide the advanced algorithms that I need. Unfortunately, julia is not a good team player.

Re: Why Julia

#72

Post by zzleeper »

altairiumblue wrote: post #2

As someone who has never run into performance problems with R, and also knows how to use Python - is there a good reason to learn Julia?

Last week I compared a standard regression command across several statistical programs (R, Py, Stata, Matlab, Julia, etc) on a stupidly simple 10x5 matrix, and Julia took ages to run (this is on windows). Even loading the CSV file took seconds in Julia, hundreds of times slower than all of the other packages put together.

I'm not sure if they just suck at Windows, but I was extremely dissapointed... :/

Re: Why Julia

#73

Post by dnautics »

agumonkey wrote: post #29
enriquto wrote: post #26

Earlier quoted context omitted.

Of course! Once I realize that after a few seconds only a dozen images have been processed I cut the loop, remember that the julia repl is dog slow, and then, rewrite the task in a different way. But I would prefer not to have to do that. Moreover, for more complicated examples, there may be data dependencies that make the loop commutation non trivial. The slow startup time may be a minor inconvenience, I agree. But…

Yeah I get it, it's inconvenient. But I taking the jvm thing again, I think julia's value is outside of this way of doing things. Out of curiosity I timed ocaml $ time echo 'let x = "1" in print_endline(x)' | ocaml -stdin - 1 real 0m0.045s user 0m0.039s sys 0m0.007s I thought julia init time was due to type checking phase but ocaml seems to have no issue, even with non zero code: $ time echo 'let l = [1;2;3;4] in let…

What were you planning to use Julia for where its init time matters?

Re: Why Julia

#74

Post by dnautics »

dnautics wrote: post #67
RivieraKid wrote: post #55

Earlier quoted context omitted.

Agreed, that's my experience as well. Julia is amazing for scripts and smaller projects, but I wish there was something like Swift (which I'm increasingly convinced is closest to the ultimate general-purpose language) with all the nice things that Julia has. Specifically, these things make Julia less suitable for larger projects: - Lack of support for OOP. And no, purely functional programming is not the best way to…

Sorry, why do you need OOP? I haven't coded OO in about 10 years now. (Mostly Julia, elixir, and functional JavaScript). It's great. Would never go back.

I even had to write python once, so I built a class where none of the functions were passed self (so it was basically a functional module)

Re: Why Julia

#75

Post by alexeldeib »

ModernMech wrote: post #53
4thaccount wrote: post #35

Earlier quoted context omitted.

I actually like 1-based for numerical work. A lot of great languages (Smalltalk, APL, Lua...etc) use it too. It makes sense with matrices.

This is something I don't fundamentally understand. As someone who works a lot with MATLAB I'm very used to and like 1-based indexing. But when I use C or Python, 0-based indexing is not something I complain about or hold against the language. It's just the way things are. Maybe if you don't think of it in terms of a different index basis and instead you think of it as indexing vs. offsets then it becomes easier to s…

I don't hold it against any language, but it certainly breaks with common convention. The number of simple off by one errors I had when I started writing Lua was a bit irritating.

Re: Why Julia

#76

Post by ninesigns »

I wish Julia would be more strict wrt type coercion of integer to float values.

I've once spent a day debugging the issue caused by the following line of code, where t1, t2 are floats and v is an array:

d = (t2 - t1) * length(v)

It should've been LinearAlgebra.norm():Float instead of length():Int. Had julia been stricter the code would have failed to run, saving me much time.

Re: Why Julia

#77

Post by ssivark »

forkandwait wrote: post #49
FabHK wrote: post #40

Earlier quoted context omitted.

Surprises me. Julia can usually stay much closer to mathematical notation than, say, Python or C++. You can even use nice Unicode notation such as A ⊗ B ⊗ C. So, `kron` is actually provided by the standard library [1], are you saying that this kronecker product didn't do the job? [1] search in this file: https://github.com/JuliaLang/julia/blob/master/stdlib/Linear...

It was 5 years ago, maybe it's better now. I wasn't comparing Julia to python or c+, but to Matlab octave.

Thanks for that clarification. 5 years is a lot of evolution for a language that was roughly 2 years old when you used it! Might warrant a revaluation, or at least always state the timeline along with your opinions :-)

Re: Why Julia

#78

Post by improbable22 »

masklinn wrote: post #64
improbable22 wrote: post #59

Earlier quoted context omitted.

> `using` is shorter than `import` By one letter! And in the right direction: for trying things out interactively, `using ThePackage` and then having everything available is great. Then once you know what you want to do, in more careful code you can switch to `import` and qualify more things, and your future self with thank you. But serving both of these needs seems like a valid design goal. I'm not sure the manual d…

> By one letter! Yes, by one letter. Out of 6. "using" is 16% shorter than "import". And it uses better keyboard alternation (the first 4 letters of `import` are on the right side of a qwerty keyboard, the last 2 on the other, for using the only "i" and "n" are consecutive letters on the same half of the keyboard). So "using" is 1. introduced first 2. the primarily documented import mechanism 3. significantly shorter…

But you have to type `python3` which is 7 letters to 5, if we're counting :)

Seriously though, it's hard to write one manual which gives everyone the perfect on-ramp for their needs. I actually think it's fair to aim it low, make it easy for matlab refugees to get started, interactively. People who know how namespacing works in several other languages (and intend to write big projects) are the ones well-equipped to know how to dig deeper. Nobody has been victimised!

Re: Why Julia

#79

Post by disgruntledphd2 »

Cosi1125 wrote: post #50
e12e wrote: post #31

Earlier quoted context omitted.

Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programming language) - with the benefit of speed - and no/hardly any need to drop to/link to C libraries - "everything" is in Julia, and you can inspect the code "all the way down" (well, to a point - there's of course llvm at the bottom). Whether Julia is that for you…

> and python (a sane, real programming language) So... R is an unreal language then?

Nah, it's just a re-implementation of S, which was really, really old and different from what people expect.

R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming.

Because of the re-implementation of S, it has lots of odd quirks and multiple ways to do things, which Python tends to avoid. Python is definitely more consistent from a programming point of view, but R is a more cohesive system from an analytics point of view.

But yeah, lots of people are hateRs (unfortunately).

Re: Why Julia

#80

Post by shele »

altairiumblue wrote: post #4
shele wrote: post #3

Earlier quoted context omitted.

Think about it a moment, which answer would you prefer?

Regardless of the answer, I have plans to learn it simply out of curiosity. I'm just not yet convinced that there are any practical benefits to using Julia over the other languages.

Great, the answer is then: You should give it a try, to a certain extend "Why Julia is nice" is easier experienced than explained.
Post reply on HN