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

41–50 of 241 posts

Re: Some Insights from a Julia Developer

#41

Post by attractivechaos »

ChrisRackauckas wrote: post #25
attractivechaos wrote: post #21

Earlier quoted context omitted.

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…

1) No, they are just different dispatches to getindex. 2) No, iteration is through indices(A) or eachindex(A), etc., which are the preferred way of iterating anyways. You shouldn't do 1:length(A) which is a MATLABism that works but I would say isn't good Julia. 3) Defining new dispatches for length and size is a pretty standard use of the language? "Non-standard" arrays with non-standard indexing already work in lots…

On 2), if you think 1:length(A) is bad, why not forbid it from beginning (e.g. use low(A):high(A) instead)? To find an x-based array length, why not just length(A), instead of length(linearindices(A))? Decisions like such are remedies of immature early design. Also, what if I use length() on an x-based array? Abort or a wrong number silently? On 1), having two different ways to access array, the most fundamental data type, is already worrying enough. On 3), the page says "don't implement size or length". That is very uncommon in most other mainstream languages.

Julia has potential to become a great general-purpose programming language, but this indexing issue will practically limit it to the numerical computing community. Perhaps achieving that is already good enough.

Re: Some Insights from a Julia Developer

#42

Post by Bromskloss »

baldfat wrote: post #27
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.

I have zero understanding about this rant? 0 based is due to programming iteration. I don't use pandas because it is 0 based and it was a mistake. Domain Specific Languages for Statistics and "Math" have traditionally been 1 based. R is one based and S before that. The fact that Pandas went with 0 based was a huge disappointment for many. I use R.

> 0 based is due to programming iteration.

I think it makes sense for enumeration in general to begin at 0. It's a mapping from the natural numbers after all, and zero is the most natural number!

What makes you think of programming iteration as a motivation for zero-based indexing?

Re: Some Insights from a Julia Developer

#43

Post by mkborregaard »

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…

One of the most mindboggling thing about the recurrent 0- vs 1-based indexing discussion is how incredibly rarely that difference is ever used programmatically in Julia. Most of the large julia packages are programmed in a way that doesn't care whether the array is 0 or 1 based. It is important in some other languages, and then I just think people are happy that this is something that everybody can agree to disagree on. I don't think the discussion is very productive though.

Re: Some Insights from a Julia Developer

#44

Post by mkborregaard »

ChrisRackauckas wrote: post #25
attractivechaos wrote: post #21

Earlier quoted context omitted.

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…

1) No, they are just different dispatches to getindex. 2) No, iteration is through indices(A) or eachindex(A), etc., which are the preferred way of iterating anyways. You shouldn't do 1:length(A) which is a MATLABism that works but I would say isn't good Julia. 3) Defining new dispatches for length and size is a pretty standard use of the language? "Non-standard" arrays with non-standard indexing already work in lots…

The `length(linearindices)` and no `size` etc are for a short transitory period while packages are ported to the indexing-based-non-reliant framework.

Re: Some Insights from a Julia Developer

#45

Post by Bromskloss »

mkborregaard wrote: post #29
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…

Julia supports indexing with arbitrary bases, and it generally works ecosystem-wide.

Oh, it does? I've taken to saying that "zero-based indexing – that's how Julia broke my heart", because at the time, I didn't get the impression that there was anything else in sight. How do I index based on zero?

Re: Some Insights from a Julia Developer

#46

Post by ChrisRackauckas »

ChrisRackauckas wrote: post #25
attractivechaos wrote: post #21

Earlier quoted context omitted.

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…

1) No, they are just different dispatches to getindex. 2) No, iteration is through indices(A) or eachindex(A), etc., which are the preferred way of iterating anyways. You shouldn't do 1:length(A) which is a MATLABism that works but I would say isn't good Julia. 3) Defining new dispatches for length and size is a pretty standard use of the language? "Non-standard" arrays with non-standard indexing already work in lots…

@attractivechaos I don't know how to reply to your last reply, so I'll do it here. 1:length(A) is bad because it's using a standard construction for intervals of numbers, but using it for indices. We don't want to get rid of it because 1:5 or 0:0.2:1 is something that is very common and necessary, but I don't see how to tell one that they should instead use eachindex(A) except through proper docs. 1:length(A) is so common in MATLAB though that I am sure people will carry it over, and I'll PR to their library to fix it. I'm not sure how to fix a knowledge issue like that.

You're not understanding generic types and its relation to (1). There's only one way to access an array: getindex. That's the function that's called with A[i]. However, you can use an immutable to put a thin (zero-cost) wrapper over an array, and define dispatches to getindex to do whatever you need it to do. So it's both implicit syntactically because the user just does A[i], but it's explicit because the user has to choose a different type. getindex is then usually inlined and then compiled according to the type, making it a thin abstraction over the implementation.

There are iterators which don't have a size or length. You can write generic algorithms which require an AbstractArray which HasLength and query at compile time for things like that and throw appropriate errors (those are called traits).

There is still a lot of development to do here, but the basics like this are pretty much solved except when new users treat Julia like MATLAB, but I'm not sure how anyone could control for that.

Re: Some Insights from a Julia Developer

#47

Post by noobhacker »

jampekka wrote: post #37
improbable22 wrote: post #19

Earlier quoted context omitted.

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

Could you clarify what's insane about the variable scoping in R? I'm a bit too close to R so I'm afraid I'm oblivious.

Re: Some Insights from a Julia Developer

#49

Post by salqadri »

crwalker wrote: post #48

Julia is my go-to language for numerical work. Compared to other solutions I've used like python + numpy + pandas, Matlab, Mathcad, heh even Excel, Julia is a breath of fresh air. Fast, clean, powerful.

The feature to observe the underlying AST is amazing!

Re: Some Insights from a Julia Developer

#50

Post by 88e282102ae2e5b »

jernfrost wrote: post #33
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 a…

Is Julia really that much more performant than numpy?
Post reply on HN