Earlier quoted context omitted.
That sounds like a major problem with Ubuntu, rather than with Python or pip. On Windows, meanwhile, the standard Python installer gets all this set up properly in like three clicks. Better yet, because it installs per-user by default, "pip install" just works. And if you still choose to install it globally, it will fail, but it will tell you exactly what you need to do to make it work: Could not install packages due…
Eh, that has always been the case for windows vs linux, that you don't have to compile anything yourself because there is always an installer that will deploy precompiled binaries for whatever you want to install (except for when there isn't, because nobody has compiled it for windows, at which point you're in deeper shit) (or except when something installs itself but doesn't update your envars, so you have to do it…
A newcomer’s (angry) guide to R
221–230 of 232 posts
Re: A newcomer’s (angry) guide to R
#222Earlier quoted context omitted.
> R and Lisp are hardly alike even if it was inspire by it. It's like saying Erlang and Prolog is very similar. If you want learn FP do it in Erlang, Lisp, Haskell, etc.. Don't do it in R, it's half baked. They are very alike in the underlying core design, not in how you use them. In R, everything is an expression, and every expression is a function call. Even things like assignments, if/else, or function definitions…
Do you have an example of what R would look like without the C-like syntactic sugar? It doesn't need to be complex, I'm just intrigued about what it might look like.
> as.list(quote(if (1 > 2) 3 else 4));
[[1]]
`if`
[[2]]
1 > 2
[[3]]
[1] 3
[[4]]
[1] 4
Okay, let's try this: > `if`(1 > 2, 3, 4)
[1] 4
And to make sure that it really does evaluate only the correct branch: > `if`(1 > 2, cat(3), cat(4))
4
Now something more interesting: > f f
[[1]]
`function`
[[2]]
[[2]]$x
[[2]]$y
[1] 1
[[3]]
{
x + y
}
[[4]]
function(x, y=1) { x + y }
This last entry is probably confusing, because it looks recursive. However, it's not the function itself - it's the srcref (basically, metadata about where the code came from, used e.g. by debugger to report line numbers) - it just pretty-printed itself like the function it is for. We can ignore it, though. Otherwise there are two arguments here - first one is a pairlist with named elements, one for each argument, and values are the default values for those arguments (if present). Second argument is the function body, which is itself an expression. We can look at that: > as.list(f[[3]])
[[1]]
`{`
[[2]]
x + y
So {} is itself a function! And x+y works as you'd expect: > as.list(f[[3]][[2]])
[[1]]
`+`
[[2]]
x
[[3]]
y
Now let's try to do the same ourselves. One catch here is that function() expects the first argument to be a list itself, rather than an expression that evaluates to a list. So we can't do this: > `function`(pairlist(x=1, y=2), quote({x + y}))
Error: invalid formal argument list for "function"
Because the first argument is not itself a pairlist, but a promise of one. So we need to construct the call, thereby evaluating the arguments in advance, and then eval it. Here's the first take, ignoring the function body: > eval(call("function", pairlist(x=1, y=2), quote({x + y})))
function (x = 1, y = 2)
{
x + y
}
The body we can just rewrite as plain calls: > eval(call("function", pairlist(x=1, y=2), quote(`{`(`+`(x, y)))))
function (x = 1, y = 2)
{
x + y
}
And just to make sure it does what it should: > eval(call("function", pairlist(x=1, y=2), quote(`{`(`+`(x, y)))))(123)
[1] 125
You might have noticed that I've cheated a bit here by giving each argument a default value - the original didn't have one for the first argument. It's because we need to somehow get a "missing" bit on a list element for that to work, and this makes it a great deal more convoluted - R has an easy way to check for it, but not to set it, other than by omitting arguments in function calls. The easiest way to get it is to quote() a call with one, and then just pull the pairlist out of the expression tree.Re: A newcomer’s (angry) guide to R
#223Earlier quoted context omitted.
"I 've done it so it's not so bad" is not a very good argument. I've done a significant data science project in Prolog (with R for the plotting btw) but that doesn't mean Prolog is the go-to language for data science :)
But it is a datapoint against the hypothesis "Prolog is inappropriate for data science".
Re: A newcomer’s (angry) guide to R
#224Earlier quoted context omitted.
Eh, that has always been the case for windows vs linux, that you don't have to compile anything yourself because there is always an installer that will deploy precompiled binaries for whatever you want to install (except for when there isn't, because nobody has compiled it for windows, at which point you're in deeper shit) (or except when something installs itself but doesn't update your envars, so you have to do it…
You don't need to compile anything yourself on Linux either - that's what package managers are for.
Then again, with Python in particular, I have often had errors either with pip-install, or after "successful" installation, for various reasons.
Re: A newcomer’s (angry) guide to R
#225Earlier quoted context omitted.
No, you are wrong. R is terrible , and especially so for non-professional programmers, and it is an absolute disaster for the applications where it routinely gets used, namely statistics for scientific applications. The reason is its strong tendency to fail silently (and, with RStudio, to frequently keep going even when it does fail.) As a result, people get garbage results without realizing , and if they're unlucky,…
R is fundamentally flawed. It tries to merge two highly conflicting goals: a productive analytics environment and a programming language. To do the first really well means automating away many of the issues that would crop up in the second allowing R to 'just work'. Because of that nothing beats R for getting to an answer as fast as possible (not even Python) at the cost of making it more difficult to productionise a…
And it really is insane and horrible.
Re: A newcomer’s (angry) guide to R
#226Earlier quoted context omitted.
Do you have an example of what R would look like without the C-like syntactic sugar? It doesn't need to be complex, I'm just intrigued about what it might look like.
Sure! If you want to experiment with this, it's pretty easy to "reverse engineer" that original form. Just use quote, and convert to a list (you need to do that because expressions will pretty print by default using the same sugar!), to see the internal structure: > as.list(quote(if (1 > 2) 3 else 4)); [[1]] `if` [[2]] 1 > 2 [[3]] [1] 3 [[4]] [1] 4 Okay, let's try this: > `if`(1 > 2, 3, 4) [1] 4 And to make sure that…
Re: A newcomer’s (angry) guide to R
#227To me, this is all the encouragement I need to use R.
Re: A newcomer’s (angry) guide to R
#228Earlier quoted context omitted.
R certainly has a lispish code-as-data element to it, but it seems like it has some serious flaws. Don't most lisps have functions and macros as separate constructs? R has functions, but with some mucking around you can make them do macro-type stuff. Then people write these half-function, half-macro things (e.g. "non-standard evalation") that tend to break composability, either totally or sometimes only in edge cases…
Lisps do that distinction because they need it. In R, you can do everything with functions, because arguments can be lazily evaluated, or you can even get the syntax tree used for that argument at call site instead. So in R, a macro is just a function. And yes, it's easy to break stuff that way. Just as easy as it is with macros (esp. non-hygienic ones).
Because of much better performance and predictability of code.
Re: A newcomer’s (angry) guide to R
#229Earlier quoted context omitted.
You don't need to compile anything yourself on Linux either - that's what package managers are for.
Iiish. For small projects or when you want to get development versions etc that are not in a distro's repos it's pretty common to have to do a make-configure. Then again, with Python in particular, I have often had errors either with pip-install, or after "successful" installation, for various reasons.
Re: A newcomer’s (angry) guide to R
#230Earlier quoted context omitted.
Lisps do that distinction because they need it. In R, you can do everything with functions, because arguments can be lazily evaluated, or you can even get the syntax tree used for that argument at call site instead. So in R, a macro is just a function. And yes, it's easy to break stuff that way. Just as easy as it is with macros (esp. non-hygienic ones).
> Lisps do that distinction because they need it. Because of much better performance and predictability of code. See: http://www.nhplace.com/kent/Papers/Special-Forms.html