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

181–190 of 241 posts

Re: Some Insights from a Julia Developer

#181

Post by ChrisRackauckas »

syllogism wrote: post #97
ChrisRackauckas wrote: post #11

Earlier quoted context omitted.

I don't find it strange: I wrote this to say why I like using Julia and point out what the community is missing, not as a comparison to every other JIT in existence. But if you want to know why I gave up on Cython, I'll lay it out for you. I tried it almost 2 years ago because some documents in a course had IPython notebooks which used it. So I did some standard scientific computing stuff like write some Runge-Kutta…

Well...It is strange to omit Cython, because that's what the package authors actually use :). It's a huge part of answer to the question you pose about how package development works in Python. Cython isn't perfect, but it works very well. To answer the specific question you had about multiple dispatch: Cython's had fused types for a while now, although I guess they weren't so prominent in the docs when you were tryin…

The problem is, I needed the library. I didn't have the time and resources to build it in Python, while it was a night project for a week to build it in Julia. As a methods researcher I'm going to use the tool that doesn't impede my research but allows me to distribute robust and performant implementations, which after trying lot of other tools I've found is Julia.

Re: Some Insights from a Julia Developer

#182

Post by ChrisRackauckas »

bluescarni wrote: post #120
ChrisRackauckas wrote: post #11

Earlier quoted context omitted.

I don't find it strange: I wrote this to say why I like using Julia and point out what the community is missing, not as a comparison to every other JIT in existence. But if you want to know why I gave up on Cython, I'll lay it out for you. I tried it almost 2 years ago because some documents in a course had IPython notebooks which used it. So I did some standard scientific computing stuff like write some Runge-Kutta…

