Dynamic type systems are not inherently more open

Six notable things I took away from this post:<p>- Structural typing, i.e. instead of &quot;you eagerly write a schema for the whole universe&quot;, just limit to what you need (basically, encode only the same kinds of assumptions you would make in a dynamically-typed language).<p>- <i>It’s easy to discover the assumptions of the Haskell program [...] In the dynamically-typed program, we’d have to audit every code path</i> — Left implicit in many debates about these topics are the &quot;weights&quot; that one attaches to these things, the importance and frequency of attempting such activities. Surely they vary, depending on everything from the application (Is it &quot;code once and throw it away&quot;, or does it need to be maintained when the original programmers have left?) and down to the individual programmer&#x27;s approach to life (What is the cost of an error: how bad would it be to have a bug? Etc).<p>- <i>&quot;This is a case of improper data modeling, but the static type system is not at fault—it has simply been misused.&quot;</i> — To me this shows that bugs can exist in either the data modeling or the code: in a dynamically-typed language the two tend to coincide (with much less of the former) and in a statically-typed language they tend to be separate. (Is this good or bad? On the one hand you can think about them separately, on the other hand you have to look for bugs in two places &#x2F; switch between two modes of thought, but then again maybe you need to do that anyway?)<p>- Structural versus nominal typing, where the latter involves giving a name to each new type (<i>&quot;If you wish to take a subselection of a struct’s fields, you must define an entirely new struct; doing this often creates an explosion of awkward boilerplate&quot;</i>).<p>- <i>&quot;consider Python classes, which are quite nominal despite being dynamic, and TypeScript interfaces, which are structural despite being static.&quot;</i> — This is highly illuminating, and just this bit (and the next) elaborated with some examples would make for a useful blog post on its own.<p>- <i>&quot;If you are interested in exploring static type systems with strong support for structural typing, I would recommend taking a look at any of TypeScript, Flow, PureScript, Elm, OCaml, or Reason [...] What I would</i> not <i>recommend for this purpose is Haskell, which [is] aggressively nominal&quot;</i><p>For what it&#x27;s worth, my opinion is that posts like this, on hotly debated topics, would do well to start with concrete examples and be written in the mode of conveying interesting information&#x2F;ideas (of which there are a lot here) rather than being phrased as an argument for some position, which seems to elicit different sorts of responses — already most of the HN comments here are about static versus dynamic type systems in general, rather than about any specific ideas advanced by this post.

I think there&#x27;s a perhaps irreconcilable disconnect between 2 camps here, but I also think that&#x27;s ok and different people are allowed to like different things.<p>My experience, having gone from dynamic typing to static typing and now pining for more expressive type features in my chosen language is that static typing changes where you have to spend the cognitive complexity budget.<p>To my mind if I return to a piece of dynamically typed code written any time other than in the same session I have to load a whole mental model of the entire code, what types all the variables are, what expectations are attached to them, what mutation, if any, each method call performs. I suppose the trade-off is that advocates say you can prototype things more easily when requirements are not known.<p>With static typing I only need to load 2 things, the high level goal, what I need to achieve, and the local context where I need to make the change. The rest is taken care of by static typing, I can encode all that cognitive complexity in the types and I never need to think about it again. But as I say, that&#x27;s how my brain works, yours might work differently and that&#x27;s fine.

I&#x27;ve come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn&#x27;t always &quot;as soon as possible&quot;. Let me illustrate, say you&#x27;re adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out the feature. Then while testing out the feature you decide that it was a bad idea after all or that the feature should be implemented completely differently. So you scrap the implementation. In this case fixing those bugs was a waste of time. Dynamic typing allows you to postpone fixing those bugs after you&#x27;re more certain that the feature and its implementation will stay.

This &quot;be liberal in what you accept&quot; idea, applied to modern programming, always struck me as strange.<p>Yes, taking an unknown structure in your program is the easy part. Programming against an unknown structure is where the problem lies.<p>I&#x27;d love to hear more examples of programming against such input that are beneficial over &quot;parse don&#x27;t validate&quot; idea.

