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

21–30 of 241 posts

Re: Some Insights from a Julia Developer

#21

Post by attractivechaos »

pjmlp wrote: post #15
attractivechaos wrote: post #13

Earlier quoted context omitted.

That is an ugly hack, mainly because it was not in the original language design.

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) for iteration rather than 1:length(A). This, however, complicates 1-based use cases.

Generally, I don't think there is a good way to achieve flexible indexing without causing troubles somewhere, so I don't think Julia has really solved the problem.

Re: Some Insights from a Julia Developer

#22

Post by sin7 »

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.

R had changed a ton in the last three years. It's pretty clean these days.

Re: Some Insights from a Julia Developer

#23

Post by disconnected »

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

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, therefore, is consistent with the pointer arithmetic.

That said, and funnily enough, Fortran, which is much older than C, has 1-based indexing (by default, but you can configure 0 based indexing, if I remember correctly).

Re: Some Insights from a Julia Developer

#24

Post by _Codemonkeyism »

"is a good generic type-stable function for any number which has zero and + defined. That's quite unique: I can put floating point numbers in here, symbolic expressions from SymEngine.jl, ArbFloats from the user-defined ArbFloats.jl fast arbitrary precision library, etc."

Is it really unique? Isn't that just a Monoid (e.g. in Haskell, Scala, ...) or am I wrong?

Re: Some Insights from a Julia Developer

#25

Post by ChrisRackauckas »

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…

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 of packages. It could be better (that's one of the things that I am advocating for), but it's not a language tooling issue whenever it's a problem, it was the developer going `::Array` and thus requiring a contiguous 1-base index array where other AbstractArrays would actually work.

Re: Some Insights from a Julia Developer

#26

Post by StefanKarpinski »

_Codemonkeyism wrote: post #24

"is a good generic type-stable function for any number which has zero and + defined. That's quite unique: I can put floating point numbers in here, symbolic expressions from SymEngine.jl, ArbFloats from the user-defined ArbFloats.jl fast arbitrary precision library, etc." Is it really unique? Isn't that just a Monoid (e.g. in Haskell, Scala, ...) or am I wrong?

I think that unique is an overstatement there, but in the context it's a comparison to other numerical computing systems, where this kind of support for generic code is less common.

Re: Some Insights from a Julia Developer

#27

Post by baldfat »

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.

Re: Some Insights from a Julia Developer

#28

Post by [deleted] »

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…

[deleted]

Re: Some Insights from a Julia Developer

#29

Post by mkborregaard »

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.

Re: Some Insights from a Julia Developer

#30

Post by wallnuss »

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…

* My entire codebase

Julia has great interoperability between Python (checkout PyCall.jl) and many other languages. You don't need to abandon your old codebase.

With regards to your other points, a lot of that is subjective and hard to argue about, but for me Julia has drastically changed the way I approach writing scientific code and is not just an incremental improvement upon the status quo.

Post reply on HN