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

81–90 of 257 posts

Re: Why Julia

#81

Post by banku_brougham »

RivieraKid wrote: post #55
Datenstrom wrote: post #8

I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…

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…

honest question, not a serious SDE here. In what ways is julia not supportive of OOP?

Re: Why Julia

#82

Post by vharuck »

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?

I use R daily at work, and often reach for it before Python for non-statistical tasks out of comfort.

But R's functions for non-statistical tasks often break the language's idioms. Those dealing with files and connections are especially ugly.

I wouldn't call it insane or unreal, but it's definitely not intended for general scripting.

Re: Why Julia

#83

Post by IshKebab »

agumonkey wrote: post #14
enriquto wrote: post #6

> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).

I didn't find it slow, but: $ time julia -e 'print(1)' 1 real 0m0.438s user 0m0.300s sys 0m0.118s $ time python -c 'print(1)' 1 real 0m0.040s user 0m0.036s sys 0m0.003s it is slower.. That said, instanciating julia every step of a bash loop.. I think it requires a jvm mindset, warmup once and iterate inside rather than outside.

First of all that is ridiculously slow. Secondly, unlike Matlab you don't have everything you need available after starting the REPL. For instance if you want to plot something you might run `using Gadfly`. How long does that take?

16 seconds. Sixteen seconds. For real. This is not usable.

Re: Why Julia

#84

Post by [deleted] »

agumonkey wrote: post #14
enriquto wrote: post #6

> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).

I didn't find it slow, but: $ time julia -e 'print(1)' 1 real 0m0.438s user 0m0.300s sys 0m0.118s $ time python -c 'print(1)' 1 real 0m0.040s user 0m0.036s sys 0m0.003s it is slower.. That said, instanciating julia every step of a bash loop.. I think it requires a jvm mindset, warmup once and iterate inside rather than outside.

[deleted]

Re: Why Julia

#85

Post by repsilat »

4thaccount wrote: post #35
Datenstrom wrote: post #8

I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…

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.

For "2D indexing" into a 1D array it's actually a little awkward. With an n×m matrix,

- zero-indexed: i×m+j

- one-indexed: (i-1)×m+j

OTOH one-based is slightly better for trees stored in 1D arrays:

- zero-indexed: parent=(child-1)/2; children=2×parent+(1, 2).

- one-indexed: parent=child/2; children=2×parent+(0, 1).

My favourite fact about this stuff: in VB (or was it VBA?) when you asked for an array of size n, you actually got an array of size n+1. So people could do 0-based or 1-based indexing and be none the wiser...

Re: Why Julia

#86

Post by marmaduke »

enriquto wrote: post #6

> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).

Agreed Octave works excellently as a linear algebra/numerical subshell for Shell scripting, better than Python IMO.

Re: Why Julia

#87

Post by agumonkey »

dnautics wrote: post #73
agumonkey wrote: post #29

Earlier quoted context omitted.

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?

Nothing, i'm just curious [1] about Julia. I never used it.

[1]It's just because i find the science python stack a bit absurd.

Re: Why Julia

#88

Post by marmaduke »

I want to like Julia but after a decade of Python, every time I try it, it’s a death by a thousand cuts (and outdated Google results). I just can’t afford to have productivity drop to near zero for the learning curve plus reimplement everything.

Also I ha e found multiple dispatch to be harder than regular OO methods to locate (for IDEs but grep also).

Re: Why Julia

#89

Post by AllegedAlec »

RivieraKid wrote: post #55
Datenstrom wrote: post #8

I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…

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…

> Lack of support for OOP.

Please. No. Languages that try to do everything are crap. If you want to do something OOP, why don't you grab a language built for it?

Re: Why Julia

#90

Post by Cosi1125 »

disgruntledphd2 wrote: post #79
Cosi1125 wrote: post #50

Earlier quoted context omitted.

> 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 o…

Wise words here.

In my humble opinion, applying S's syntactic sugar on top of Scheme-forged core did more bad than good to R. Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible.

As for the two approaches to solving problems (TIMTOWTDI vs Python's "one true way") I think that's a matter of personal preference; I, personally, appreciate the freedom that R gives me. Also, it might be anectodal, but I believe that - to some extent - it promotes thinking "outside the box", especially when you work in a team and review others' code on a daily basis.

Post reply on HN