I have developed and maintained several large systems in both dynamic and statically typed languages.<p>From a maintenance point of view, the statically typed ones definitely win out.<p>Trying to reason about bits of code with no idea what was supposed to be passed in. Working out which bits of code are actually dead and can be safely removed. Refactoring bits of code. All incredibly difficult in the dynamically typed systems.<p>Given the choice, I would not embark on a large complex system without the benefit of a strongly typed language.

Dynamic type systems are inherently more open.<p>This article really bends over in strange ways to say otherwise.<p>Fact is: dynamic typing is all about making fewer claims in your code about what you expect about the world around you. With dynamic types, to load a property you might just have to say the property name and receiver. With static types, you usually also have to say the type of all other properties of the receiver (usually by calling out the receiver’s nominal type). Hence as systems experience evolution, the probability that the dynamic property lookup will fail due to something changing is lower than the probability of the static lookup failing.<p>The heading “you can’t process what you don’t know” is particularly confused. You totally can and dynamic typing is all about doing that. In the dynamic typing case, you can process “o.f” without knowing the type of “o.g” or even the full type of “o.f” (only have to know about the type of o.f enough to know what you can do to it). Static type systems will typically require you to state the full type of o. So, this is an example of dynamic types being a tool that enables you to process what you don’t know.

Disclosure: dynamic typer here.<p>The way I understand it, a part of the issue is about possibly deferring the time at which the type of data is known to the time at which the data is operated upon, since calling a numeric addition function on not-numbers, e.g. strings, is a type violation, no matter which programming language you are writing in. The question is where you want your parsing-or-validating to occur, since this decision makes piece of the software either more tightly coupled or more heterogenous in which kinds of data they accept. The author makes and proves a claim that this decision, which is naturally postponable in JS due to its highly dynamic and schemaless-by-default object nature, is similarly postponable in Haskell.<p>The other part about ignoring unknown keywords is very simple and understandable to me - you can indeed allow a statically typed program to ignore unknown schema keywords as you can allow a dynamically typed one to error on them.

Having moved from Python to C# I&#x27;m still coming to terms with how I feel.<p>It&#x27;s really hard to express but I do have a nagging feeling that something has been lost that other commentators haven&#x27;t quite put into words either. You just write different code in dynamic languages - even ignoring type declarations. And in many cases it feels like better, more humane code.<p>One piece of evidence for this elusive difference is my observation that API&#x27;s in Python tend to much nicer and much less verbose (again - ignoring the obvious differences based directly on type declarations). APIs tend to feel like they were designed for usability rather than mapping directly on to library code and user be damned.<p>Is this a cultural difference or does something about static typing lead to different patterns of thought?

This have a mirror with the &quot;sql&quot;&#x2F;&quot;nosql&quot; debate. Being &quot;schemaless&quot; is supposedly a great advantage of nosql, but the thing is that sql&#x2F;relational is as schemaless as you want!<p>The only thing is that rdbms push to create a static modeling of the FINAL STORAGE that is close to be the ideal of it. But anyway, you can create&#x2F;delete&#x2F;change tables as you wish (is not impossible to see dbs withs 100&#x2F;200 tables), and SQL in fact build on the fly relations with the schema you want (SELECT field, field....).<p>Where is truly weak is that not extend the relational model to INNER values (so you can&#x27;t &quot;SELECT (SELECT chars FROM name)) but is a limitation of sql, not the relational model.<p>BTW, I think the relational model is very close to the ideal here? is nominal, is structural, you can re-model data AND types(relations), can have reflection and still see with clarity all the types you have use. What else it need to be useful??.

&quot;Nitpickers will complain that this isn’t the same as pickle.load(), since you have to pass a Class&lt;T&gt; token to choose what type of thing you want ahead of time. However, nothing is stopping you from passing Serializable.class and branching on the type later, after the object has been loaded.&quot;<p>Is that actually true in Java? It seems to me that the way that you&#x27;d implement that load() method is by using generics to inspect the class you were passed, figuring out what data it wants in what slot, and pulling that data in from the input. You <i>could</i> hold on to the input and return a dynamic proxy, and you would be able to see when someone calls a getFoo() on that proxy, but then you wouldn&#x27;t know what the type of the foo it expects is. And I don&#x27;t know whether you could even make your proxy assignable to T.

