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.
______________________________________________
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.
