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