To paraphrase Churchill, “If a programmer doesn&#x27;t like dynamic typing by the time he is 20, he has no enthusiasm. If he is not static typing by the time he is 30, he has not learned from experience.”

Definitely dynamic typing is not about modeling the world. And it&#x27;s much broader than that. Static typing, strict or loose, also isn&#x27;t about modeling the world. OO design isn&#x27;t about modeling the world. These things are successful because they&#x27;re effective <i>methods for organizing code</i>. They&#x27;re about as useful for modeling the world as the Dewey Decimal System is.<p>And that&#x27;s fine! &#x27;Modeling the world&#x27; is a grandiose philosophical kind of activity and usually not something you need to do when you develop software.

I don&#x27;t think it makes much sense to compare between static and dynamic typing in general. Given the choice between static typing as in e.g. Java and dynamic typing in Python, I&#x27;d pick Python almost every time, because Java is just too verbose and the type system is kind of bad so the benefits are minimal anyway. But that&#x27;s a false dichotomy: you can have static typing without the verbosity and with more significant benefits (like no null pointer exceptions) by using something like OCaml.

Recently I worked on a project where initially we though about writing it in Rust, because why not, it seemed initially a good idea. It turned out to be a completely wrong idea. The project was a simple web API, nothing fancy, GraphQL and a SQL database. After a lot of frustrations we decided it to rewrite everything in TypeScript and did that in a week.<p>TypeScript gives you the benefit of statically typed languages with the benefit of dynamic typed languages, in the sense that you type only what you decide to type, you don&#x27;t have to type everything from the beginning, if you want to test something fast just stick and any type or simply ignore TypeScript errors and come to fix the errors later.<p>Dynamic features are also necessary, for example Rust lacks of a decent ORM, there is Diesel that is implemented with macros and breaks every time, plus is not a real ORM but rather a layer on SQL syntax, doesn&#x27;t automate nothing.<p>Also compilation time has to be considered. Rust is so slow to compile, especially when you start to have 200 dependencies, with some that include a lot of macros. That means that testing is so much slower. With dynamic languages you can even have hot reloading of your code.<p>I&#x27;m not saying that statically typed languages are stupid, there are situation where they make a lot of sense, for embedded or system programming for example I would never use node, and surely Rust will have a future in these contexts.<p>But the point is that you should use the most appropriate tool for the job, and a dynamic language is in a lot of contexts the appropriate tool.

Structural typing is extremly helpful&#x2F;practical, it lowers &quot;type-friction&quot; a lot. I have a dream that flow&#x2F;ts will be lifted up to js spec one day (yes, I know, that&#x27;s why I said &quot;dream&quot;). With this the language would be open to things like multiple dispatch a&#x27;la julia&#x2F;traits&#x2F;typeclasses and&#x2F;or pattern matching - which would (imho) place the language at the top for couple of decades. This kind of stuff is unfortunatelly outside of scope of flow&#x2F;ts as it would require runtime support, which flow&#x2F;js explicitly don&#x27;t provide (ie. stripped types makes valid js, all type-stuff happens at &quot;compile&quot; time only, without access to runtime at all).<p>But flow&#x2F;ts is major step towards practical solution, it covers something like 65% of properly typed language (properly = algebra on types, structural+nominal typing, opaque types, nullability exposed at type level, aggressive inferrence etc.)

This is a decent description of how to handle unwrapping a payload in a language with ADTs.<p>The swipe at Rich Hickey at the beginning is ill-considered, however. This is the sort of use case that clojure.spec is designed for, and it can, and does, handle validation at an equivalent level of detail.<p>You can watch him building his speaking career on the emotional appeal of specifying the types of your payloads here: <a href="https:&#x2F;&#x2F;vimeo.com&#x2F;195711510" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;195711510</a>

