Title — In Search of Types Author — Stephen Kell Abstract The concept of “type” has been used without a consistent, precise definition in discussions about programming languages for 60 years. In this essay I explore various concepts lurking behind distinct uses of this word, highlighting two traditions in which the word came into use largely independently: engineering traditions on the one hand, and those of symbolic logic on the other. These traditions are founded on differing attitudes to the nature and purpose of abstraction, but their distinct uses of “type” have never been explicitly unified. One result is that discourse across these traditions often finds itself at cross purposes, such as overapplying one sense of “type” where another is appropriate, and occasionally proceeding to draw wrong conclusions. I illustrate this with examples from well-known and justly well-regarded literature, and argue that ongoing developments in both the theory and practice of programming make now a good time to resolve these problems. What I Like Kell is a very salient writer and thinker and this paper in particular helped disambiguate the notions of “type” in a way that’s been useful for my thinking. He first breaks out “data types” from “type disciplines” and explores the essential properties of both, I find this two-part distinction useful, but his deconstruction of “data types” in particular was insightful and I highly recommend at least skimming through that section for anyone working on programming systems.

One thing I particularly appreciate about this paper (thank you for pointing me at it!) is the resuscitation (in Section 3) of the old notion of change-proneness. I'd somehow missed this rationale for our modern software engineering mileu, obsessed with libraries, commandline flags and configuration languages. Even though I've been reading the literature for decades, I came to it decades after the reasons had gotten enshrined and taken for granted: • Changes to software are costly • Therefore make software less change-prone • Hence SOLID, encapsulation, etc., etc. It's worth revisiting this argument, though. We've now had decades demonstrating that software never stops changing. Avoiding changes feels increasingly like a fool's errand. Also, once you have to make some change, we have lots of practices for reducing the cost of changes: tests, version control, CI. Is it really worth putting change-proneness on the pedestal we do, to the extent that all our best practice is focused on a risk we already have decent ways to mitigate? Perhaps it's time to just change the code (https://catern.com/change_code.html)

Yeah I really quite enjoyed the article in a way I didn’t expect to. I like the distinction between the various kinds of types and enjoy the de-emphasis on the static vs dynamic nature. I did like the discussion about abstraction, but found it a bit disjointed. Maybe I wanted too much out the discussion, because abstraction is a big interest of mine. What I did like was his calling out that a failure to “protect” and abstraction doesn't mean there is none. But I think this should lead us to the bigger conclusion, abstraction is not about data/information hiding. A linked list in C is an abstraction, but nothing need be hidden, there can just be direct pointers. I could go on about abstraction, but I will leave it to just one more thing. I think his Parma's quote about “levels of abstraction” being an “abuse of language” isn’t quite correct either. To my thinking there is a clear hierarchy to abstractness (really I’d say a partial order). I think to deny that is to change subjects. But that hierarchy isn’t a universal one, it is relative to a base. Functions in the lambda calculus are not an abstraction. Functions in java are an abstraction. Regardless, really interesting paper very happy to have read it. @Kartik Agaram I completely agree with your “just change the code” view. You are right to point out that software is always changing. I’d actually take an even stronger stance. 1. Software is always changing and trying to completely predict in which ways it will change is a fools errand. 2. SOLID, encaspulation, etc require you to predict which ways software will change 3. Making the wrong predictions makes your code harder to change on certain axes 4. Therefore these practices are net negatives This is an argument that I think is very hard to make, because like many of the arguments I want to make, it sounds like I’m just advocating for anarchy. But I think there is a real difference. I am not suggestion code have no structure, no design. I just think the designs we can easily give names to and easily tell others to copy are generally not the good ones. Design in contextual to the tasks, goals, environment, etc. There is no playbook, only taste.