4 ms·

Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programmin

by e12e 8y ago

Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programming language) - with the benefit of speed - and no/hardly any need to drop to/link to C libraries - "everything" is in Julia, and you can inspect the code "all the way down" (well, to a point - there's of course llvm at the bottom). Whether Julia is that for you right now probably depends a bit on your needs/use cases. Until Julia gains some form of aot compiler for static binaries - it's not quite an alternative to python imnho - you can't expect to run Julia scripts everywhere you can run python. Though this is similar to R. And there are of course much bigger ecosystems for python and R code/libraries than currently for Julia. Personally I think they've done a great job on the design/syntax of Julia - it's a fun language - and that might be the best reason to play with it?

Cosi1125 8y ago
> and python (a sane, real programming language) So... R is an unreal language then?
- deleted 8y ago
  [deleted]
- disgruntledphd2 8y ago
  Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming. Because of the re-implementation of S, it has lots of odd quirks and multiple ways to do things, which Python tends to avoid. Python is definitely more consistent from a programming point of view, but R is a more cohesive system from an analytics point of view. But yeah, lots of people are hateRs (unfortunately).
  - kgwgk 8y ago
    > Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. Was S "really, really old" when it was re-implemented in R? Gentleman and Ihaka first announced R in 1993 (26 years ago!). The development of S started in 1976 (i.e. 17 years before R was first released). R was a implementation of S3, "the New S language", which was a major rewrite done in 1988 (it was just five years old when R was announced!).
  - Cosi1125 8y ago
    Wise words here. In my humble opinion, applying S's syntactic sugar on top of Scheme-forged core did more bad than good to R. Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible. As for the two approaches to solving problems (TIMTOWTDI vs Python's "one true way") I think that's a matter of personal preference; I, personally, appreciate the freedom that R gives me. Also, it might be anectodal, but I believe that - to some extent - it promotes thinking "outside the box", especially when you work in a team and review others' code on a daily basis.
    - altairiumblue 8y ago
      Your very last point should be heavily against R, not in favour. Having multiple ways to do the same thing is fine when you work by yourself, but in a large team it makes the style of the codebase vary a lot based on who wrote each block of code and makes reviewing others' code more difficult. If you want to get anything done, reading code really shouldn't be your daily challenge of how "outside the box" you can think just so you can understand what is going on.
      - Cosi1125 8y ago
        That's true if we're talking about the overall architecture of the project. And, since R permits so many different coding styles (and paradigms: native functional and several OO), the team should have someone (usually the most senior software engineer) play the role of an architect and design the structure of the code, data structures, API, and so on. Perhaps having a fixed (and commonly agreed on) set of design patterns - like in Java - makes development easier and smoother, but most of the projects I've worked on have proven successful, so maybe it's not that bad either... :-)
