4 ms·

I am torn, because Hadley Wickham's tools are truly wonderful, but the underlying R language is such a mess. For example, R has lazy evaluation despite being an

I am torn, because Hadley Wickham's tools are truly wonderful, but the underlying R language is such a mess. For example, R has lazy evaluation despite being an imperative stateful language. I wish Hadley had developed these tools for some other language, such as Python, or in a language-agnostic way. Hopefully that is the direction things will go in the future.

x0x0 12y ago
It's python that's really a mess for data science; you can't avoid it being a programming language first and a tool for data science a distant tenth. Syntax that only a programmer would like is necessary, and quite a bit of it at that. R is a much better fit for people who want to do statistics first, and as little programming as possible. Thinks like function parameters being promises make it far easier to deal with functions like optimizers where there really are 10+ tuning parameters or things you may want to tweak. Iterative languages are far easier to understand for people who don't want to be programmers. You cannot develop plyr or ggplot in a language agnostic way, because they need the purpose built syntax R has. Contrast to eg the fight in python to get an infix matrix multiplication operator.
- j2kun 12y ago
  I don't see how not having innate language support for an infix matrix multiplication matters. In R all "infix" operators are really functions anyway[1] so you could write your library that way. Alternatively, you could use python's overloading for infix operators. (Also, since when was Python considered not iterative? And for that matter, doesn't R's widespread use of *apply make it more functional anyway?) [1]: Here is a simple example of that for +, note the very strange overloading of quotes. R version 2.15.2 > "+"(7,5) [1] 12
  - x0x0 12y ago
    I well understand R's operators, but why on earth is that relevant? math: S = ( H β − r )^T * ( H V H^T )^{-1} * ( H β − r ) python, ugly mess S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r) python, better: (although @ is an ugly matrix operator) S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r) the latter is an order of magnitude easier to understand, and looks just like the math. Having one layer of indirection: math to code, is far better than two: math to code to obfuscated code because you won't create infix operators. Edit: examples stolen from the matrix operator pep
    - j2kun 12y ago
      The problem is that you want to do everything in one line. The proper way to do this would be to save things like H.dot(beta) - r in a separate variable and compute it just once. Moreover, if it's hidden in a library then why does the user care if it's ugly? It's the library designer's job to test it and make sure it's right.
      - x0x0 12y ago
        No, I simply want my math to look like math instead of a bunch of code that, after careful reading and some notes, implements some math. It's not a library function, it's the code I write. R, matlab, julia all allow users to write something that looks very close to the actual math. Python doesn't see that as a priority.
- stared 12y ago
  Yeah, it is one of things in which Python is not as flexible, but there are some attempts: http://stackoverflow.com/questions/28252585/functional-pipes-in-python-like-from-dplyr/ http://stackoverflow.com/questions/28252585/functional-pipes...
craigching 12y ago
I disagree. I think if using dplyr + ggplot2 you can go very far without dealing with R's warts and I hope that the future of R lies in this direction. Honestly, R's syntax is not the problem, the "standard" library is the biggest problem in it's inconsistencies. That said, the other big area of complaint in R is the type system. We are too often having to coerce types, but I'm not exactly sure of the solution for that.

x0x0 12y ago

It's python that's really a mess for data science; you can't avoid it being a programming language first and a tool for data science a distant tenth. Syntax that only a programmer would like is necessary, and quite a bit of it at that. R is a much better fit for people who want to do statistics first, and as little programming as possible. Thinks like function parameters being promises make it far easier to deal with functions like optimizers where there really are 10+ tuning parameters or things you may want to tweak. Iterative languages are far easier to understand for people who don't want to be programmers. You cannot develop plyr or ggplot in a language agnostic way, because they need the purpose built syntax R has. Contrast to eg the fight in python to get an infix matrix multiplication operator.

j2kun 12y ago
I don't see how not having innate language support for an infix matrix multiplication matters. In R all "infix" operators are really functions anyway[1] so you could write your library that way. Alternatively, you could use python's overloading for infix operators. (Also, since when was Python considered not iterative? And for that matter, doesn't R's widespread use of *apply make it more functional anyway?) [1]: Here is a simple example of that for +, note the very strange overloading of quotes. R version 2.15.2 > "+"(7,5) [1] 12
- x0x0 12y ago
  I well understand R's operators, but why on earth is that relevant? math: S = ( H β − r )^T * ( H V H^T )^{-1} * ( H β − r ) python, ugly mess S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r) python, better: (although @ is an ugly matrix operator) S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r) the latter is an order of magnitude easier to understand, and looks just like the math. Having one layer of indirection: math to code, is far better than two: math to code to obfuscated code because you won't create infix operators. Edit: examples stolen from the matrix operator pep
  - j2kun 12y ago
    The problem is that you want to do everything in one line. The proper way to do this would be to save things like H.dot(beta) - r in a separate variable and compute it just once. Moreover, if it's hidden in a library then why does the user care if it's ugly? It's the library designer's job to test it and make sure it's right.
    - x0x0 12y ago
      No, I simply want my math to look like math instead of a bunch of code that, after careful reading and some notes, implements some math. It's not a library function, it's the code I write. R, matlab, julia all allow users to write something that looks very close to the actual math. Python doesn't see that as a priority.
stared 12y ago
Yeah, it is one of things in which Python is not as flexible, but there are some attempts: http://stackoverflow.com/questions/28252585/functional-pipes-in-python-like-from-dplyr/ http://stackoverflow.com/questions/28252585/functional-pipes...

craigching 12y ago

I disagree. I think if using dplyr + ggplot2 you can go very far without dealing with R's warts and I hope that the future of R lies in this direction. Honestly, R's syntax is not the problem, the "standard" library is the biggest problem in it's inconsistencies. That said, the other big area of complaint in R is the type system. We are too often having to coerce types, but I'm not exactly sure of the solution for that.