Dynamic types: where is the discussion?

[Webdev_Tory]

Great points! So, what kind of problems does dynamic/loose typing NOT fit well? (since fitting anything is kind of the MO of dynamic typing)

[Webdev_Tory]

Yes, I think that is a great reminder to wrap around to the original question: what are some well-studied resources that contribute to this discussion? I think you’re right that gut-feelings are a too-common and unreliable leader in these discussions.

[mjmeintjes]

Have you seen this summary? Literature review on the benefits of static types

[seancorfield]

Took me a while to figure out the date of that article – November 2014. I think I’ve run across it a few times over the years and it certainly matches my feelings about several of the studies I’ve seen (all of which he tackles there, I believe). As noted in that article, this is not a “well-studied” field – it is just a “well-discussed” field and nearly all of the studies seem to be either flawed or inconclusive (or both).

The few comments about static analysis (without adding types to a language) ring true to me – and matches my comments about this in the thread above: static code analysis can find bugs in both dynamic and static type languages that can be hard to detect via testing (and inherently get past the type checker in the static type language case). Many people in both camps find value in linting tools of varying sophistication so this should not be a surprising observation.

[Webdev_Tory]

That is almost exactly what I was hoping for when I posted this question! Thanks for that, and for @seancorfield response remembering the date of it. The only drawback being its age, but as has been pointed out, there really hasn’t been much added to the conversation in the last decade(s). Just tides of fashion.

One thing I haven’t seen so much pointed out is the difference for beginners. My intuition is that beginning/learning developers may much prefer the dynamic typing because it alleviates one of the (at beginning stage) incidental complexities of development, but my intuition suggests that managers might wish for a static type system to reign in the presumably beginner developers they don’t trust to catch their own mistakes. I have been in that supervisor role and could understand the temptation to call for static type “babysitting” provided by a java-esque type system, knowing this babysitting is exactly what infuriated a veteran developer like Rich into defining certain features of Clojure.

[Anthony_Leonard]

On the usefulness of discussion itself … as long it’s dialectic (and not eristic) it’s useful, as the greeks knew when they named them such, and before empiricism was a thing. On the main discussion, I haven’t tried here to be equivocal about the benefits of static types, but to talk about their hidden costs through a few (admittedly contrived) “facts”.

• Phone chargers suffer breaking changes, but your brain never does. This difference between “information” and “mechanism” is related to the intuition that programs with “few types, many functions” are malleable, and those with many types, few functions are brittle. Brittleness is a big problem for those who pay us as they expect software to act like humans and grow and adapt to their needs. Programming languages which idiomatically encourage the creation of many new types as a selling point, will suffer death by specificity and will be brittle in a manner we created for ourselves, and not essential to the problem.

• There are many types of types. Martin Odersky found the need to project through whole static typing landscapes to hit upon those idioms most useful for the programmer, some of which have found their way into Typescript too. And yet Java designer Joshua Bloch felt that the relatively familiar java generics failed to preserve “Java as a blue-collar language, not PhD material but a language for a job”. I have a PhD and love a challenge, but agree that figuring out the right type system from the many options can be its own parallel puzzle, more distracting than beneficial to solving the original problem.

• TypeScript [may not be] fully coexpressive with idiomatic JavaScript. This was a view expressed in The Typescript Tax that chimed with my experience. In Clojure It’s common to pipeline a map through functions like (defn add-z [{:keys [x y]} :as m] (assoc m :z (zfn x y)), essentially adding new information to a map based on that already in the map using some zfn. It took me ages to work out this has no idiomatic equivalent in Java, requiring as it does intersection types on both the input and the return type, with a “pseudo-code type signature” of type add-z = (x & y) -> (x & y & z). In other words, with all those type options available, there were useful approaches you simply couldn’t express in a fully typed way, making conscientious developers think must be missing something.

Some final thoughts on this. Firstly Uncle Bob (entertainingly as ever) reminds us that the debate started decades ago, face-to-face in offices, by men (mostly) wearing ties. Secondly, Rich Hickey, when asked about Typescript relatively recently, reminds us that static vs dynamic typing is probably not the biggest thing - that being state management in imperative coding. I guess it’s obvious that I am won over by Rich’s reasoning around the costs of static types and encourage anyone looking for discussion to simply study his talks. I’ll leave the last word though to Mark Bastian who gets to the heart of designing “data first” over “api first” and poses the question “why are you doing this” of the latter.