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.gross at 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 <raoknz at gmail.com> > Sent: Saturday, June 14, 2025 7:15 PM > To: avi.e.gross at gmail.com > Cc: Small Investor <small.investor at aol.com>; r-help at 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.gross at gmail.com <mailto:avi.e.gross at 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-bounces at r-project.org <mailto:r-help-bounces at r-project.org> > On Behalf Of Small Investor via > R-help > Sent: Friday, June 13, 2025 7:50 AM > To: r-help at r-project.org <mailto:r-help at 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 at r-project.org <mailto:R-help at 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 at r-project.org <mailto:R-help at 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 at 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.
I'll add that my current favorite editor is CudaText, written in Object Pascal. (And I too am a fan of Double Commander.) ---JRG On Sunday, June 15th, 2025 at 9:19 AM, J C Nash <profjcnash at gmail.com> wrote:> > > 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.gross at 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 raoknz at gmail.com > > Sent: Saturday, June 14, 2025 7:15 PM > > To: avi.e.gross at gmail.com > > Cc: Small Investor small.investor at aol.com; r-help at 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.gross at gmail.com mailto:avi.e.gross at 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-bounces at r-project.org mailto:r-help-bounces at r-project.org > On Behalf Of Small Investor via > > R-help > > Sent: Friday, June 13, 2025 7:50 AM > > To: r-help at r-project.org mailto:r-help at 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 at r-project.org mailto:R-help at 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 at r-project.org mailto:R-help at 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 at 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 at 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.
@vi@e@gross m@iii@g oii gm@ii@com
2025-Jun-16 01:31 UTC
[R] Some general comments -- Pascal
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 <profjcnash at gmail.com> Sent: Sunday, June 15, 2025 9:20 AM To: avi.e.gross at gmail.com; 'Richard O'Keefe' <raoknz at gmail.com> Cc: r-help at r-project.org; 'Small Investor' <small.investor at 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.gross at 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 <raoknz at gmail.com> > Sent: Saturday, June 14, 2025 7:15 PM > To: avi.e.gross at gmail.com > Cc: Small Investor <small.investor at aol.com>; r-help at 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.gross at gmail.com <mailto:avi.e.gross at 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-bounces at r-project.org <mailto:r-help-bounces at r-project.org> > On Behalf Of Small Investor via > R-help > Sent: Friday, June 13, 2025 7:50 AM > To: r-help at r-project.org <mailto:r-help at 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 at r-project.org <mailto:R-help at 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 at r-project.org <mailto:R-help at 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 at 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.