Maybe 15 years ago I was recovering or modernizing some legacy F77 code and out of exasperation, I asked "Who taught engineers to code this badly?"

Through the magic of used bookstores and online sellers, I picked up maybe 15-20 textbooks on Fortran from the early 60s to about 1990 (1990 was long after the codes I was dealing with were written). I was determined to find a Smoking Gun in engineering computing education that explained the code quality I was seeing.

Instead, what I found almost universally was good, solid guidance on writing numerical code and writing code in general. Even back to McCracken's classic text on Fortran, the books all advocated good practice as it was known at the time.

It was about this time I was throwing myself into legacy code recovery and modernization (failing marriage, socially isolated, stranded far from home in Chicagoland with no job prospects back here in Texas. It wasn't pretty.). What I learned from reading old code and old texts was that what I was seeing as "bad" code was more accurately "inconvenient" code. The codes generally worked without error and were written in a way that worked around constraints in memory, CPU, architecture, environment, language, and state of the art. The problem was lack of long-term maintenance; the codes were optimized for constraints that no longer existed and the original developers had moved on to other projects and hadn't been replaced. This is not "technical debt", this is simple neglect. It's understandable though because many of these codes had lasted far longer than anyone expected them to and there's a strong culture of Don't Fix It If It Ain't Broke. Eventually environmental change catches up to the code and it breaks, especially if the maintainers are subject matter experts and don't update their toolchain periodically (or ever). Fortran is a surprisingly resilient language for being almost 80 years old and it still amazes me that 50 year old code builds and runs on modern systems with very little change needed. Part of that is a culture of backward compatibility and low maintenance requirements. By and large, the legacy codes I see are written reasonably well for their era. My view on what I consider "bad" code has tempered over the past 15 years as I've done more research into the coding practices, instruction, and hardware as they have developed from the late 1950s to present. We dont generally notice the overhead of function calls today, both because we have an abundance of resources and because modern compilers are insanely good at optimization. That was not the case for a long time so when you see long (10+ page) routines in these codes, it helps to understand that there was a non-negligible cost to creating and calling functions and that there may have been limitations on the number of functions a compiler (or linker or operating system) could support. I can't tell you what it was like to program a low-end IBM 360 in 1968 - it likely involved punch cards and F66 but I don't have a feel for memory space, processor and I/O speed, tape storage, or operating environment. My first computer was a VIC-20 with slightly less than 4kB of usable RAM and cassette tape storage. I can tell you about writing code to fit into 3583 bytes, load times from cassette, and the joys of a 1MHz 8-bit processor. Put aside the nostalgia - try writing using a CP/M system today to understand limitations (I highly recommend the @rc2014 for real hardware) or use simh for emulating older mainframe or timesharing systems https://opensimh.org/). Again, this is about understanding constraints that no longer exist in modern desktop machines.

This extends to toolchains - modern IDEs and compilers make easy work of developing and debugging. There's a very practical reason why global variables fell out of favor, not for some theoretical or pedagogical reason but because they led to errors and broken code. Debugging 40 years ago was much harder and you see guidance on good practice and debugging in texts from the early 60s.

So when I see a modern popular text on R hand-wave away concerns about globals as academic, I immediately distrust the programming culture around R (and no, it's not just one book by one author; look up variable scope and environments in "R in Action".)

R is a very very useful interactive desktop tool. Think of it as bash but for statistics and data analysis. I can see its value. But as a programming language and a programming culture it's hot garbage. Languages are more fixable than culture.