Re:Parsing R code: Freedom of expression is not always a goo...
by klrall on Tuesday June 14, 2022 @09:12AM
(#31738915)
Freedom of expression helps you think though. Lisp is helping the thoughts, other languages obstruct them (that certainly includes Python).
For a scientific language like R this quality is important.
Perhaps the ideal data science language would be a Lisp/R with excellent embedding qualities like Lua for the scientific parts. People could then choose their favorite language for shoveling data around.
Re:Parsing R code: Freedom of expression is not always a goo...
by NeutralForest on Tuesday June 14, 2022 @10:25AM
(#31740003)
Why would say Python obstructs the thought?
Re:Parsing R code: Freedom of expression is not always a goo...
by wdkrnls on Tuesday June 14, 2022 @04:46PM
(#31745832)
Because with original thinking there is more than one way to do it. Pythonic conformity might make long term maintenance easier, but it's rigidity exacts a cost on expressing new thoughts. R is basically the epitome of Greenspun's 10th rule: it's really their implementation of a common lisp that looks like C with metaprogramming and conditions and restarts and all. They tried standardizing on Common Lisp first (XLisp-Stat) but S from Bell Labs was too popular. In short, today R is a lisp with access to modern numeric libraries.
Re:Parsing R code: Freedom of expression is not always a goo...
by sshine on Tuesday June 14, 2022 @04:41PM
(#31745771)
Duck typing allows for freedom of expression/thinking.
You can declare a new property on an object simply by assigning, and consistency is not required either.
It also potentially leaves a mess over time.
Re:Parsing R code: Freedom of expression is not always a goo...
by disgruntledphd2 on Tuesday June 14, 2022 @11:08AM
(#31740610)
Python doesn't, but pandas definitely does.
As someone who occasionally writes parsers for real languages, and as someone who was really into R in university, I am happy that I stepped back on this one. ;-)
R's syntax belongs in the same category as Ruby and JavaScript:
Too much freedom of expression makes the meaning of a program highly dependent on its execution. It is hard to say concise things about a program without running it.
It is the murky side of (untyped) Lisp, if you ask me.