Live data from Hacker News

An R programmer looks at Julia

r-bloggers.com

11–20 of 24 posts

Re: An R programmer looks at Julia

#11

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

I find that I do the same thing, except with Ruby for data processing instead of Python. It may be that I just don't know R all that well, but there are so many tasks that are incredibly awkward in R, often requiring a third-party library like plyr which are easily expressed in a language with more "normal" semantics.

An example, from this week: I have a bunch of CSV data files from various trials of an experiment. I want to combine them into one data frame with a new column that includes an id for trial. This took me about a half hour to figure out in R, and five minutes to write in Ruby.

I think the main problem with R is that there's a different way to do everything. It feels like a language that was not so much designed as gradually evolved. In a functional-ish language like Ruby or Python you have a few workhorse data manipulation tools: map, fold, etc. But in R everything is different depending on whether you're dealing with row vectors, column vectors, data frame, or arrays. It makes it hard to generalize over slightly different problems to find common solutions.

Julia looks really awesome, though, and I'm excited to see something that might be able to replace R and bring all of this comfortably into one language.

Re: An R programmer looks at Julia

#12
post #10
post #5

I've written a few hundred lines of R sporadically over the last several years. The absolute worst thing about it in my opinion is the type system. It does not matter how many times I use R, I cannot for the life of me remember or understand the difference between vectors, arrays, lists, data frames, and matrices. A list is sort of like a mix between an array and a map, a matrix is sorta like a 2d vector but can have…

The terminology is weird. I'm not an R expert, but here's how I think of it: vector: this one is clear based on the name; it's a homogeneous sequence (with very aggressive type conversion). A sequence of strings, a sequence of numerics, etc. One thing worth knowing is that there are no atomic types, so c(1) == 1. That is, the value 1 is identical to the singleton vector containing 1. Also the empty vector c() is iden…

Hi chubot,

Two things:

1) A data.frame is in fact a list of vectors of the same length "compacted" together.

2) I find the types very "sensible" for a person doing statistics. But I guess (almost) everything makes sense once you get used to it...

Re: An R programmer looks at Julia

#13

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

That is very interesting. I use Python to pre-process data for Matlab, and have been giving serious thought lately to learning R for its free license and easy(?) integration with Hadoop. Can you briefly comment on the advantages or R over Matlab aside from licensing?

One thing is probably the huge number of statistical packages it has (see: http://cran.r-project.org/web/views/), including (static) graphics (e.g: ggplot2, lattice, and just the base graphics).

Re: An R programmer looks at Julia

#14

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

That is very interesting. I use Python to pre-process data for Matlab, and have been giving serious thought lately to learning R for its free license and easy(?) integration with Hadoop. Can you briefly comment on the advantages or R over Matlab aside from licensing?

If you're already used to Matlab, then you may not find my comments as relevant. If you were already proficient in both, then they're both interchangeable for many tasks (which is in fact why I always recommend learning R over learning Matlab).

Licensing isn't just a minor thing - getting Matlab to run on non-Debian Linux is a painful ordeal. I never actually got it working, because I never bothered to debug its cryptic error messages, and since it's distributed as a precompiled binary, I wasn't going to sit around trying to patch it. A corollary is that R is easier to integrate into other toolkits, and there are a ridiculous number of freely available R libraries that make your life easier.

My issues with Matlab may be things that someone familiar with the language would care less about. That said, I find Matlab to be incredibly, incredibly irritating, and I think that's because it's design is tailored towards people with minimal experience with other programming languages (like research scientists), whereas R's design is simply based off of S - so I find it violates the Principle of Least Surprise less. Matlab is not like Lisp or Haskell (where the journey of understanding the language is valuable in itself) - it's really just a means to an end (number crunching), so the POLS is especally important.

R, unlike Matlab, imposes almost no restrictions on the structure of a program. The way I see it, Matlab makes Java's broken one-class-per-file model even worse, by imposing more filesystem-level restrictions on my program.

R, unlike Matlab, uses a type system that's more familiar to someone used to programming with multiple datatypes, as opposed to someone used to thinking in terms of strictly numerical structures. I never got the hang of when I should index with () or {} or [] Matlab ... I'd have to look it up to tell you. R, on the other hand, is more like Python in this regard - even if it's not quite as clean as Python, it makes basic things like importing/maniplating CSVs much easier than Python (or even Excel, which is even designed around that exact purpose).

R, unlike Matlab, returns the last value computed, not the last values with the same local names as the return value names.

R, unlike Matlab, uses a more intuitive (to me) definition of dimensions (and of row- vs. column-vectors). I spent 80% of my time in Matlab figuring out how to get dimensions to match in a robust manner, and I've never had to do that in R.

You get the idea - my frustrations with the language itself are mostly with the fact that it's so unlike most other languages, and it's too much of a hassle to learn. My frustrations with the language environment is that the free alternative (R) is much easier to work with, and much more cross-platform.

Re: An R programmer looks at Julia

#15
post #11

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

I find that I do the same thing, except with Ruby for data processing instead of Python. It may be that I just don't know R all that well, but there are so many tasks that are incredibly awkward in R, often requiring a third-party library like plyr which are easily expressed in a language with more "normal" semantics. An example, from this week: I have a bunch of CSV data files from various trials of an experiment. I…

> I think the main problem with R is that there's a different way to do everything. It feels like a language that was not so much designed as gradually evolved.

I don't know how much you know about the history of R, but you're spot on about that.

Re: An R programmer looks at Julia

#16

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

Have you evaluated any other of the LLVM languages such as Clay or Rust?

Re: An R programmer looks at Julia

#17

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

What do you think of pandas? It gives you an R-esque feel within Python.

Re: An R programmer looks at Julia

#18

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

> I guess the answer is (as always!) to use a purely homoiconic Lisp dialect, so you get the best of both worlds but that's asking a lot of statisticians.

For what it's worth, Julia is homoiconic and "underneath" the Matlab-like syntactic exterior, quite a lot like scheme.

Re: An R programmer looks at Julia

#19

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

What do you think of pandas? It gives you an R-esque feel within Python.

I haven't used it - I'll check it out. Though the more I think about it, the more I think that my issues stem from the fact that I need two fundamentally different ways of looking at types in each part of the workflow, so it may be difficult to simulate that within Python - we'll see.

Re: An R programmer looks at Julia

#20
post #16

I have to come to love R (for what I use it it for), but reading this makes me realize how unusual my R-workflow must be, because most of the 'advantages' of Julia over R don't really come up in my daily workflow anymore - it seems that's likely because I've adapted to the shortcomings of R and have twisted other tools to my needs. I'll add Julia to my list of languages to check out in more detail, because perhaps Ju…

Have you evaluated any other of the LLVM languages such as Clay or Rust?

One of my friends seems to like Rust, though I haven't actually used either myself.
Post reply on HN