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

Julia adoption keeps climbing

hpcwire.com

Post reply on HN
Print view View original

281–290 of 309 posts

Re: Julia adoption keeps climbing

#281

Post by dm319 »

veddox wrote: post #166
laplacesdemon48 wrote: post #125

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

I deeply loath R for its terrible type idiosyncracies, syntax, and slowness. However, even I must admit that it is incredibly good at what it was meant to do - analyse and display data. (And yes, the tidyverse is a huge improvement of the syntax, although it's telling that they basically reinvented the language to do so.) As an ecological modeller, I create my actual simulation models in Julia, because it is a much,…

I don't understand how people can loath R. If you take a functional approach, especially using pipes, dplyr and a split, apply, combine style, it is quite beautiful. Much nicer than trying to, say, divide a time period by an integer in Go.

Re: Julia adoption keeps climbing

#282

Post by dm319 »

CoolGuySteve wrote: post #141
laplacesdemon48 wrote: post #125

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

When it comes to data wrangling, one huge advantage of Julia over tidyverse/R dataframes/Pandas is that you can write a damn for loop and it won't be brutally slow. It's so much simpler and faster to use a loop that says "pick this row only if this and that and this other thing are sometimes true" vs having to construct an algebra of column filters to do the same.

I think loops are not ideal for data analysis. They are prone to human error, especially ones that modify the data, and in a way that can be hard to sort (i.e.iterating over the dimensions of the wrong object). A stepwise creation of new logical fields using mutate, and then a vectorised ifelse command is more robust and you can clearly see steps of the logic.

Re: Julia adoption keeps climbing

#283

Post by StefanKarpinski »

legerdemain wrote: post #250
StefanKarpinski wrote: post #246

Earlier quoted context omitted.

And as the phrase "reserved" in the error message indicates, it will likely be given a meaning once all the ramifications of doing so are worked out and the best choice of meaning is decided upon. If you're impatient and don't want to wait for that, define it to do what you want. Your code won't even break when it is given an official behavior since your method will overwrite the built-in one.

But this is exactly the kind of thing I called a bothersome corner case. Needing to redefine a global function in order to use fairly intuitive behavior is not great developer experience.

When things like this are left undefined, it's not to intentionally annoy you, as you seem to be taking it. It's generally because there are two or more reasonable possible behaviors and which one is correct hasn't yet been determined. In this particular case, there are subtleties because named tuples can be seen as ordered collections of values and as named associative structures. Deciding that kind of thing takes a lot of time and effort. If you feel that there is a preferred behavior that broadcasting over named tuples ought to have, it would be helpful to post that on GitHub.

Re: Julia adoption keeps climbing

#284

Post by StefanKarpinski »

oivey wrote: post #261
legerdemain wrote: post #241

Earlier quoted context omitted.

Thanks for the good find!

Looks like vectorizing over NamedTuples is explicitly disallowed. Probably you can still vectorize things over the keys and values separately, along with some helper functions, but it is a bit annoying. Looks like the reason was due to questions on whether iteration should be over values or pairs.

Indeed, that is precisely the decision that must be made. Neither one is obviously correct. And once a decision is made and goes into a release, it cannot be unmade — we all have to live with it forever.

Re: Julia adoption keeps climbing

#285

Post by grayclhn »

jpfr wrote: post #23

I teach a graduate course in optimization methods for machine learning and engineering [1,2]. Julia is just perfect for teaching numerical algorithms. First, it removes the typical numpy syntax boilerplate. Due to its conciseness, Julia has mostly replaced showing pseudo-code on my slides. It can be just as concise / readable; and on top the students immeditaly get the "real thing" they can plug into Jupyter notebook…

> Due to its conciseness, Julia has mostly replaced showing pseudo-code on my slides.

This benefit is really underappreciated IMO — for a lot of "science" applications, the core part of the program should be readable by people who don't program in the language. In research papers, by people who want to understand the fine details of your algorithm, for example.

Julia gets closer to "executable pseudocode" than I would have thought possible.

Re: Julia adoption keeps climbing

#286

Post by grayclhn »

dm319 wrote: post #281
veddox wrote: post #166

Earlier quoted context omitted.

I deeply loath R for its terrible type idiosyncracies, syntax, and slowness. However, even I must admit that it is incredibly good at what it was meant to do - analyse and display data. (And yes, the tidyverse is a huge improvement of the syntax, although it's telling that they basically reinvented the language to do so.) As an ecological modeller, I create my actual simulation models in Julia, because it is a much,…

I don't understand how people can loath R. If you take a functional approach, especially using pipes, dplyr and a split, apply, combine style, it is quite beautiful. Much nicer than trying to, say, divide a time period by an integer in Go.

I use a lot of R, and like many aspects of it. But the fact that `f(stop("Hi!"))` may or may not throw an error depending on the internals of `f` is a little maddening. (And there are tons of similar issues.)

Re: Julia adoption keeps climbing

#287

Post by superdimwit »

skybrian wrote: post #277
superdimwit wrote: post #187

Earlier quoted context omitted.

I would recommend Plotly.js in VSCode for interactive plotting.

Could you elaborate? I see that Plotly.js is a JavaScript library, but is there special integration with VSCode?

yes, it integrates with the VSCode plotting pane. Not exactly sure where this happens, though.

Re: Julia adoption keeps climbing

#288

Post by snicker7 »

laplacesdemon48 wrote: post #125

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

> My message to the Julia team: You can get a very large portion of the R userbase to switch over if you focus on a Julia version of the tidyverse (especially dplyr).

How about the Queryverse?

https://www.queryverse.org/

Re: Julia adoption keeps climbing

#289

Post by nextos »

amkkma wrote: post #154
j7ake wrote: post #137

Earlier quoted context omitted.

Another big thing that R has an edge over python (and I guess Julia, but not sure) is making quick yet presentable plots of data that contain different factors that you want to show together. The matplotlib equivalent requires tracking different indices and manually adding layers for different indices.

Julia has plenty of plotting solutions that are better for stats than matplotlib: https://github.com/JuliaPlots/AlgebraOfGraphics.jl https://github.com/queryverse/VegaLite.jl https://github.com/JuliaPlots/StatsPlots.jl

Gadfly is amazing too, and Makie is the future.

Re: Julia adoption keeps climbing

#290

Post by kescobo »

laplacesdemon48 wrote: post #125

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

Out of curiosity, when was the last time you looked at DataFrames.jl? A huge amount has happened in the last year. Plus, if you want more tidy-like syntax, you can go with Query.jl, (or DataFramesMeta.jl, though that isn't quite finished updating to the the new DataFrames syntax), or of you just want pipes on DataFrame operations, there's Pipe.jl and Chain.jl.

I don't think your comments are harsh, you need what you need and you like what you like. I do mostly data wrangling too, but feel much less constrained with Julia than with tidyr. Sometimes having constraints and one right way to do things is good, but it's not for me.

Also worth noting it's not necessarily on the language developers to do this. Even in R, tidyverse is in packages, not in the base language.

Post reply on HN