On doing things with SQL commands, well THERE is a language that has grown and changed a lot. And a language in which obviously equivalent things aren’t because of SQL’s inconsistent three-valued logic. With a really big standard and a dizzying array of implementations that fail to conform in oh so many different ways.
You can indeed do a lot in SQL and it copes with huge volumes of data much better than R. Ross Ihaka was saying 20 years ago that there needed to be something that scaled better than R and handled complex analyses better than SQL. Something that integrates visualisation well would be good too. Can I praise the core R developers for adding namespaces? We couldn’t have so many packages, making R so useful in so many areas, without them. Whenever I feel a need for Pascal or Modula2 I reach for Ada instead, but noth are still around. On Mon, 16 Jun 2025 at 1:31 PM, <avi.e.gr...@gmail.com> wrote: > I did not intend to segue into the fates of other languages except insofar > as R is like many others that can be evolving while both attracting new > "clients" and uses and shedding others including g some who decide some > other language may suit them best. > > I am happy to hear versions of PASCAL are still around and note the early > versions had a bit of a purpose as Niklaus Wirth was looking for a language > that had certain properties he felt were lacking in other languages. The > language began as rather barebones and it was not necessarily easy to do > much with it as it did not allow all kinds of useful things. Ideally, you > could more easily debug and "prove" a program worked and other such goals. > For a while, I worked for a company during grad school in Wisconsin on a > sort of automation system for factories where we used OMSI PASCAL to write > many functions in clusters that could be overlaid on top of the same > regions, on several levels, as needed, so they had to compile to about the > same size as their peers. It was weird and I suspect not the ideal choice. > > These days, with lots of memory and networking built into many languages, > You might simply create a bunch of objects and initialize them and let them > loose. PASCAL was the sexy language for a time but as Wirth then moved on > to Modula, and endless other languages including compiled ones, have come > along, I have wondered if any new development resulted, other than from > people who learned one language in school and thus keep using it. > > R itself may fit into an awkward category where it may have more people > gravitating to other solutions. An amazing amount of what R is often used > for can be done by embedding some SQL commands into any language that > provides a wrapper for dealing with a database. And languages like python > have been adding more support to handle some R functionality such as the > modules of numpy and pandas when added to Python as the base language uses > flexible lists and had no concept of vectors or data.frames but does have > all kinds of neat things that R has not added, except for the ones in > packages I suspect few use. > > As noted several times, if many languages sort of converge by adding > features from other languages till they are a bit alike, then the winners > may be the ones taught the most. Arguably, Python is now ahead for one > group of interpreted languages and there are quite a few others coming > along to compete with the C language group, such as RUST and Go and way > more languages than anyone might ever want or need. As the OP said, he > wonders if R has issues that make it hard for people to feel comfortable > using it. I suggest he has not looked much at the alternatives to see they > are all heading the same way, in that they may call all the add-ons modules > or crates instead of packages and share the same growth pains. > > So, if R is otherwise a decent fit for their needs, I suggest using it, > with some precautions, as there is not much out there that is not on the > same trend. But note if the lifetime of a project is very long, whatever > choice you make may not be well supported some day. > > -----Original Message----- > From: J C Nash <profjcn...@gmail.com> > Sent: Sunday, June 15, 2025 9:20 AM > To: avi.e.gr...@gmail.com; 'Richard O'Keefe' <rao...@gmail.com> > Cc: r-help@r-project.org; 'Small Investor' <small.inves...@aol.com> > Subject: Re: [R] Some general comments -- Pascal > > Pascal is still used, though sometimes under slightly different names. An > actively maintained > piece of software I use extensively is Double Commander. This is built > using Free Pascal, which > will (at last try) run my 1989 "Compact Numerical Methods" codes. If you > use optim(), you are > using my "BFGS" (I call it Variable Metric), CG and Nelder-Mead. Brian > Ripley asked me in 1995 > if he could p2c these for R. > > But generally, "old" codes can be difficult to run. I've found quite > ancient Fortran can be > run fairly easily on Linux as long as there's not too much input-output. > That seems to be > a big obstacle as storage / streaming have changed over the years. > > John Nash > > > On 2025-06-15 01:18, avi.e.gr...@gmail.com wrote: > > Richard, > > > > You remind me of my excursions over the years into many languages, > including some that may be extinct. Is PASCAL used anywhere, for example? I > wrote lots of code in it once. Others that I know are around have morphed > as in variations of LISP. I was amused to hear from a friend that he is > playing with PROLOG as it is useful in a limited domain. Will COBOL be > around to cause anxiety in year 3K? > > > > I looked up F, just for fun, and was amused at the overload as there are > very different languages with names like F# and F*. I used Fortran in the > seventies and even taught it in the very early eighties but have never had > any reason to use it since except indirectly as other languages like R or > Python may quietly attach Fortran-based libraries. > > > > Yet, it does indeed persist in newer iterations. I have not even > considered looking at my old C programs to see if I could compile them as I > was an early switcher to C++ and have tried other C variants. I stopped > using PERL long before it made major changes except indirectly by invoking > the PERL-compatible versions/extensions to regular expressions available > in other languages. > > > > Back on topic, I hear the frustration about how complex a language (and > especially extensions) in R have become and part of the cost is that people > are trying to do more and more within it. R was not necessarily intended to > be a general purpose programming language or a scripting language or a > fully-object-oriented-language and so on. Some here will correct me, but it > began as a statistical language of sorts including a major focus on vectors > and matrices albeit in some ways the data.frame features and newer versions > have somewhat come to dominate as well as graphics. > > > > Obviously, part of the problem is the fact that open-source software > with lots of volunteers can keep expanding without much control. The people > maintaining the core language try to keep it somewhat small and nimble. > But, I could imagine someone taking that base and adding lots of stuff > (such as the entire tidyverse and more) so the new base would be very large > and you did not need to use the install.package/library functions as much. > Such a bloated language version might work better for people writing > production code where they want more stability and control over changes. > Ideally each new update would include serious testing of all internal > modules and how they work together. As mentioned, some changes like adding > a built-in pipe result in people who like pipes and do not even use the > tidyverse, not having to include some package just to get one of the older > external pipes. > > > > What I was talking about is that a new language might realize the > usefulness of some such features and make them not just a part of the core > language but have it seamlessly be seen as part of the command structure. > As a contrast, Python has a sort of variant of piping in terms of being > able to connect a series of function calls together using member functions > of objects as in object.method1(something).method2(something), … > > > > But the above works best if you know that each function call will always > return an object of the right type or subtype so that further methods > invoked are available. The R pipe method is in some sense better as all it > does is pass the previous result, of any class, as the first, or specified > argument to the next function. A new language based on R, might have most > things be more fully fledged objects as in S7 or something newer, and allow > both kinds of pipelining. > > > > One advantage (and disadvantage) of starting anew is that compatibility > with old code can be dropped. As, again, one example, lots of current R > functions were never designed to take the appropriate argument as a first > argument and perhaps had it as a second one or even an optional named > argument. A new system might be designed from the ground up to have more > function argument list done such that the first argument is the obvious one > used in pipelining, or perhaps a new hack where when you declare a > function, you can specify which argument is to be the default one replaced > when used in a pipe situation. Or, it might supply two or more versions of > the function that are almost identical except that they take arguments in a > different order. > > > > If done right, a new language might not catch on easily with the > existing user base but might become used more by new projects. > > > > I have to speculate on a side issue regarding AI. Instead of training a > general-purpose AI using internet resources such as stack-overflow posts > where people ask how to do something or why something is not working, a new > language might be trained by having documentation written that includes > many how-to parameterized scenarios it could learn from for many common and > expected uses. A well designed and tight language with (initially) fewer > complications, might work better. It may start with say ONE kind of > data.frame that includes many of the features you currently get from > tibbles and data.tables as options. > > > > And, of course, I am a fan of making a language that can incorporate > other languages as needed to do focused tasks well done by others and > integrate it. Way back in my UNIX days, I often wrote fairly complex > applications largely written as shell scripts that called on various > programs like the UNIX utilities such as grep and sed and AWK as well as > PERL and others and over time, features were added to versions like ksh > that allowed lots to be done internally within the shell script that speed > up many things. The UNIX pipelines helped make fairly complex things seem > almost routine to write this way. A new language, perhaps somewhat based on > R, might do well if it did not do everything but allowed co-processes to be > invoked as needed. I have written such programs in RSTUDIO and other places > that allow integration of sorts between Python and R to work on the same > data in memory and do some translating back and forth. R itself, spends > some time translating R data structures to ones some version of C can > expect and then call a fast C routine to do some work and then translate > the results back. > > > > Sorry for the length of my thoughts. I will stop here. > > > > From: Richard O'Keefe <rao...@gmail.com> > > Sent: Saturday, June 14, 2025 7:15 PM > > To: avi.e.gr...@gmail.com > > Cc: Small Investor <small.inves...@aol.com>; r-help@r-project.org > > Subject: Re: [R] Some general comments > > > > Avi Gross asked “i often wonder what would happen if someone took a > language that was decades old…”. Welcome to F. F is basically modern > Fortran without the cruftier old bits. > > > > I note that I have some software written in the 1980s in C which no > modern C compiler will accept (not my code, although I maintained it for a > while) and I stopped using C++ because of version to version breakage. > PERL 6 was so very different from PERL 5 that they stopped pretending it > was PERL. > > > > The fundamenal problem is that the rest of the world doesn’t stay put. > “The last Windows” will be replaced in October by windows 11 and Windows 12 > (which may but probably won’t fix some of the worse issues with 11) is on > the horizon. R was born when nobody would have dreamed of trying to run it > on a phone. We used to use 8 bit character sets, the unicode rescued us > from the 4-byte character set threatened by ISO, offering us a 2-byte > practical alternative (see Java) and then Iso 10646 and Unicode merged and > we ended up with 21-bit characters, the defined subset of which is > constantly growing, and features are introduced, deprecated, and > resurrected. 32-bit machines are superseded by 64-bit machines, and then > we find credit-card size 32-bit machines we’d like to use. Suddenly we > have “AI” everywhere, writing clean highly plausible and dangerously wrong > code. How long before someone starts asking for voice driven AI support in > R. (I wish I was joking.). And don’t get me started on the current Xorg > issue. > > > > I do share the OP’s concerns; I just don’t see any other system doing > substantially better, especially open source ones. > > > > One thing that I would find helpful is that when a function is dropped > from core R, the documentation page should explain how to convert uses of > the defunct function to the newer form, or at least point to such > documentation. This doesn’t always happen. > > > > As for splitting into different library/universe “dialects”, the only > way to avoid that is to stop people using the language. Ever looked at > Jacascript? One language I occasionally use has at least three > incompatible unit testing frameworks. > > > > On Sat, 14 Jun 2025 at 9:25 AM, <avi.e.gr...@gmail.com <mailto: > avi.e.gr...@gmail.com> > wrote: > > I would add to what Jeff replied. Many and perhaps most or even all > > languages that have room for evolution, including Python, can end up > getting > > more and more complex with multiple ways to do things but it generally is > > possible to write many useful programs in the core language. > > > > I often wonder what would happen if someone took a language that was > decades > > old, and examined a recent version and used the results to create a new > > streamlined language in which many choices are simply removed and some > newer > > ones are used instead. Consider the endless number of ways you can now do > > formatted printing in python including various versions of strings. In R, > > some of the ideas have been made available in the glue package in the > > tidyverse which many people do not know about and others use instead of > much > > of what is available in basic R. > > > > I think having choices is great for programmers but as noted, makes it > > harder when hiring people to see if they fit. But, IMNSHO, any programmer > > you hire that is not able to rapidly get on board and read manual pages > or > > sections of books showing how to use features, may not be the best hire. > I > > know I have been hired in situations where my experience was of different > > operating systems, programming languages and editors/environments and > > switching was not hard because I had a flexible background. Over years, > we > > kept shifting and I kept up while some others who knew ONE THING were > often > > struggling. > > > > The reality is that R was written so long ago that it would rapidly have > > been less and less attractive to some programmers if it stood still. > Some of > > the concerns mentioned are reasonable and some have solutions such as > taking > > a snapshot of what versions of things you allow to be used that form a > > stable environment and then not updating anything. A new machine would > > download just the copies needed, as long as the version remained > archived. > > > > But is R as bad as Python which split in ways that made many 2.x programs > > incompatible with 3.x and yet some people continue to use the old > version, > > which is a bit souped up to emulate, rather than changing the code to be > > compatible? Nobody forces you to use dplyr and frankly, it has similar > > issues as the tidyverse once built has been changed often enough so my > older > > programs often tell me functionality has been, or will soon be, made > > obsolete and the newer stuff may be much more powerful and yet a pain to > use > > for simple things as they allow ever more abstractions. > > > > I will say that it may happen to R too and a new language named P may be > > offered alongside R that will become more difficult within a year. > > > > But had this happened, R would not have things like a built-in pipe that > > some find useful or even essential. > > > > -----Original Message----- > > From: R-help <r-help-boun...@r-project.org <mailto: > r-help-boun...@r-project.org> > On Behalf Of Small Investor via > > R-help > > Sent: Friday, June 13, 2025 7:50 AM > > To: r-help@r-project.org <mailto:r-help@r-project.org> > > Subject: [R] Some general comments > > > > Dear R community, > > I have been using R for over 15 years. I want to raise an issue which has > > been haunting me for some time now: It feels as if R is falling apart. I > try > > to justify this feeling by providing three discussion points: > > 1. Version compatibility issues seem to be on the rise. Very often, you > get > > the message that package x was built on R version y (and thus, won't > work in > > your version of R). When you update to the latest version of R, you > realize > > that not all packages are available for that version. It seems that for > each > > version, only a (non-predictable) subset of packages is available. > > 2. The overhead of installing new packages seems to be on the rise. It > seems > > that the packages depend on more and more other packages. The more > packages > > you have in the 'foundations' of package x, the more likely it is that > one > > of these causes an error and the whole stack fails. Installing used to be > > easy back in the day: You got a 20 lines' output. Now you get endless > > prints. I may be mistaken but some packages seem to require admin rights > on > > your computer which you don't often have on your work PC. > > 3. R seems to be developing into different dialects. You have dplyr and > > tidyr, some people prefer data frames, some prefer tibbles. Some people > use > > pipes, some use traditional syntax. Some prefer object-oriented programs, > > some prefer procedural scripts. If you put in a job announcement that > > somebody has to know R, it doesn't mean the same thing for different > people. > > If you compare the use experience of R in 2025 to that of Matlab, the > > difference is striking: Matlab is concise and clear, R is more and more > > about endless prints. Of course, Matlab is a commerical product, but R > used > > to be the same way. I don't know if many other people feel the same way, > but > > I think I am shifting away from R. > > yours best,a data analyst dude > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-help@r-project.org <mailto:R-help@r-project.org> mailing list -- To > UNSUBSCRIBE and more, see > > https://stat.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide > > https://www.R-project.org/posting-guide.html > > and provide commented, minimal, self-contained, reproducible code. > > > > ______________________________________________ > > R-help@r-project.org <mailto:R-help@r-project.org> mailing list -- To > UNSUBSCRIBE and more, see > > https://stat.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide > https://www.R-project.org/posting-guide.html > > and provide commented, minimal, self-contained, reproducible code. > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > > https://stat.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide > https://www.R-project.org/posting-guide.html > > and provide commented, minimal, self-contained, reproducible code. > > > [[alternative HTML version deleted]] ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
