Published: September 20, 2020
As a programmer, we're accustomed to learning about "coding" and maybe even "refactoring." However, how often do we learn about deleting things? I mean, delete something already! That beloved feature... gone!
Thus, being somewhat motivated by a large bit of writers block, some dumb curiosity, and being couped up in the house during the pandemic, I decided to undertake a code deletion challenge. I decided to pick on something that I've used a lot--the Python interpreter. I would also loosely style my challenge after 100 days of code where there would be a few basic rules:
Rule 2 forces you to read and understand someone else's code base. Although I've used Python a lot, I am not a core developer. I have written no part of it.
Rule 3 is open to some interpretation. "Operational" doesn't mean backwards compatible. It's just meant to keep you honest--any fool can delete a bunch of random things if the code doesn't have to run afterwards. For, my project, there was a minimum requirement of being able to start Python into the REPL, run some basic programs, and import modules. Everything beyond that was negotiable. However, it might be helpful to have an end goal (see below),
Rule 4 is to up the stakes of the game. Sure, you could spend 100 days deleting single lines of code here and there. However, what would be the point of that? No, I'm talking about taking on bigger things. For example, delete Unicode or the GIL. THAT'S a challenge. Also, just to be clear, "delete" is not the same as "fix." Delete just means it's gone--as in "not present."
Deleting things is weird kind of project. Sure, you can start out by randoming deleting seemingly inconsequential features here and there. However, like coding, it might help to have some kind of "end game" in mind.
I've recently been doing a fair amount of interpreter writing in the various courses that I teach. For example, in my compilers course, we spend some amount of time writing a so-called "Definitional Interpreter" to better understand program semantics. I've also worked through the SICP metacircular evaluator project numerous times.
So, in deleting features from Python, maybe I could work my way backwards from the current Python implementation to some kind of very stripped down interpreter, similar to what would be written for a course. Perhaps it would be useful. Or maybe not. However, as a goal it seemed to be as reasonable as anything else.
Over the last year on my early morning bike rides, I passed this house that the owner had decided to dismantle piece-by-piece. I don't know if that's something they were doing themselves as a kind of side project, but slowly over a period of about six months, the siding, roof, and various walls disappeared until all that remained was a basic wood frame along with some stonework. Clearly, this had to be done in a reasonable careful way. Take out a load-bearing wall and the whole house is likely to collapse on your head. There's got to be a plan.
Deleting code is much like that. Everything is probably a lot more intertwined than you think and the dependencies can be complex and non-obvious. It might involve a lot of layers ranging from high-level APIs to low-level operating system interfaces. Delete the wrong thing and the whole house of cards will collapse. You might need to build some temporary supports to keep everything functional. There's probably a certain intuition required to know what you can get away with deleting in the first place.
In coding, almost all of the focus is on constructing things. You think about data structures, algorithms, packages, and problem solving. Deleting something is whole different game. Do you need to understand much about the inner workings of something in order to delete it? No, you do not!
However, you DO need to understand how the thing you're deleting is connected to other things. And you will curse the words "leaky abstraction" with your fists of destruction raised high in the air. In that sense, the entire project becomes one of connections. You will learn all sorts of things about how the code is constructed, how the parts fit together, danger areas, and more. Deleting is not for the timid.
Thinking entirely about the connection between things is a dangerous game to play. One day you're deleting locales. The next month? Studying category theory. You have been warned.
You can find the results of my 100 day deletion challenge here. All told, I managed to reduce Python from 1,153,762 lines down to 181,327 lines according to results reported by sloccount. Admittedly, much of that probably came from deleting the test suite on Day 18. Nevertheless, I still managed to delete a lot of things (Unicode, packages, threads, the GIL, async, etc.).
Did I manage to turn Python into the extremely stripped down "mini-interpreter" that I'd hoped? No, I did not. However, I'm still thinking about that. Maybe I'll return to think about that another time.
In any event, a lot was learned in this adventure and I'll probably have more to say about it at a later date. In the meantime, you should ask yourself "am I up for the challenge?" If so, deleting code won't disappoint. You'll learn a lot.
[ More Bits ]Copyright (C) 2005-2024, David Beazley