The <i>Manifold</i> project [1] nicely illustrates the author&#x27;s proposition regarding structural typing and static type systems. Using the Manifold library you can indeed create structural interfaces [2] in Java similar to those in TypeScript. Manifold also enables the use of structural interfaces with Maps, it&#x27;s pretty amazing.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;manifold-systems&#x2F;manifold" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;manifold-systems&#x2F;manifold</a> [2] <a href="https:&#x2F;&#x2F;github.com&#x2F;manifold-systems&#x2F;manifold&#x2F;tree&#x2F;master&#x2F;manifold-deps-parent&#x2F;manifold-ext#structural-interfaces-via-structural" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;manifold-systems&#x2F;manifold&#x2F;tree&#x2F;master&#x2F;man...</a>

Also maybe of interest: “The advantages of static typing, simply stated” <a href="https:&#x2F;&#x2F;pchiusano.github.io&#x2F;2016-09-15&#x2F;static-vs-dynamic.html" rel="nofollow">https:&#x2F;&#x2F;pchiusano.github.io&#x2F;2016-09-15&#x2F;static-vs-dynamic.htm...</a>

We are seeing a natural evolution where the size and complexity of software is making strong typing almost a necessity. Python now has a type hint system. Types can be checked with external tools but Python 4.x may (?) have that built in.<p>Ruby is also moving in the same direction, as far as I know.

Every time this comes up, I think about how the pendulum swings back and forth. For example, if we take static and dynamic type systems in a slightly larger scope, we’ve just recently moved from a static system to a dynamic system, because the static system was being mis-used by “libraries”.<p>I’m speaking of the recent move to deprecate user agent strings, and the pushing of “feature detection”.<p>It’s just human nature in the end. We’re not computer. We will never use a static spec to its full potential; we’ll break a type system wide open the moment we get to our limit of tolerance for not getting the job done.<p>We need type inference more. The computer has built the AST, why do compliers seem so incapable of traversing that tree and finding the type errors for us?

Protobufs don&#x27;t follow this model. For example, a User message type will often be defined in one place and code generated from it in multiple languages. Every server and client uses essentially the same type, modified as suitable for that language. As a result, clients are usually working with types that they don&#x27;t control and that have many more fields than they actually use.<p>Maybe clients <i>should</i> declare their own types containing just what they need and copy the data into them from the protobufs? But this does get tedious. On the other hand, in a schemaless JSON system, there is nothing statically checking that the clients and servers have compatible ideas of what a message should contain.

Seldom mentioned in type system discussions like this is the notion of <i>openness</i>. For instance, F# is one of the very few languages addressing openness where schematic structure in data can be <i>directly</i> and type-safely reflected by the type system e.g., using &quot;type providers.&quot; This general area of research is relatively untapped and, in my view, offers huge potential given weak links with conventional type system&#x2F;data bridging solutions (eg code generation). Structural types emitted from something like type providers would be a game changer.

The author doesn’t really address the issue raised in the first (longer) quoted post.<p>Given a set of reasonable requirements I think pretty much no one would claim a general-purpose language couldn’t satisfy them without too much trouble. In fact, that might be a fair definition of a general-purpose language.<p>I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as you use it in a distributed environment: the guarantees are static. They pertain only to your little binary and don’t say anything about the rest of the system.<p>People can tend to make the mistake of assuming other components in the system will continue to behave as they do on the day their own component was compiled.

I would posit that, the more specific the rules of a system, the fewer behaviours can be expressed by it.<p>When a language restricts the usage of things by the type of thing being used, it restricts the set if behaviours that can be expressed in that language.<p>You can get around this by adding more rules to specify the behaviours needed. (Boilerplate?)<p>In this way, a dynamic language permits more behaviours with less rules. It is more “expressive”.<p>This can be good and bad, some of those behaviours are probably unwanted!<p>And this is just a theory.

Nice that someone put in the time to write up arguments I&#x27;ve been having for years, or at least since JS rose in popularity.

Interesting how different the response has been, in general, to those from r&#x2F;programming.<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;eqv6yd&#x2F;no_dynamic_type_systems_are_not_inherently_more&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;eqv6yd&#x2F;no_dyna...</a>