- vharuck 8y ago
  I use R daily at work, and often reach for it before Python for non-statistical tasks out of comfort. But R's functions for non-statistical tasks often break the language's idioms. Those dealing with files and connections are especially ugly. I wouldn't call it insane or unreal, but it's definitely not intended for general scripting.
  - Cosi1125 8y ago
    I don't argue that R is not insane ;-) As for (a bunch of) functions in the basic library (which, essentially, is a set of packages that you can discard or simply not use), I dare say it has little to do with the language itself. I don't like Python's regular expressions library, for example, but it's only a set of functions (or methods) that you can write on your own! The same goes for R's data-wrangling routines; there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library. Heck, you can even write your own DSL (think: Grammar of Graphics) if you think it could improve your code! There are several quirks built so deeply into the core of the language that you cannot overcome them ("why can't I overload `+` for character strings??"), but they have nothing to do with the rather poor and unintuitive basic library.
    - kgwgk 8y ago
      > there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library A different take on the subject (https://r4stats.com/2017/03/23/the-tidyverse-curse/ https://r4stats.com/2017/03/23/the-tidyverse-curse/): > On the other hand side – I have met a guy using R in production. And he told me that he needs code that stayed the same for 5+ years. That is why he does not use dplyr or any tidyverse, it is still changing too much.
      - Cosi1125 8y ago
        That's right! And I always keep telling my peers that they should think twice before they decide to use tidyverse packages in the production code. What I meant is that in R you always have choice - and even if you feel that the existing solutions don't meet your expectations, you can always write your own (even if it means writing a DSL like Hadley et al. did in ggplot2 or rlang).

by e12e 8y ago

Cosi1125 8y ago

> and python (a sane, real programming language) So... R is an unreal language then?

deleted 8y ago
[deleted]
disgruntledphd2 8y ago
Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming. Because of the re-implementation of S, it has lots of odd quirks and multiple ways to do things, which Python tends to avoid. Python is definitely more consistent from a programming point of view, but R is a more cohesive system from an analytics point of view. But yeah, lots of people are hateRs (unfortunately).
- kgwgk 8y ago
  > Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. Was S "really, really old" when it was re-implemented in R? Gentleman and Ihaka first announced R in 1993 (26 years ago!). The development of S started in 1976 (i.e. 17 years before R was first released). R was a implementation of S3, "the New S language", which was a major rewrite done in 1988 (it was just five years old when R was announced!).
- Cosi1125 8y ago
  Wise words here. In my humble opinion, applying S's syntactic sugar on top of Scheme-forged core did more bad than good to R. Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible. As for the two approaches to solving problems (TIMTOWTDI vs Python's "one true way") I think that's a matter of personal preference; I, personally, appreciate the freedom that R gives me. Also, it might be anectodal, but I believe that - to some extent - it promotes thinking "outside the box", especially when you work in a team and review others' code on a daily basis.
  - altairiumblue 8y ago
    Your very last point should be heavily against R, not in favour. Having multiple ways to do the same thing is fine when you work by yourself, but in a large team it makes the style of the codebase vary a lot based on who wrote each block of code and makes reviewing others' code more difficult. If you want to get anything done, reading code really shouldn't be your daily challenge of how "outside the box" you can think just so you can understand what is going on.
    - Cosi1125 8y ago
      That's true if we're talking about the overall architecture of the project. And, since R permits so many different coding styles (and paradigms: native functional and several OO), the team should have someone (usually the most senior software engineer) play the role of an architect and design the structure of the code, data structures, API, and so on. Perhaps having a fixed (and commonly agreed on) set of design patterns - like in Java - makes development easier and smoother, but most of the projects I've worked on have proven successful, so maybe it's not that bad either... :-)
vharuck 8y ago
I use R daily at work, and often reach for it before Python for non-statistical tasks out of comfort. But R's functions for non-statistical tasks often break the language's idioms. Those dealing with files and connections are especially ugly. I wouldn't call it insane or unreal, but it's definitely not intended for general scripting.
- Cosi1125 8y ago
  I don't argue that R is not insane ;-) As for (a bunch of) functions in the basic library (which, essentially, is a set of packages that you can discard or simply not use), I dare say it has little to do with the language itself. I don't like Python's regular expressions library, for example, but it's only a set of functions (or methods) that you can write on your own! The same goes for R's data-wrangling routines; there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library. Heck, you can even write your own DSL (think: Grammar of Graphics) if you think it could improve your code! There are several quirks built so deeply into the core of the language that you cannot overcome them ("why can't I overload `+` for character strings??"), but they have nothing to do with the rather poor and unintuitive basic library.
  - kgwgk 8y ago
    > there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library A different take on the subject (https://r4stats.com/2017/03/23/the-tidyverse-curse/ https://r4stats.com/2017/03/23/the-tidyverse-curse/): > On the other hand side – I have met a guy using R in production. And he told me that he needs code that stayed the same for 5+ years. That is why he does not use dplyr or any tidyverse, it is still changing too much.
    - Cosi1125 8y ago
      That's right! And I always keep telling my peers that they should think twice before they decide to use tidyverse packages in the production code. What I meant is that in R you always have choice - and even if you feel that the existing solutions don't meet your expectations, you can always write your own (even if it means writing a DSL like Hadley et al. did in ggplot2 or rlang).