What Dynamic Typing Is For
unplannedobsolescence.com
unplannedobsolescence.com
Immutability, for example, is another great constraint that's not considered in the article, but should certainly be on your mind if you're deciding between, say, Rust and Java.
The article delves into some of the drawbacks of static typing, in that while it can be more expressive, it can also contain a lot of information that's useful for the compiler but decidedly less useful for a reader. The Rust example that loads a SQL resultset into a collection of structs is a standard problem with dealing with data that's coming from outside of your static type system.
The author's solution to this is the classic one: we just need a Sufficiently Smart Compiler™. Now, don't me wrong; compilers have gotten a lot better, and Rust is the poster child of what a good compiler can accomplish. But it feels optimistic to believe that a future compiler will entirely solve the current drawbacks of static typing.
I was also slightly surprised when templates were suggested. Surely if you're aiming for rigor and correctness, you want to be dealing with properly typed data structures.
I don't think that's an ideal mental model. Code in any (useful) language can do what you want, and can not do what you don't want. The question is how far that code is from code that breaks those properties -- using a distance measure that takes into account likelihood of a given defect being written by a coder, passing code review, being missed in testing, etc. (Which is a key point -- the distance metric changes with your quality processes! The ideal language for a person writing on their own with maybe some unit testing is not the same as for a team with rigorous quality processes.) Static typing is not about making correct code better, it's about making incorrect code more likely to be detected earlier in the process (by you, not your customers).
By 'constraint' I mean something the language disallows or at least discourages. Constraints in software development are generally intended to eliminate certain classes of errors. Static typing, immutability, variable scoping, automatic memory management and encapsulation are all examples of constraints, and represent control that the language takes away from the developer (or at least hides behind 'unsafe' APIs).
By 'expressiveness' I mean a rough measurement of how concisely a language can implement functionality. I'm not talking code golf here; I mean more the size of the AST than the actual number of bytes in the source files.
Adding constraints to a language does not necessarily reduce its overall expressiveness, but static typing is one of those constraints that typically does have a negative effect on language expressiveness. Some will argue that static typing is worth it regardless, or that this isn't an inherent problem with static typing, but one that stems from inadequate compilers.
One of the most untapped and misunderstood areas in language design is static metaprogramming. Perhaps this is what you meant by "inadequate compilers", but there is no reason why Java can't provide compile-time metaprogramming. With a comprehensive implementation it can compete directly with dynamic metaprogramming, with the benefits of static analysis etc., which is a game changer.
What often annoys me about proponents of static typing is that they sound like it doesn't have a cost. But it does.
1. It makes syntax more verbose, harder to see the "story" among the "metadata".
2. It makes code less composable, meaning that everything requires complex interfaces to support everything else.
3. It encourages reuse of fewer general types across the codebase, vs narrow scoped situational ones.
4. It optimizes for "everything must be protected from everything" mentality, when in reality you only have like 2-5 possible data entries into your system.
5. It makes tests more complex to write.
6. Compiled languages are less likely to give you a powerful/practical REPL in a live environment.
For some, this loses more than it gains.
Also, albeit I haven't seen this studied, human factor probably plays bigger role here than we realize. Too many road signs ironically make roads less safe due to distraction. When my code looks simple and small, my brain gets to focus better on "what can go wrong specifically here". When the language demands I spend my attention constructing types, and add more and more noise, it leaves me less energy and perspective on just taking a step back and thinking "what's actually happening here".
"write 99% correct code in 1 week and then try to fix it as you go, but your fixes often break existing things for which you didn't have proper tests for. It then takes you total of 2 years to finally reach 100% correct code."
Which one do you choose? It's actually not as simple as 1 year vs 2 years. For a lot of stuff 100% correctness is not critical. 99% correct code can still be a useful product to many, and to you it helps you to quickly validate your idea with users.
However, the difference between static and dynamic typing is not that drastic, if you compare dynamic typing to an expressive statically typed language with good type inference. Comparing, for example, Python to C++ is not really fair as there are too many other things that make C++ more verbose and harder to work with. But if we compare Python to for example F# or even modern C#, the difference is not that big. And dynamic typing has a costs too, just different.
1. "Story" can be harder to understand without "metadata" due to ambiguity that missing information often creates. It's a delicate balance between too much "metadata" and too little.
2. Too much composability can lead to bugs where you compose wrong things or in a wrong way. Generic constraints on interfaces and other metaprogramming features allow flexible and safer composability, but require a bit more tought to create them.
3. Reuse is similar. No constraints on reuse, doesn't protect you from reusing something in corner case where it doesn't work.
4. (depends on how you design your types)
5. Dynamic languages require you to write more tests.
6. F# and C# for example both have REPL.
Quality statically typed language is much harder to create and require more features to be expressive, so there are less of them or they have some warts and they are harder to learn.
It's a game of tradeoffs, where a lot of choices depend on a specific use case.
Whether you write document them or not, types still exist, and you have to think about them.
Dynamic languages make it really hard to answer “what is this thing, and what can I do with it?”. You have to resort through tracing through the callers, to check the union of all possible types that make it to that point. You can’t just check the tests, because there’s no guarantee they accurately reflect all callers. A simple type annotation just gives you the answer directly, no need to play mental interpreter.
I work on airplanes and cars. The cost of dead people is a lot higher than the cost of developer time. It’s interesting to ask how we can bring development costs down without compromising quality; in my world, it’s not at all interesting to talk about strategically reducing quality. We have the web for that.
You have some level of quality ya'll are used to, that was already achieved by compromise, and you'd like to stay there. How was that original standard established?
On an exponential graph of safety vs effort (where effort goes up a lot for small safety gains) you are willing to put in a lot more points of effort than general industry to achieve a few more points of safety.
Safety-critical code for aviation co-evolved with the use of digital systems; the first few generations were directly inspired by the analog computers they replaced, and many early systems used analog computers as fallbacks on failures of the digital systems. These systems were low enough complexity that team sizes were small and quality was maintained mostly through discipline. As complexity went up, and team sizes went up, and criticality went up (losing those analog fallbacks), people died; so regulations and guidelines were written to try to capture best practices learned both within the domain, and from across the developing fields of software and systems engineering. Every once in a while a bunch more people would die, and we'd learn a bit more, and add more processes to control a new class of defect. The big philosophical question is how much of a washout filter you apply to process accumulation; if you only ever add, you end up with mitigations for almost every class of defects we've discovered so far, but you also end up fossilized; if you allow processes to age out, you open yourself to make the same mistakes again. To make it a less trivial decision, the rest of software engineering has evolved (slowly, and with crazy priorities) at the same time, so some of the classes of defect that certain processes were put in to eliminate are now prevented in practice by more modern tooling and approaches. We now have lockstep processors, and MPUs, and verified compilers, and static analysis tools, and formal verification (within limited areas)... all of which add more process and time, but give the potential for removing previous processes that used humans instead of tooling to give equivalent assurances.
Perhaps. Speaking personally now (instead of trying to generalize for the industry), I feel like almost all of the success stories about increasing code quality per unit time have been stories about putting defect detection and/or elimination left in the development process -- that is, towards more and deeper static analysis of both requirements and code. (The standout exception to this in my mind is the adoption of automatic HIL testing, which one can twist as moving testing activity left a bit, but really stands alone as adding an activity that massively reduced manual testing effort.) The only thing that I can see removing static types is formal proofs over value sets (which, of course, can be construed as types) giving more confidence up front, at the cost of more developer effort to provide the proofs (and write the code in a way amenable to proving) than simple type proofs do.
In the industries I've worked, it's not a huge problem if you have a bug. It's a problem if you can't iterate quickly, try out different approaches quickly, bring results quickly. A few bugs are acceptable as long as they can be fixed. I've even worked at a medical device startup for a bit and it wasn't different, other than at some point there need to happen some ISO compliance things. But the important thing is to get something off the ground in the first place.
Having competent people is a huge time (cost) savings. But if you don't have a process that avoids shipping software even when people make mistakes (or are just bad engineers), you don't have a process that maintains quality. A bad enough team with good processes will cause a project to fail by infinite delays, but that's a minor failure mode compared to shipping bad software. People are human, mostly, and if your quality process depends on competence (or worse, on perfection), you'll eventually slip.
So you're using proof on every line of code you produce?
No, except for trivially (the code is statically and strongly typed, which is a proof mechanism). The set of activities chosen to give confidence in defect rate is varied, but only a few of them would fit either a traditional or formal verification definition of a proof. See DO-178C for more.
We have started to use typed HTML templates in Ruby using Sorbet. It definitely prevents some production bugs (our old HAML templates would have `nil` errors when first going into production).
What I'm proposing is quite a bit more reasonable—so reasonable that versions of it exist in various ecosystems. I just think they can be better and am essentially thinking out loud about how I'd like that to work.
You use `req.cookies['token']` as an example of a subtle bug in JavaScript, but this isn't necessarily an inherent bug to dynamic typing in general. You could, for example, have a key lookup function that requires you to pass in a default value, or callback to handle what occurs if the value is missing.
req.cookies.get('token', () => {
throw new AuthFailure("Missing token")
})Have you somehow solved the halting problem? AFAIK, all Turing complete languages are perfectly capable of expressing the exact same programs.
That's one of the insights in WUFFS. Yes, most problems cannot be solved with WUFFS, but, we often don't want to solve those problems so that's fine. WUFFS code, even written by an incompetent noob, categorically does not have most of the notorious problems from systems languages, yet in the hands of an expert it's as fast or faster. It has a very limited purpose, but... why aren't we making more of these special purpose languages with their excellent safety and performance, rather than building so many Swiss Army Chainsaw languages which are more dangerous but slower ?
When you don’t write them down, you’re saying, “trust me, this works.” But now the types are written down in your head (a very volatile form of memory that can’t be accessed easily by others).
One time when dynamic works well is when “prove this works” is simply not worth the time. Eg. a quick script.
Which is only even true during the initial phases of a project. The moment the initial team shares bus numbers with other developers, the 'you' becomes a collective you, and you have three people who all believe they have it written down in their head, and often at least one is wrong.
You can make a project that relies on memorization. It will eventually fail, in one sense of the term or another. Or you can make it so that you can verify things you think you used to know about the project cheaply. But then you need to remember to check your assumptions when doing new work.
Note that "types have been written down" != "the program was written with static typing". See, for example, what's doable with clojure.spec.
While loose, "from the hip" code (w.r.t. typing) often correlates with the use of dynamically typed languages, we shouldn't make the mistake of assuming a total causality there.
(Also, I still find the number of people willing to put e.g. `object` parameters in their public C# APIs concerningly high. Not that one has to deal with such APIs all the time, but they're not exactly eradicated, either.)
It's great when you compile large amounts of code written in the same language into a single binary.
It's not so great for calls between languages or for servers communicating across a network. To get static guarantees back again, you often need to validate your inputs, for example using something like Zod for TypeScript. And then it's not a static guarantee anymore; it's a runtime error.
Database tables often live on a different server than the server-side processes that access them, so mix-and-match between different schema versions that the compiler never saw together is possible in most systems.
To prevent this, you would need some kind of monolithic release process. That runs into lifecycle issues, since data is often much longer-lived than the code that accesses it.
True, but validating at the boundaries and having a safe core is much better than having the unsafe portion everywhere imo.
And then the next server in line has to validate the data again.
Schemas should be derived from the type of the representation used in the application code, or vice-versa. If there are multiple schemas in use, there should be multiple corresponding types, perhaps with ways to interconvert between them. Schema changes will be less frequent, and easier to manage, with a bit of upfront systems analysis and design, including use of a data dictionary or complete IRM repository.
The more time you invest in thinking and planning what you want to build ahead of time, the fewer bugs and changes you'll have to worry about at runtime. The payoff is almost always more than worth the investment; "we don't have time to do things the right way" implies you have plenty of time to do things the wrong way.
BTW, Java has a framework called Manifold that provides type-safe SQL just like the author wants, with IDE support and everything:
https://github.com/manifold-systems/manifold/blob/master/man...
It just seems that some people like static types and good for them. Dynamic languages are for those of us who are, perhaps, lazy and want to be free to think about how to solve the problem at a slightly higher level without having to get into details.
For me the details activate my perfectionism and that blocks me from advancing with thinking about the goal and the effort of creating an elegant set of types makes me less willing to suddenly throw everything away when I realise there's a better approach. Dynamic languages give me that ability to "sketch" until I have an answer and at that point I have to ask: do I really need this to be in a higher performance language? Once or twice the answer has been yes but working out the approach in a dynamic language allowed me to do it right in the static language first time.
How many times have you seen a NoneType error or a KeyError? It's probably the most common class of bugs in Python and there's an easy way to eliminate it. And as a nice side effect your code is way easier to understand, navigate and edit.
I still sometimes have to give up and use Any in Python, partly because half the Python community haven't realised their mistake yet. But that's fine. It's still way better.
I thought adding types might help to remove the most trivial mistakes and help me get it into shape faster. All I can say is that it didn't. The easiest mistakes to make were not the kind of things that triggered typing issues.
When I bit the bullet and found some things that could be made testable - only then did the burden start to fall and to sort of exponentially disappear. Each test, crappy and incomplete as it might have been, made it easier to refactor so that the next test could be added. I went from system tests inwards towards unit test because this, again, had the biggest benefit/cost.
So my thesis is that big general tests do more for you at the start and honing in towards more detailed ones returns less and less value. In this model I see types as being fairly detailed level tests so they can happen later on. This is a facetious, throwaway idea that just occurred to me so don't take it too seriously.
def add(a, b):
return a + b
add(1, 2) # Works
add('a', 'b') # Works
add(1, 'b') # Type error!
This only gets harder with more type inference, as the actual issue may be far away from where the type error occurs.
This is why in haskell it is considered best practice to add type annotations to all top level definitions, at the very least.
But in practice it's quite handy to annotate module interfaces and even individual functions.
> But in practice it's quite handy to annotate module interfaces and even individual functions.
Yes, but it also limits what information the types can represent because of syntax and human patience limitations. A fully inferred language could associate numbers with possible value ranges, lists with their sizes, enumeration of fixed string values, etc.
Global type inference is literally this. Inferring types leaves gaps in the typing information, being global means the gaps can be arbitrarily large, and so a type conflict could theoretically span every line of a large program.
nitpick - in the Rust example it seems the events are not passed into rendering the events.html template.
https://unplannedobsolescence.com/blog/what-dynamic-typing-i...
IMO, the value of simple interfaces is enormous and yields substantial benefits in terms of separation of concerns and modularization. The benefits of such architecture make arguments around static vs dynamic types pointless.
Once you know how to architect code properly and test appropriately, it makes almost no difference whether the languages is statically typed or dynamically typed... A lot of the constraints of static typing become annoyances.
The most infuriating line I hear from proponents of dynamically typed languages is how statically typed languages make refactoring easier. It's infuriating because I know exactly what they mean but it's incorrect. Having coded with statically typed languages, I'm familiar with the feeling of refactoring code and "the friendly compiler" guiding me and reminding me of all the places were I forgot to update the code when I changed one of the types... But unfortunately, the very fact that refactorings often require updating code in so many places is a testament to poor architecture. I don't have this problem when refactoring dynamically typed codebases. On average, the code is more modular. With dynamically typed languages, people don't try to design types that cut across the entire codebase. Oftentimes, many 'refactorings' in static typed land are just type modifications which wouldn't even be a problem in the first place if a dynamically typed language was used.
Also most types systems don't go far enough. reverse takes a list and returns a list. That type checks but is of little practical value.
MathJs: https://mathjs.org/docs/reference/functions/reshape.html
NumPy: https://numpy.org/doc/stable/reference/generated/numpy.resha...
Eigen (C++): https://libeigen.gitlab.io/eigen/docs-nightly/classEigen_1_1...
The JS one is simple enough, but even here be dragons. The "number" type supports storing decimals like 2.3. There's an isInteger() function on it that's never used, and the implementation doesn't actually check that they're integers as far as I can tell. It's anyone's guess what happens when you violate the docs-only requirement for integral values only. Moreover, -1 is a sentinel value indicating autosize, so there are non-integral values that are accepted.
The numpy interface is worse. First off, fully static typing would involve dependent types here. We'll ignore that. Then you have the shape parameter, which is a structure of "ints". What do ints mean here? Any number of things, from python native bigints to np machine types. It also takes sentinel values. The order parameter is the real nightmare here though. Using this effectively is incredibly difficult because numpy doesn't want to constrain itself by specifying memory layout. But choosing appropriately here requires knowing that! Of course we could also just look at the static typing annotations for this function, which has 6 overloads for reshape (https://github.com/numpy/numpy/blob/0066c73f573daafa01cbb975...).
I don't see a lot of evidence in either of these that the dynamic typing forced people to keep them actually simple. They're filled with edge cases.
Compare with Eigen, which uses static typing to separate type parameters from runtime parameters. You don't need to worry about non-integral values because they're unrepresentable. You don't have sentinel values, because AutoSize is a different type with a clear name. The layout is specified as a type parameter, so the order parameter is usable based on information available at compile time. The return type is a bit complicated, but no worse than numpy.
TSX in particular is a terrible example to make the point. It's very very similar to HTML so there is barely anything more to learn, and in return you get type checking, auto complete, go-to-definition, etc. Its so good I use it for completely static sites.
The SQL example is more compelling, but again it's really hard to paint "SQL makes static typing a bit awkward" as "dynamic typing is great here!". Like, you shouldn't be super happy about walking across a desert because your car can't drive on sand. "Look how simple legs are, and they work on sand".
That said, the SQL example does suck. I'm surprised nobody has made something like sqlx that generates the Rust types and does all the mapping for you from your schema. That's clearly the way to go IMO.
I didn't say I was happy about it—I just said I needed to get across the desert!
The most maintainable codebase is the one that requires the least guessing from the developers perspective. Where everyone that looks at the code immediately gets a good understanding of what is going on. When it comes to this I personally had the best experience with Go so far as it is verbose when it comes to error handling (I don't need to guess what happens or what can go wrong etc.). Is it the most elegant? No, but I don't need to build a big context window in my brain to understand what is going on immediately (looking at you Rails callbacks).
Anyways I found the article interesting and as I am also using SQLC I think it is something that goes in that direction.
~98% of software gets thrown on the trash heap before it reaches the point where it really needs to be maintained.
That last 2% of gold dust desperately needs to be maintained well and to work, but to get to the point where you have that asset you'll probably find you need to throw away an awful lot of code first.
If you write that 98% using static typing it will slow you right down - potentially to the point where you dont even get to the gold dust.
If you write that 2% with dynamic typing it will fall apart. A lot of programmers see this process without ever appreciating the fast prototyping that got it there in the first place.
So, this is why Im a fan of gradual typing.
Structural subtyping usually hits the sweet spot for me: I can just create random structures on the fly, the type system makes sure I use them consistently, and my IDE helps me extract a named type out of them after the fact with just a few keystrokes.
1. Shorter iteration time for fixing type errors, especially things like field typos, missing arguments etc. They show up immediately as I'm typing instead of having to run a test suite (and having to write an extensive test suite).
2. You can write fewer tests to achieve the same code quality. Especially with really strong type systems like Haskell and Rust. Huge time saver.
3. IDE navigation features (go-to-definition, find-all-references) are generally faster and more reliable than grepping. I'm sure we've all had the pain of trying to grep where the `process` function is defined in a large dynamically typed codebase.
4. Auto complete works reliably.
5. You can refactor things reliably, especially renaming identifiers.
6. For multi-person projects or long-lived single-person projects it means you waste less time figuring out what code does.
IMO gradual typing isn't a good idea. Adding types after the fact is much more effort because you basically have to reverse engineer the code. And you don't get the performance benefits of "true" static types. There's a reason Dart switched away from it.
You really should want a template engine that knows if the variable it's injecting goes into a tag as text or into an attribute, etc.
The problem with the webstack is that these things are easily hard, or comes to you by using an ORM, or DSLs in a generic language.
Personal I think that things like JSX or: https://www.gomponents.com/ Aren't that bad, as they are basically modeling HTML.
JSX doesn't have to mean react, you could render server side into plain html.
Okay, but you can do the same in dynamically typed Python, while still using familiar exception logic and not requiring the type annotation on `req` (although of course you can still use one):
def authenticate(req):
match req.cookies.get("token"):
case None:
raise AuthenticationFailure("Token not included in request")
case cookie_token:
pass
match req.db.get_user_by_token(cookie_token):
case None:
raise AuthenticationFailure("Could not find user for token")
case user:
return user
def authenticate(req):
cookie_token = req.cookies.get("token")
if cookie_token is None:
raise AuthenticationFailure("Token not included in request")
user = req.db.get_user_by_token(cookie_token)
if user is None:
raise AuthenticationFailure("Could not find user for token")
return user
The nice thing about the Rust syntax shown is that constructs like `let` and `match` allow for a bit of type inference, so you aren't declaring manifest-typed temporaries like you'd have to in many other languages.
> It's possible to write sloppier Rust than this, but the baseline is quite a bit higher.
The flip side: the baseline for Python might be low, but that's deliberate. Because there are common idioms and expectations: dictionaries have both a `.get` method and key-indexing syntax for a reason (and user-defined types are free to emulate that approach). So indeed we could rewrite again:
def authenticate(req):
try:
cookie_token = req.cookies.get("token")
except KeyError:
raise AuthenticationFailure("Token not included in request")
user = req.db.get_user_by_token(cookie_token)
if user is None:
raise AuthenticationFailure("Could not find user for token")
return user
You can always add more checks. The Zen says "explicit is better than implicit", but I would add that "implicit is better than redundant".
> In essence, dynamically-typed languages help you write the least amount of server code possible, leaning heavily on the DSLs that define web programming while validating small amounts of server code via means other than static type checking.
Well, no; it's not because of access to the DSLs. It's because (as seen later) you aren't expected to worry about declaring types for the interfaces between the DSLs and the main code. (Interfaces that, as correctly pointed out, could fail at runtime anyway, if e.g. an underlying SQL database's column types can't be checked against the code's declared data structures at compile time.)
The main thing that personally bothers me with static typing is that, well, sometimes the type calculus is difficult. When your types don't check, it's still on you to figure out whether that's because you supplied the wrong thing, or because you had the wrong specification of what to supply. And understanding the resulting compile-time error message (which is fundamentally written in terms of what the type is) is typically harder than understanding a run-time dynamic type error (which can usually be understood in terms of what the object does).
But the rust code is still safer, e.g. you haven't checked for an `AttributeError` in case `req.cookies`, the point is Rust protects you from this rabbit-hole, if you're prepared to pay the price of wrestling the compiler.
Luckily i'm just the mad scientist to recreate a non-async rust web stack, here's the sqlite bit if you're interested.
maybe people should watch Rich Hickey's Value of Values.
Flavour book: https://frequal.com/Flavour/book.html
Flavour home page: https://flavour.sourceforge.io/
Example app: https://frequal.com/wordii
Personally, I’d rather stop writing software than write everything in Java, and writing software is just about my favorite thing in the world. I don’t contend that Java is a bad language. However, it’s almost diametrically opposed to how I think about programming logic, and its style and conventions set my teeth on edge. I’m sure Java programmers would say the same about my preferences, too, and that’s OK! I’m not saying that my opinions are objectively right. But I am saying that no one would be willing to pay me what it would take to get me to write Java for a living.