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

Some Insights from a Julia Developer

stochasticlifestyle.com

Post reply on HN
Print view View original

31–40 of 241 posts

Re: Some Insights from a Julia Developer

#31

Post by kgwgk »

freyir wrote: post #20
j7ake wrote: post #3

Everything sounds great about Julia but it's lacking sufficient critical mass to develop useful packages to make scientists and data analysts effective. At the moment the bottleneck in our scientific computing and data analysis workflow is not waiting for code to run but rather quickly inplementing, evaluating, and iterating different models on datasets.

When I last looked at Julia, the language wasn't yet stable. It's not fun developing packages for a language that changes from release to release, so I don't expect their ecosystem to stand a chance until they get to v1.0. All the advantages for package developers listed in this article are moot while the language remains a moving target. It was said that v1.0 was due in early/mid 2017, but it looks like it's still a…

I was going to add that Python has been "getting there" since 1995, but I see you have already edited you comment :-)

Re: Some Insights from a Julia Developer

#32

Post by mkborregaard »

j7ake wrote: post #3

Everything sounds great about Julia but it's lacking sufficient critical mass to develop useful packages to make scientists and data analysts effective. At the moment the bottleneck in our scientific computing and data analysis workflow is not waiting for code to run but rather quickly inplementing, evaluating, and iterating different models on datasets.

What makes you say it lacks critical mass? I don't think that's accurate, but of course it takes time. Implementation time is important, yes - but julia is not just a fast-to-run-language, which is essentially the point - it is a fast-to-implement language.

Re: Some Insights from a Julia Developer

#33

Post by jernfrost »

88e282102ae2e5b wrote: post #17

It's great and all, but I can't justify switching languages for minor improvements over Python + numpy/scipy. I'd be abandoning: * My deep knowledge and experience with Python * My entire codebase * The ability to work on projects with colleagues who don't also switch * The certainty that when I leave my current job, someone will be able to pick up after me * Zero-based indexing I've started to do some work in Rust w…

The improvements are not minor they are massive. Citing rust shows that the advantage of Julia has not been explained well enough. Julia allows you to write as performant code as Rust with a much smaller investment in learning. You cite your concern for spending time learning something new. That makes no sense considering the high learning curve and complexity of Rust compared to Julia. Julia is quite fast to learn and has far more overlap with Python than Rust to make the transition easy. You can call python code from Julia and ise many of the same tools like the notebook.

Re: Some Insights from a Julia Developer

#34

Post by jernfrost »

mhd wrote: post #16

Is there a good use case for Julia outside the "math" community, when your alternatives wouldn't be R or Numpy, but Ruby or C#?

I use Julia for shell scripting. Remember how many ende up using ruby for this? Well Julia works even better. I don’t write big programs in Julia. It is just a kind of everyday tool. I am a C++/Swift/Objective-C developer professionally.

Re: Some Insights from a Julia Developer

#35

Post by fasquoika »

mhd wrote: post #16

Is there a good use case for Julia outside the "math" community, when your alternatives wouldn't be R or Numpy, but Ruby or C#?

For the most part, no. The language and community are significantly math oriented. However, if you're someone who likes to learn languages just to broaden their horizons a little bit, Julia might be a good choice. It's one of the few languages in common use which has multimethods (the other major one being Common Lisp). Actually, in general Julia is surprisingly Lispy for a language with Algol-family syntax.

Re: Some Insights from a Julia Developer

#36

Post by j7ake »

mkborregaard wrote: post #32
j7ake wrote: post #3

Everything sounds great about Julia but it's lacking sufficient critical mass to develop useful packages to make scientists and data analysts effective. At the moment the bottleneck in our scientific computing and data analysis workflow is not waiting for code to run but rather quickly inplementing, evaluating, and iterating different models on datasets.

What makes you say it lacks critical mass? I don't think that's accurate, but of course it takes time. Implementation time is important, yes - but julia is not just a fast-to-run-language, which is essentially the point - it is a fast-to-implement language.

At least in the field of computational biology most people use R or python because of the wealth of statistical packages and biology-specific packages (biomaRt) that makes implementing and testing models on biological data much faster than in Julia.

It's always this problem, if everybody is using R, it is hard to migrate to Julia. But in order to migrate to Julia you need people to stop using R and switch to Julia.

Re: Some Insights from a Julia Developer

#37

Post by jampekka »

improbable22 wrote: post #19
jampekka wrote: post #6

Too bad they somehow thought it was a good idea to make the syntax resemble MATLAB of all languages. Perhaps most of the nausea inducing warts could be worked around with some kind of transcompilation, although some semantic issues, such as one-based indexing, would remain. It'll be a sad day if Julia starts to get such popularity that high quality libraries will be Julia-only.

What syntax would you like instead, for numerical programming? * Python seems not so different, but once you add numpy then it involves a lot of ugly `np.arcsin(np.sqrt([...]))` type of things. * R looks horrifyingly ugly but I haven't written anything Coming from Mathematica 1-based is comforting, and it also matches the way people write mathematics on paper which is nice.

I mostly use Python, although it has some syntax issues too (eg. no real lambdas, I'd prefer no parenthesis for function calls etc). I don't see why that's a numpy problem. If you just do "from numpy import *" you can pollute your namespace with hundreds of symbols, just like eg. MATLAB.

R not just looks ugly, but is quite horrible in the inside too. For example the variable scoping is one of the most insane I have ever seen.

But in general, I think having special purpose languages is mostly a bad idea. Firstly, having domain specific languages isolate different fields of science: If engineers use MATLAB and statisticians use R, the transfer of progress between these fields is hindered. Secondly, almost all special purpose languages for scientific stuff encourage horrible programming practices. Which typically leads to practice in the field lagging years or even decades behind scientific advances, because usable implementations are quite scarce, or tied to a domain-specific language.

Re: Some Insights from a Julia Developer

#38

Post by pvg »

disconnected wrote: post #23
azag0 wrote: post #7

Earlier quoted context omitted.

One-based indexing is not a semantic issue, it's a language-design decision you may disagree with.

I don't have any particular feelings toward one or the other (it is a convention, get over it), but I think that zero-based indexing is just an artifact of C that stuck around. In C, the array syntax is "mostly" just syntactic sugar for pointer arithmetic. When you do "a[n]=value;" this is equivalent to " *(a+n) = value;". To get the nth cell of an array, you just add "n" to your base pointer "a". Array indexing, the…

Zero based indexing is not a C artifact. Here's Dijkstra writing about it in '82:

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

Re: Some Insights from a Julia Developer

#39

Post by [deleted] »

attractivechaos wrote: post #21
pjmlp wrote: post #15

Earlier quoted context omitted.

Why ugly? It looks similar to what I know in the Pascal family, where indexes can be ranges or enumerations.

It is ugly because 1) 1-based indexing and x-based indexing are treated differently; 2) x-based indexing has to use more complex syntax, which in effect discourages the use of non-1 indexing; 3) this strategy sets potential pitfalls (e.g. implementing length and size for non-1 indexing arrays). A cleaner design, I guess, would be to specify index range on declaration like pascal static arrays and use low(A):high(A) f…

[deleted]
Post reply on HN