I wrote the pickle.load comment [1]. I want to defend it here.<p>King (the author) places &quot;dynamically typed&quot; and &quot;statically typed&quot; in opposition. But keep in mind that many languages have both: Java, ObjC, TypeScript, C#, etc. I like to say that a a language &quot;has&quot; static and&#x2F;or dynamic types, but &quot;is&quot; dynamic if it supports runtime features like reflection - of course this is a sliding scale.<p>King observes that static types allow you to make explicit what you know. After calling `pickle.load` you don&#x27;t know <i>anything</i> about the result, so its static type is going to be something quite constraining like `String -&gt; Object`. It seems we are in violent agreement on this point.<p>King then goes on to make a different claim: that it is possible to implement `pickle.load` in Java and also in Haskell. It is possible in Java but not in Haskell.<p>Here&#x27;s the key line for Java:<p><i>However, nothing is stopping you from passing Serializable.class and branching on the type later</i><p>Notice the subtle shift in meaning for &quot;type&quot;: from static type to runtime tag. It is possible to branch on the type at runtime, because the type is available at runtime, because Java has dynamic types. They&#x27;re awkward and painful to use, but it is possible.<p>For Haskell:<p><i>Can we do this in Haskell, too? Absolutely—we can use the serialise library, which has a similar API to the Java one mentioned above.</i><p>Absolutely you cannot! The Serialise libary requires you to list all of the possible result types up-front, &quot;by providing a set of type class instances.&quot; There is no way for a Haskell program to deserialise a value whose static type was not visible when the program was compiled. There is no way in Haskell to &quot;get a list of all types&quot; (it&#x27;s hard to even formulate this).<p>Implementing Python-style pickle isn&#x27;t really about types, it&#x27;s about the language&#x27;s dynamic features. Can you look up a types by name, reflect on a value at runtime? Dynamic features really do bring new capabilities to programs.<p>1: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21479933" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21479933</a>

