271–280 of 309 posts
Any recommendations on beginner (to Julia) books to get started?
The manual is great https://docs.julialang.org/en/v1/manual/getting-started/ . If you want something more step-by-step with some simple exercises, check https://benlauwens.github.io/ThinkJulia.jl/latest/book.html .
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…
Fourth, the ability to effortlessly drop down several layers of abstraction: Pointer types, all packages including Base are written in Julia and can easily be extended or patched on the fly, homoiconicity, seamless integration with BLAS and LAPACK.
Earlier quoted context omitted.
If we removed dplyr, then R scripts would absolutely scream so I find the speed argument for 'why switch to X' unconvincing. If users cared so deeply about speed, almost no one would be using tidyverse instead we'd all be using base-R or data.table. Multiple dispatch? Hmm is this really a problem that I'm going to come across in the real-world when 90% of our time is spent ingesting a poorly-formatted csv, doing some…
> is this really a problem that I'm going to come across in the real-world when 90% of our time is spent ingesting a poorly-formatted csv, doing some quick plots and perhaps building a model to test something out Yes, multiple dispatch is not some highfalutin ivory tower concept that only comes up in specialized code. For example, the model in question could define custom plotting recipes[1] so that you can just call…
Naturally you are correct and I am wrong to dismiss it as unimportant. What I'm saying is that the majority of R/Python users today are not looking for ultimate speed or sophisticated programming paradigms. Most users are doing the unsexy bread and butter of 'Take some tabular data' -> analyse -> report on it and I want to dismiss the argument of 'users will migrate to Julia because of these nifty features' because it ignores the very reasons the existing users use these tools in the first place. It would be as absurd as proclaiming Excel users will switch to Python because the accounts deparment suddenly cares about NLP.
Earlier quoted context omitted.
This whole thread seems to be quite civilized. I can see no name-calling or off-topic rants, only a frank exchange of opinions, mixed in with some facts. Your post seem to indicate that there is some sort of 'fight' going on, or that the tone is broken. I disagree. If most web discussions were like this one, we would have fewer problems in this world.
Oh, that's exactly what I mean -- when I say "everything that's broken about the tone of web discussions these days", I'm talking about threads and topics other than this one. I don't see any 'fight' here, and that's what's so refreshing.
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 agree that most of the time data wrangling is super confortable in R due to the syntax flexibility exploited by the big packages (tidyverse/data.table/etc). At the same time, Julia and R share a bigger heritage from Lisp influence that with Python, because R is also a Lisp-ish language (see [Advanced R, Metaprogramming]). My main grip from the R ecosystem is not that most of the perfomance sensitive packages are written in C/C++/Fortran but are written so deeply interconnect with the R environment that porting them to Julia that provide also an easy and good interface to C/C++/Fortran (and more see [Julia Interop] repo) seems impossible for some of them.
I also think that Julia reach to broader scientific programming public than R, where it overlaps with Python sometimes but provides the Matlab/Octave public with an better alternative. I don't expected to see all the habits from those communities merge into Julia ecosystem. On the other side, I think that Julia bigger reach will avoid to fall into the "base" vs "tidyverse" vs "something else in-between" that R is now.
[PyCall.jl]: https://github.com/JuliaPy/PyCall.jl
[RCall.jl]: https://github.com/JuliaInterop/RCall.jl
[Julia Interop]: https://github.com/JuliaInterop
[Advanced R, Metaprogramming] by Hadley Wickham: https://adv-r.hadley.nz/metaprogramming.html
Earlier quoted context omitted.
If we removed dplyr, then R scripts would absolutely scream so I find the speed argument for 'why switch to X' unconvincing. If users cared so deeply about speed, almost no one would be using tidyverse instead we'd all be using base-R or data.table. Multiple dispatch? Hmm is this really a problem that I'm going to come across in the real-world when 90% of our time is spent ingesting a poorly-formatted csv, doing some…
> If the goal of Julia is to replace R/Python then their priorities feel way off the mark There's a lot more to scientific computing than wrangling tabular data. Julia is competing in that overall space with R/Python/Fortran/Java/C++. If R or Pandas is better at data wrangling, then Julia won't win out there. But so be it. No PL is best at everything.
I'm a graduate student that's switched almost completely over to Julia. Prior to it I worked in both MATLAB (the IDE is so nice, and writing out matrix computations is just great) and Python (for ML). Julia is absolutely nicer to write in than either of the two. MATLAB is slow and at times feels less like a programming language and more like an incomplete and brittle interface with the JVM. Python is also slow, and i…
I would recommend Plotly.js in VSCode for interactive plotting.
(From the hpcwire article) "During his talk, Edelman presented an example in which a group of researchers decided to scrap their legacy climate code in Fortran and write it from scratch in Julia. There was some discussion around performance tradeoffs they might encounter in the move to a high level programming language. The group was willing to accept a 3x slowdown for the flexibility of the language. Instead, said Edelman, the switch produced 3x speedup."
Earlier quoted context omitted.
I see, that's what I thought. No problem with naming languages after people, but it's easier if it's an homage to a certain person. Common first and last names alone often point to confusing people, and there might be a certain dissonance between the mental images ("I pulled some Julias pigtails in kindergarten, now I have her name on a CV?"). The same problem would probably arise if the last names would be more comm…
I agree that it's easier when it's an homage to a certain person, and a last name, like Pascal. I actually knew that about Pascal but never gave it a second thought. According to Wikipedia at least, "Julia" is not named after anyone in particular.
It's nice imo, the precompilation step is a bit slow imho. Also not sure whether I'm a big fan of its module system.