From your list of "first-choice languages", C++ is conspicuously missing. That seems rather peculiar, as the type of genericity you are praising Julia for has been one of the core concepts of generic programming in C++ since basically the late nineties with the standardization of the STL (and it's become an increasingly emphasized part of the language throughout its evolution in the last 10 years or so, see C++11 and…

I learned C because of classes in MPI and I tried to go back to it after years of Python and MATLAB but the amount of boilerplate code and the workflow slowed me down too much. C++ is definitely a fine choice if you are a great programmer but I don't find it easy at all to prototype or maintain codebases in languages like that. YMMV

Re: Some Insights from a Julia Developer

#183

Post by dnautics »

x0x0 wrote: post #155
ACow_Adonis wrote: post #147

Sometimes, in my darker moments, I have the terrifying thought that one of the reasons that many users like R and made it popular (apart from the historical context of its now many libraries and being the main free version of statistical software), is specifically that it isn't robust and sensibly designed from a programming/analytical perspective. You can download a package, type in a preset command on a preset thin…

I think your fears are misplaced. R users love R because of ease of use. R does sometimes ignores ugly corner cases in favor of that ease of use (though I'm skeptical this damages the validity of the answer in anything like 5% of cases), but that's a side effect. sklearn and pandas are great, but you still simply have to be a programmer to use them, or at least much closer to a programmer than many statisticians want…

hell, I'm a programmer (currently writing low-level i/o access to a linux block device) and I shudder when thinking of having to learn sklearn and pandas.

Re: Some Insights from a Julia Developer

#184

Post by x0x0 »

ACow_Adonis wrote: post #161
x0x0 wrote: post #155

Earlier quoted context omitted.

I think your fears are misplaced. R users love R because of ease of use. R does sometimes ignores ugly corner cases in favor of that ease of use (though I'm skeptical this damages the validity of the answer in anything like 5% of cases), but that's a side effect. sklearn and pandas are great, but you still simply have to be a programmer to use them, or at least much closer to a programmer than many statisticians want…

In many ways, I think we're actually in agreement :p Free. Quick. Interactive. 4 lines. Done. What's the value proposition of Julia compared to that? Now you can argue that Julia will allow better type specification and specialisation, etc, etc. But that's not what's valued or used in your example. Now, my mindset/domain has to engage with such, and i freak out at the implicit-ness/assumptions inherent in such code,…

I don't think julia is going after R's niche. They're going after matlab and sklearn/pandas/numpy.

so my 02 on julia's value prop: free. performant. scalable. capable. easy to use is there, but the others matter a bit more.

Re: Some Insights from a Julia Developer

#185

Post by x0x0 »

dnautics wrote: post #183
x0x0 wrote: post #155

Earlier quoted context omitted.

I think your fears are misplaced. R users love R because of ease of use. R does sometimes ignores ugly corner cases in favor of that ease of use (though I'm skeptical this damages the validity of the answer in anything like 5% of cases), but that's a side effect. sklearn and pandas are great, but you still simply have to be a programmer to use them, or at least much closer to a programmer than many statisticians want…

hell, I'm a programmer (currently writing low-level i/o access to a linux block device) and I shudder when thinking of having to learn sklearn and pandas.

They're great, really! I'm not a hater. It's just you have to be at least an ok programmer to use them, because (and I know this isn't a word) the programmery-ness of what you're doing just pokes through a lot.

Re: Some Insights from a Julia Developer

#186

Post by dnautics »

ACow_Adonis wrote: post #161
x0x0 wrote: post #155

Earlier quoted context omitted.

I think your fears are misplaced. R users love R because of ease of use. R does sometimes ignores ugly corner cases in favor of that ease of use (though I'm skeptical this damages the validity of the answer in anything like 5% of cases), but that's a side effect. sklearn and pandas are great, but you still simply have to be a programmer to use them, or at least much closer to a programmer than many statisticians want…

In many ways, I think we're actually in agreement :p Free. Quick. Interactive. 4 lines. Done. What's the value proposition of Julia compared to that? Now you can argue that Julia will allow better type specification and specialisation, etc, etc. But that's not what's valued or used in your example. Now, my mindset/domain has to engage with such, and i freak out at the implicit-ness/assumptions inherent in such code,…

julia code tends to be extremely terse. I had to listen to unix domain sockets and spit out an aggregated result to an upstream analytics engine and I accomplished the whole thing (including spawning worker threads to listen to potentially multiple clients posting to the domain sockets), in about 65 lines of code. It's also very readable. I don't have any uptime guarantees or anything (and it requires a fairly heavyweight julia container - or a julia runtime installation - atm), so I wouldn't say it's an optimal solution moving forward, but as a glue piece I was able to show a demo and get to the point where I was debugging upstream and downstream components.

Re: Some Insights from a Julia Developer

#187

Post by dnautics »

Bromskloss wrote: post #42
baldfat wrote: post #27

Earlier quoted context omitted.

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?

Enumeration should generally begin at 1. In common language, you don't say "this person won the 0th place trophy", you say "this person won the 1st place trophy". It's address offsetting that should begin at 0.

C strongly encourages you to think of arrays as simply address+offset pointers, so it absolutely should start with 0.

Re: Some Insights from a Julia Developer

#188

Post by Bromskloss »

dnautics wrote: post #187
Bromskloss wrote: post #42

Earlier quoted context omitted.

> 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?

Enumeration should generally begin at 1. In common language, you don't say "this person won the 0th place trophy", you say "this person won the 1st place trophy". It's address offsetting that should begin at 0. C strongly encourages you to think of arrays as simply address+offset pointers, so it absolutely should start with 0.

> you don't say "this person won the 0th place trophy"

I think it would make sense to say it. The reason I don't is that people around me would misunderstand me if I did. (Around some people, it works, though!)

Re: Some Insights from a Julia Developer

#189

Post by simonbyrne »

ssivark wrote: post #96
88e282102ae2e5b wrote: post #94

Earlier quoted context omitted.

I didn't mean to seem petty, it's just that going back and forth between zero-based and one-based languages just added extra mental overhead (admittedly this was with Fortran, so there may have been other issues).

The way I think of it is that different indexing schemes suit different problems. I want to think carefully about the problem domain and use the most convenient convention. For example, when my array stores a time series, I would like the index to correspond to timestamps (and still be performant, so long as my timestamps can be efficiently mapped to memory locations, which is true for affine transformations, for exa…

Fourier transforms are a great example: when I started with Julia, this was the only time I missed 0-based indexing.

Now there is the awesome FFTViews.jl package which goes one better with wrap-around indexing: https://github.com/JuliaArrays/FFTViews.jl

Re: Some Insights from a Julia Developer

#190

Post by Bromskloss »

Bromskloss wrote: post #156
baldfat wrote: post #149

Earlier quoted context omitted.

Also head and tail in Pandas is 1 based! That drove me crazy. print(users[users.age > 25].head(3)) Returns 3 elements and not 4!

Is it possible that the argument to `head` is the _number_ of elements to return, and that the choice of indexing therefore doesn't enter the picture?

Actually, even if the argument (3 in this case) were an index, I would expect it to be the index of the first element _not_ to fetch, like how intervals typically are written with an inclusive lower bound and an exclusive upper bound as in "2 ≤ i Of course, I don't know what Pandas is like outside this particular example, or what Pandas even is. A database thing?

[0] https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

Post reply on HN