The problem is finally solved, first by brute force, later by cheating.

Turns out that lockEnvironment() only prevents adding new variables to an environment, it doesn't prevent the whole environment from being deleted. Thankfully I didn't have to spend too long experimenting before I found that out.

The first solution was to copy and paste the fragment of code from my reset_tests() function that set common paths from environment variables into the main test driver program. It's dumb and hacky but it got me enough info to change back to the proper directory and source() reset_tests.R.

I was afraid I'd have to do that for the last 5 tests because they all called the routine that was wiping memory. Oddly, the problem didn't occur during the remaining tests. I looked more closely at the problem routine and found it only wiped memory when one particular test/feature was called. That explained why the other tests weren't affected. It also turned out that I had modified the original routine to exempt half a dozen variables from being wiped so I exempted a few more which were set in the test routine which fixed the problem more gracefully. This came at the cost of modifying the application source and, worse, made the test dependent on the application knowing about a variable that is not set anywhere in the application. The application is riddled with test-aware code, exhibiting different behavior when it knows its being tested. This is still a huge red flag to me but at this point I'm familiar enough with the code that I can see the test-aware code is benign, plus I now view R itself as a huge red flag. Test-aware code is the least of my problems with this application.

This isn't really fair because a careful R programmer could have made this application into an R package and used the TestThat library for writing proper unit tests (testthat.r-lib.org/). At that point code installation, testing, and configuration management are all greatly simplified so R could be made to work responsibly in our environment. The code would still be a mass of unstructured globals but operationally it would be much better, certainly no worse than it is right now.

And in fact I tried doing this to the code with limited success. Following the guidance in r-pkgs.org/ I was able to migrate most of the code into a package and add the global variables to the function interfaces, effectively de-globalizing them. It made functions clearer - you could now see everything they depended on and what they were changing - and it avoided the maintenance and reliability problem of changing global variables all over the code. That's Software Development 101, something that the authors of the popular texts on R completely and intentionally blow off (at least the author of The Art of R Programming shrugs off the problem very directly; "It'll be FIIIIINE...")

When you have a programmer culture that rejects fundamentals like this, it's no surprise I see code this bad and dangerous.

Before I go off on a long aside, the reason I couldn't fully convert this application to a package and a simple driver was the use of an override to the list() function that I cannot understand. It's written in low-level R and does some sort of functional programming data munging for applying a function to elements of a data structure. This one function broke me; it's clearly copied from some other program as a clever hack. The style of the code is too different from the rest of the application, it doesn't follow the code's naming convention, and is much more sophisticated and low level than anything else in the code. There is some serious "code smell" that this function is doing something that shouldnt be done, either because it's too tedious to restructure the application to use standard language features or the application author couldn't be arsed to learn how to solve this problem the right way. Either way, I was 80% of the way to converting this code to a bona fide R library and was stopped by this one alien function I couldn't understand, package, or refactor away. Frustrating.

But back to my aside on language culture and bad code.

Unit Testing for R

Software testing is important, but, in part because it is frustrating and boring, many of us avoid it. testthat is a testing framework for R that is easy to learn and use, and integrates with your existing workflow.

^{testthat.r-lib.org}

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