4 ms·
What syntax would you like instead, for numerical programming? * Python seems not so different, but once you add numpy then it involves a lot of ugly `np.arcsi
by improbable22 9y ago
What syntax would you like instead, for numerical programming?
* Python seems not so different, but once you add numpy then it involves a lot of ugly `np.arcsin(np.sqrt([...]))` type of things.
* R looks horrifyingly ugly but I haven't written anything
Coming from Mathematica 1-based is comforting, and it also matches the way people write mathematics on paper which is nice.
- sin7 9y agoR had changed a ton in the last three years. It's pretty clean these days.
- jampekka 9y agoI mostly use Python, although it has some syntax issues too (eg. no real lambdas, I'd prefer no parenthesis for function calls etc). I don't see why that's a numpy problem. If you just do "from numpy import *" you can pollute your namespace with hundreds of symbols, just like eg. MATLAB. R not just looks ugly, but is quite horrible in the inside too. For example the variable scoping is one of the most insane I have ever seen. But in general, I think having special purpose languages is mostly a bad idea. Firstly, having domain specific languages isolate different fields of science: If engineers use MATLAB and statisticians use R, the transfer of progress between these fields is hindered. Secondly, almost all special purpose languages for scientific stuff encourage horrible programming practices. Which typically leads to practice in the field lagging years or even decades behind scientific advances, because usable implementations are quite scarce, or tied to a domain-specific language.
- noobhacker 9y agoCould you clarify what's insane about the variable scoping in R? I'm a bit too close to R so I'm afraid I'm oblivious.
- sin7 9y agoI use a lot of R. The thing that drives me insane is when you create a function such as multxy <- function (x){x * y}, then you call multxy(6) R will not return an error as long as y is in the parent environment. That's pretty insane.
- icebraining 9y agoI don't use R, so I thought you were referring to dynamic scoping, which I do think it's horrifying. But it seems R uses lexical scoping - that is, the y is captured at function definition time. That's extremely common and quite useful, in my opinion.
- jampekka 9y agoR uses a "sort of" lexical scoping which causes some "interesting" things. Eg a symbol may be simultaneously in global and local scope within the same function, which can be (ab)used to create a variable that's randomly scoped[0]. I'd say this is sort of a "dynamically lexical scope". [0] http://andrewgelman.com/2014/01/29/stupid-r-tricks-random-scope/ http://andrewgelman.com/2014/01/29/stupid-r-tricks-random-sc...
- icebraining 9y agoAh, fair enough, that's definitively weird.
- kazinator 9y agoThe article is not convicing me that the language is obeying any poorly designed requirements. The function f contains a free reference to a variable called a. This is satisfied in some sort of global environment. Later, f is called from a function in which there is a local a bound to 100. Of course, this a which is local to that function is invisible to the free reference in f which continues to refers to the global a that contains 10. It could be there is some problem in R, but whatever that is, this article isn't exposing it in a convincing way. Same thing in Common Lisp (using CLISP): [1]> (defun f (x) (* a x)) F [2]> (setf a 10) 10 [3]> (f 3) 30 [4]> (defun g (y) (let ((a 100)) (f y))) G [5]> (g 3) 30 The surprise is supposed to be that `(g 3)` doesn't produce 100. Why should it? (It could produce 100 if the symbol a were marked for binding as a special variable; but it isn't. Thus it's just a free variable in f resolved in the global environment, and a lexical binding in g).