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.