EDIT: I was in a snarky mood earlier when I wrote this comment, I was tempted to just delete it, but I’ll leave the text as a reminder to myself to find better wording for comments despite my personal mood in the future.<p>I clearly do not understand the overwhelmingly dedication type system proponent have against dynamic languages, particularly as evidenced by the previous comments in this thread. I would note that it seems to be the same, but reversed, for proponents of dynamic languages. Other than two or three mentions of Rust, all the examples and discussions have been about primarily interpreted or JIT languages with extensive runtimes. So there is little argument that these type systems are saving users (and I mean developers) from “memory safety” bugs or potential vulnerability exposing errors (those would tend to be problems with the interpreter&#x2F;runtime implementation).<p>Maybe I’m missing something, but if we are talking about managed language runtimes and, again based on the languages dominating the discussion, are nearly universally garbage collected, who cares what, if any, type system is in use for a given program?<p>I don’t know for certain (I don’t do any web based work) but I can’t recall ever reading about using typescript to boost speed or memory efficiency over vanilla JS. There is some performance benefit to say compiled Haskell vs interpreted Python, but that is apples and oranges, but based on a limited amount of googling, it looks like Clojure and Haskell are reasonably close for performance concerns.<p>Also, most of the type systems being discussed are complex and high level, so where does C and C++ fit into this topic? They are statically typed languages (I am aware the type systems used are fundamentally weaker than those of HM type systems) but no one seems to be arguing that they are good examples of why static typing is beneficial. Rust, while a more typical functional programming style type system, is still not really being discussed. I know that the article doesn’t address these areas or languages, but for those advocating so strongly for types, why no present something other than technical debt, easier reading, and organizational benefits. For dynamic proponents, why not address the lack of user visible benefits, i.e. no real performance win in common usage scenarios, the lack of assistance weaker type systems give to protect from differing types of errors, etc.<p>All I can tell is that some people like types and some people don’t. And most of the discussion seems to center on your standard CRUD app, web based applications, does it even matter?

Types are specifications, Knowing if and how something doesn&#x27;t meet a spec is useful both in development and at run time.

This is so predictable.<p>1. Author attacks premise of dynamic type systems argument.<p>2. Author presents premise for static type system (which is practically confluent&#x2F;equivalent&#x2F;equifinal to premise he just undermined).<p>&gt;static type systems allow specifying exactly how much a component needs to know about the structure of its inputs, and conversely, how much it doesn’t. Indeed, in practice static type systems excel at processing data with only a partially-known structure, as they can be used to ensure application logic doesn’t accidentally assume too much.<p>Chances are you are wrong about &#x27;how much you need to know&#x27; irrespective of your type system. Nobody gets it right the first time.<p>When we figure out that we were wrong about how much we need to know about the structure of our inputs (e.g we assumed too little) we do this thing we call... &quot;extending our code&quot; [1].<p>The question then is simply: which type-system is better at extensibility?<p>And I have no idea how to define &quot;better&quot;.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Extensibility" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Extensibility</a>

&gt;&gt; but they simultaneously advance an implicit belief: that dynamically typed languages can process data of an unknown shape.<p>The real difference is that dynamic type systems don&#x27;t pretend to. Static type systems have a way of putting developers at ease on auto-pilot. Arguments which compare dynamic type systems with static type systems should be more focused on reality rather than hypothetical, idealized use cases where the developer is a completely rational agent who understands everything about the project&#x27;s direction and strategy. The reality is that the vast majority of developers can&#x27;t design software properly; they can&#x27;t even select the best data structure to solve the simplest problems and they over-engineer and can&#x27;t create good abstractions that make sense and aid the project&#x27;s evolution. Most developers don&#x27;t know what a good abstraction looks like because they don&#x27;t have a long term vision for the product that they&#x27;re working on.<p>All these safety features which static typing supposedly introduces don&#x27;t actually protect the project&#x27;s code from the real threat which is poor design at an architectural level. I would even argue that dynamic typing can encourage worse design because it gives developers an incentive to keep inventing strange abstractions&#x2F;types that don&#x27;t correspond to the high level picture of what the software actually does... Most statically typed projects I&#x27;ve seen tend to be full of weird and unnecessary abstractions like: &#x27;Interactor&#x27;, &#x27;Builder&#x27;, &#x27;PrimaryAdapter&#x27;... these kinds of abstractions do not bring the code any closer to alignment with the end user&#x27;s perspective of the software (which should be the primary goal of any abstraction), instead, they impose constraints on developers working on the project... but as requirements change, these constraints have a way of becoming redundant which is why sometimes large amount of logic needs to be re-written.<p>Static typing encourages short term development strategies centered around constraining developers from doing certain things based on speculative and often completely arbitrary concepts that the lead developer felt in their gut was important. Maybe if the abstractions were designed around some long-term vision of the evolution of the project, but this is almost never the case (and I&#x27;ve worked on many different projects, for many different companies for over a decade), most of the time, abstractions and the constraints that they impose are in fact based on nothing but arbitrary technical decisions that may as well have been the result of a coin toss.<p>Developers should have an incentive to create fewer (and only necessary) abstractions, not more. By forcing developers to rely on their memory instead of their IDE to figure out which variables hold what kinds of objects, there is a strong incentive for them to keep abstractions as simple an non-confusing as possible.<p>Any tool which makes some aspect of life easier for the user will invariably make the user lazier and complacent in that domain. Abstractions are not something one should be complacent about, they&#x27;re very difficult to get right.

Title is confusing refers to Open worlds Not Open software

&gt; We don’t have to respond to an ill-formed value by raising an error! We just have to explicitly ignore it.<p>The point of the article is basically &quot;dynamic type systems are not inherently more open because we can just ignore type errors in static type languages [which means, of course, that we&#x27;re making them behave like dynamic languages]&quot;... Well, shoot.<p>Ultimately, this seems like her previous article was just contributing to that <i>six-decade-old</i> flamewar. Since this is a flamewar, it got comments disagreeing, and now she posted an article disagreeing with the disagreements.<p>Everything worked as expected and nothing that hasn&#x27;t been said before (over and over) was said.<p>Why can&#x27;t people just be ok with &quot;I like this paradigm and it&#x27;s ok if you like another&quot;? Sure, the discussion has led to plenty of advances in programming language design, but at this point it&#x27;s pretty clear that, if it were possible to absolutely prove that one type system is better than another, we would have done so already. Meaning that everything pretty much comes down to opinion.