JC, Are you going to call this new abbreviated language by the name "Q" or keep calling itby the name "R" as "S" is taken? As a goal, yes, it is easier to maintain a language that is sparse. It may sort of force programmers to go in particular ways to do things and those ways could be very reliable. But it will drive many programmers away from the language as it will often not match their way of thinking about problems. You can presumably build a brand new language with design goals. As you note, existing languages come with a millstone around their necks or an albatross. R is an extendable language. You can look at many of the packages or even packages of packages such as the tidyverse as examples of adding on functionality to do things other ways that have caught on. Some even partially supplant use of perfectly usable base R methods. Many end up being largely rewritten as libraries in another language such as a version of C to speed them up. So I suspect limiting R from doing things multiple ways would encourage making more other ways and ignoring the base language. But different ways of doing things is not just based on command names but on techniques within programming. Anyone who wants to can do a matrix multiplication using a direct primitive but also by a nested loop and other ways. There is nothing wrong with allowing more ways. Yes, there is a huge problem with teaching too much and with reading code others wrote. But I suggest that there have been languages that tried to make you use relatively pure functional programming methods to solve everything. Others try to make you use object-oriented techniques. Obviously some older ones only allow procedural methods and some remain in the GOTO stage. Modern languages often seem to feel obligated to support multiple modes but then sometimes skimp on other things. R had a focus and it left out some things while a language like Python had another focus and included many things R left out while totallyignoring many it has. BOTH languages have later been extended through packages and modules because someone WANTED the darn features. People like having concepts they can use like sets and dictionaries, not just lists and vectors. They like having the ability to delay evaluation but also to force evaluation and so on. If you do not include some things in the language for purist reasons, you may find it used anyway and probably less reliably as various volunteers supply the need. Python just added versions of a PIPE. That opens up all kinds of new ways to do almost anything. In the process, they already mucked with a new way to create an anonymous function, and are now planning to add a new use for a single underscore as a placeholder. But a significant number of R users already steadily use the various kinds of pipes written before using various methods and that can break in many cases. Is it wiser to let a large user body rebel, or consider a built-in and efficient way to give them that feature? What I wonder is that now that we have a pipe in R, will any of the other ways wither away and use it internally or is it already too late and we are stuck now with even more incompatible ways to do about the same thing?
-----Original Message----- From: J C Nash <profjcn...@gmail.com> To: Reece Goding <reece.god...@outlook.com>; r-devel@r-project.org <r-devel@r-project.org> Sent: Tue, Apr 12, 2022 10:17 am Subject: Re: [Rd] I've written a big review of R. Can I get some feedback? Any large community-based project is going to be driven by the willing volunteers. Duncan Murdoch has pointed this out a long time ago for R. Those who do are those who define what is done. That said, I've felt for quite a long time that the multiplicity of ways in which R can do the same tasks lead to confusion and errors. Arguably, a much stricter language definition that could execute 95% of the existing user R scripts and programs would be welcome and provide a tool that is easier to maintain and, with a great deal of luck, lead to better maintainability of user codes. And, as others have pointed out, backward compatibility is a millstone. Whether anything will happen depends on who steps up to participate in R. In the meantime, I believe it is important for all R users to report and try to fix those things that are egregious faults, and documentation fixes are a very good starting point. John Nash On 2022-04-09 15:52, Reece Goding wrote: > Hello, > > For a while, I've been working on writing a very big review of R. I've > finally finished my final proofread of it. Can I get some feedback? This > seems the most appropriate place to ask. It's linked below. > > https://github.com/ReeceGoding/Frustration-One-Year-With-R > > If you think you've seen it before, that will be because it found some > popularity on Hacker News before I was done proofreading it. The reception > seems largely positive so far. > > Thanks, > Reece Goding > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
