Strong static typing, a hill I'm willing to die on

The article and many commenters here all talk about programmer ergonomics, productivity and "correctness".

The current research shows that these things are neither improved nor weakened by static typing. There are (even recent) papers on comparing typed vs dynamic language with no meaningful results. So basically it's entirely subjective.

However there _is_ an actual effect of static typing that can be trivially proven: It enables a programmer to write more efficient code. That should be at the forefront of every discussion around typing discipline, because everything else is just _hot air_ at this point.

TypeScript (used in the article) is an example that is _not_ actually strongly typed (it's statically typed but weak) and it doesn't even provide performance and memory layout guarantees, because the types are just comments. So you pay all of the cost of static typing without _any_ of the tangible benefits except documentation.

To me it is surprising that we as a technical community completely ignore actual evidence and take our cultural and personal preferences as fact.

And note the switch from 'only' to 'any'.

Anyway just hypothesising.

Does it, though? I'm not sure the research shows any strong evidence one way or the other. There's a decent review of various studies here, for example: https://danluu.com/empirical-pl/, that seem to indicate no real conclusion.

> Language design does have a significant, but modest effect on software quality. Most notably, it does appear that disallowing type confusion is modestly better than allowing it, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages.

> The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits.

> The data indicates that functional languages are better than procedural languages; it suggests that disallowing implicit type conversion is better than allowing it; that static typing is better than dynamic; and that managed memory usage is better than unmanaged.

Regarding your comments:

> Personally I like typed languages but the type systems in languages like TypeScript are simply insufficient. You still end up with runtime bugs because you can't actually use those types at runtime.

That's because TypeScript is not actually strongly typed, it is gradually typed; throw in a single "any" type into your TS and all static guarantees are now off. I agree that TypeScript is insufficient, and point to languages like Rust or Haskell (one of the languages with the lowest defect rate in the study [0]) that actually do offer static guarantees, and where use of untyped "escape hatches" is far less common and/or is far more judiciously applied.

> If a type system could basically remove the need for me to think about runtime bugs, then that's an absolute killer feature that I doubt anyone would argue against. But most languages don't provide that

Isn't this basically the promise of Haskell, Rust, et al? "If it compiles, it works;" "guaranteed memory safety," etc?

[0] https://developers.slashdot.org/story/18/01/01/0242218/which...

I think we'll have to settle for judgment calls.

I tried going through some of the research we have on developer productivity a few years back and it's almost all garbage or is only truly applicable to juniors (e.g. when you're new you really benefit from quick feedback time on static errors).

The entire space suffers from the fact that good experimental design is impossible to implement with anyone who's not a college student (good luck getting professionals to follow your rules for months) and the curse of dimensionality from the need to disentangle individual variations, type of software development, management style, and a thousand other things to try and draw out a signal.

Sadly, many things and life can't be effectively measured.

If the language is powerful enough to be able to write ordinary programs, it is powerful enough to produce bugs.

Static typing can be effective at catching certain types of bug, not all. It can improve readability sometimes (as a DSL for static unit tests/executable docs).

In general, dynamic languages are more agile and you can write more tests easier. Some of the tests you wouldn't need to write in a statically typed language, therefore typing is still useful though not as universally effective as one might believe.

I don't know which research you're thinking about, but if it's the one I've seen, it was empirical analysis and it's worthless because it's subject to survivor bias: whatever the tool you're using to make a program, it's going to be polished just as much as needed for it to fit its market, or it will die, simple as that.

If one paradigm lead to much more bugs per written line of code, but you're using it anyway for mission critical stuff, then you'll fix those bugs or fail. On the other hand, if one other paradigm leads to very little bugs compared to others, but you're using it somewhere where reliability doesn't matter, then the few bugs that are there from the beginning will stay there.

We can even call that the iron rule of bugs: No matter what tools you use, your code will contain roughly as many bugs as your business can tolerate.

The real question is how much effort does it take to achieve the same level, but it's obviously harder to study.

The thing is, not everything is going to show up in research results. There are an insane number of variables.

How do you account for developer experience? How do you account for experience within a domain? Experience with a language? How do you account for different type systems? Training with type systems? Complexity of the domain? How do you account for one developer being better than another? How do you account for development methodologies? How do you account for people's moods that day? How do you account for effort?

It's just not something you can easily research. It's extremely expensive just to generate a small study that tries to control for some of these things.

In the meantime, we can use our experience as engineers. We have to make a judgment. We have to form opinions that are biased and subjective.

For the most part, the resistance to Typescript from devs who prefer to write plain Javascript is purely borne out of adding the types being "too much effort to be worth it". Sure you gotta wrestle with the type system now and then but there's often a reason you have to + once it works it usually works very well. Which I find kind of funny bc those devs don't mind putting the effort into writing unit tests, but adding types (think of them as just lower level tests) is somehow an insult to the way they do things.

But nah they'll still just rawdog their JS and just make mistakes/misspell stuff now & then as we all do. Let's just hope tests/CI pipeline is enough to pick it up before it gets to prod.

Also, the domain we're in is engineering. There are no single correct decisions and everything is about trade-offs. And that's good because otherwise our jobs would be the first to be automated out of existence. All of the discussion in this thread about people "thinking less of" other engineers for their opinions/experiences is fucking gross.

> I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; simple to read and simple to comprehend.

I don't agree with this argument, I think it's akin to saying "I like driving blindfold because it makes me drive slower". You can use linters with limits on line length and number of params if this is a goal for you, no need to go indirect with the restrictions.

I agree that typing is not the only solution, I'm just saying that I think the ROI is massive in types, so I think this should be the first tool people go to. Almost no investment, and a lot of benefit.

I agree with "code is the documentation", I even made a point about documentation in the post, but I argue that typing is part of the code. So "the code is the documentation, and typing is part of the code" is how I'd phrase it.

You must have a crazy good memory. I switch between multiple languages, and autocomplete lets me easily see what variant of a function this library uses again.

You know everything by heart?

This is very interesting and at first blush strikes me as backward. I wish I could sit in your office and see this happening, because I find it hard to imagine and I would love to know what that looks like. (And I have way less experience than you so I'm not saying it can't happen.)

Specifically, I find the domain-specific logic in my field is impossible to grok in dynamically typed codebases, while statically typed ones actually teach the developer what the business logic is.

> I may just be a grizzled greybeard screaming "the code _is_ the documentation"

Also confusing to me! In all my experience, static typing is what allows the code to be the documentation. Without it, there's no way to know what properties this object has or why we have a check for this certain property that I thought didn't even exist on this object. (Other than comments - maybe I'm on a weird team but I don't know anyone other than me who leaves comments of any significance.)

I say that as someone that quite likes static types. I don’t care, do what you do!

> I find dynamic typing ... acts as a forcing function to writing simple code; simple to read and simple to comprehend.

I find the opposite true. Many super-dynamic patterns are hard to type correctly. Good type systems tend to encourage simpler patters so you get simpler types.

> The argument that it helps inexperienced developers approach the codebase is, IMO, a poor one as it tends to incentivize an iteration loop that lacks understanding and is simply trying to make all the red go away.

Making the red go away is important because the red indicates a problem! This is a lot easier than other ways of discovering the error. Why would you want to discover the error later?

> I also don't like autocomplete, so take that as you will.

This is why I'm with commenters who say they don't trust people who are against static typing... I'm extremely suspect of computer programmers who don't want computers to help them program.

If this were broadly true for most developers using dynamically typed languages, it would be a very compelling argument indeed. But I think there’s pretty strong evidence the opposite is generally true: actual types produced to document real world dynamic code tend to be vastly more complex than the equivalent functionality implemented with static types from the outset. In the TypeScript ecosystem, DefinitelyTyped is an excellent source of countless case studies. The types they provide are typically definitely not, as you put it, “used in a simple way”. That’s not complexity inherent to the type system, or the type definitions as provided; it’s complexity inherent to the dynamic code they describe.

Equivalent packages which were statically typed from the outset tend to have much simpler interfaces because the types are defined upfront rather than retconned onto existing APIs. That doesn’t necessarily mean their interfaces are absolutely simple, but they’re typically relatively simple by comparison.

I’d go so far as to say that you can’t know how simple or complex an interface is without specifying it. If “the code is the documentation” (which I agree is a great ideal!), then interfaces without code specifying them are under-documented by definition. The further the code specifying the interface is from the interface itself, the more obscured your documentation is.

This also happens with tests. It's easy to get wrapped in testing libraries and abstractions and spend way more time than you need to.

The 80/20 rule applies in both areas. You get 80% of the benefit with 20% of the abstraction. It's usually a mistake to try to go beyond this.

Of any popular language I'm familiar with, I'd say Go is the one that follows the 80/20 rule best. It encourages you to focus on solving the problem rather than leading you down rabbit holes of various kinds, including with types. That's not to say Go doesn't have its issues, but it really is excellent at discouraging over-engineering.

What? It helps developers inexperienced with a given codebase (not necessarily inexperienced generally), because you can very easily understand the types being passed into functions. You may need to understand why a function is behaving a certain way, so you look at the arguments, if you see a type you don't recognize you can push a button and your IDE will take you to the definition of that type. If you want to you can with another key combination see all the inheritors of that type, and so on. It makes it much easier to feel confident about what one can and can't do with any given object at any given time, which is helpful when one is getting up to speed with an existing breed of architecture.

Dynamic APIs are super hard to reason about if you don't have types to ensure you are calling your APIs correctly (function argument A can be number or string, but not formatFunction)

So having static types makes your APIs less dynamic because people are too lazy to type them correctly. Which in general is good in my opinion, making an API dynamic should be done only when it is really helpful to do so.

The other point is null-guards which _some_ (but not all) type systems enforce, null-guards are just 100% good thing.

I guess that's similar to the redis example I gave, but it essentially means that even though we get sent JSON over the wire, we validate it fully and when it gets to our code we know it's a well formatted type. So our code can assume an email type is a valid email, an ID type is a valid ID, etc.

Is it really? Map<String,String> is a totally reasonable type to use in certain cases.

I'm forever grateful for Typescript, but I wouldn't be surprised to see some of that code in a future research paper titled "The era when types went too far".

I really wonder how people can actually work like that. Is there some overarching methodology like super strict tests with 100% code coverage or so?

I don't see how either of these things relate to type discussions. A typo can certainly lead to incorrect code in the most strongly typed, staticest language there is (otherwise, what the hell is writing code even for?) What's worse: a runtime error or no error that produces the wrong result? Running a Python project might be quicker than compiling a C++ project. Dynamically typed languages can do better than grepping for function calls.

You know, until the program is non-trivial: passing data between systems on a queue; using async, threading, and/or multiprocessing; compiled binary critical-performance libraries… and I’m left wishing I’d written the whole thing in Erlang.

Every time I see a developer make this complaint about static typing I wonder what the hell they're doing with their type definitions and architecture where this is actually a problem.

> and pray you fixed them all.

If this isn't detected for you at compile/build time you're not using static typing

> In my experience, not even that. Static typing speeds up my day to day programming.

Completely agreed. It also completely blows past the whole maintainability argument -- the junior developer you hire in 6 months is going to be much slower getting up to speed on your untyped code (using the "royal you" here).

For some, I'm willing to grant that it may be "faster" to write initially, but every developer reading your code written without types thereafter is going to be slower.

This is great, but it only works if you are executing the code that you want to inspect/complete/refactor. In my experience, that just doesn't scale well.

> You need to do runtime validation.

Type systems don't eliminate this, sure, but when used correctly, they _drastically_ reduce it, which is extremely useful.

> And good luck untangling your type definitions when your requirements change.

That's the best part - the compiler tells me exactly what I have to fix to get things working again. If I do the same thing in a dynamic language, I have to track things down myself, wait for unit tests to fail (hopefully I have 100% coverage...), and pray that there isn't an escape.

Just to take one somewhat at random:

> And good luck untangling your type definitions when your requirements change.

I think it is exactly the opposite of the case that static types make it harder to adapt to changing requirements. In every dynamically typed system I've ever worked on, there have been important assumptions about data structures - sometimes checked dynamically in pre- or post- conditions, sometimes only checked in tests, and often simply not checked at all - scattered all around, such that changing requirements necessitated reasoning through the impact of the change on all these implicit assumptions. It was terrifying to make changes. Sure, easy to make a change and start up the application with the new code without a fuss. But to know whether the change broke some obscure codepath I hadn't considered or been aware of? Very difficult! I much prefer a static analysis pass saying, "hey, you changed this interface, did you know this codepath over here relied on that thing you changed?". Static type systems are not the only way to accomplish this, but in my view, they are a much less burdensome way to accomplish it than the level of dynamic validation and testing necessary to do so otherwise.

But again, it's just a frustrating debate, because clearly you have the exact opposite experience! So where does it get us? Nowhere really...

I actually found this way easier with static types because with static types I could be significantly more confident about every single place one of those types was used, and look at it and see if it needed changes. This was way fiddlier to do in a dynamically typed environment

Author here. I think your examples illustrate my point rather than provide a counter example.

I mentioned later in the post that we validate when creating the type (from e.g. user input) so we know that the `Name` type is always valid (and " ") is not a name. So the type ensures that we have a valid name. So this will definitely be caught in our codebase.

As for birthdayGreeting("Anna" 4.5) and birthdayGreeting("Anna," -12335), number means a float in JS so it actually would be valid, though admittedly I had full integers in mind when writing this. Another example of where stricter typing than what TS providers (which Rust does!) would have helped better define the invariant.

So in short: the problem in the code there was that I was trying to show a simple example, which means I didn't define all the types as strictly as I normally would have, and it surfaced more bugs that would have been caught with types.

> This is actually very important since "type bugs" are trivially easy to catch

This, IMO, is exactly why I’m in the static type camp. It’s so trivial that you can do it declaratively, inline with the code it’s testing, with instant feedback, at every call site and in every downstream expression/statement. A type annotation doesn’t mean my semantic/domain logic is sound, I still have to test that. but it could replace dozens of trivial tests orthogonal to the logic I care about… tests which, let’s face it, few people are going to write exhaustively otherwise.

How is this evidence for it being a waste of time? No solution is perfect yet many are worthwhile.

One of the most famous type errors in recent history did in fact crash a spaceship.

https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_o...

It's funny you should mention this, as it immediately brings [1] to my mind. This well-known incident was due to type-checking, with acceptable ranges defined ahead of time for some types (which resonates with your comment: make birthdayGreeting accept ranges 1-150 or something, easy to do in ADA).

There are a few more well-publicized issues with spacecraft that could have been caught with better type-checking, including metric/imperial conversions (why not build the unit into a type? Though the fault probably was with integration testing for [2]).

Of course, you are right that type checking can't find every code issue (especially algorithmic), it doesn't replace tests. Instant feedback and type hints are invaluable during the development phase, though.

In your example, one could probably replace the first name string by a person type/object, by the way.

[1]: https://en.m.wikipedia.org/wiki/Ariane_flight_V88

[2]: https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter

Yet static typing does very much catch issues, so I really don't see where you're coming from with this.

I honestly don't know of a good way to implement this pattern without type checking or at least optional type hints and static analysis. Instead, you can do validation of the input values in every single method, which is hugely burdensome, or you can assume callers are passing you valid values and write tests to make sure it isn't too catastrophic if they don't. I don't find either of these solutions satisfying.

If you program in a dynamic language, then you have no choice but to perceive all bugs as runtime bugs. Because every bug you witnessed was a runtime bug, so why would types have helped you?

When I program in a typed language, the compiler rejects programs I write all the time. Things like: putting code that can't be rolled-back in the middle of a transaction.

Uhm. What? I'm a static typing proponent and I have never believed that the compiler will guarantee program correctness. Nobody believes that. They believe it largely eliminates a certain category of error, which it does. You're entitled to your opinion on dynamic vs static typing, but this particular point of yours is just a wild straw man

That's just not true. Absolutely no one claims that static typing guarantees correctness, because that's ridiculous and obviously nonsense.

The bigger issue with Python and static typing is the ecosystem and conventions that a lot of developers use, made worse by a lot of these developers really being data scientists who are writing Python. *args/**kwargs are heavily abused by people too lazy to write proper method signatures. It's extremely common in Python to have methods pass around DataFrames or dictionaries as a grab-bag of stuff. Bonus points when methods add and remove columns/fields so you don't know what's in the data bag until you run the code (or read every line).

You can do this in almost any language, of course. Nothing stops you from writing a C# program with every type being `dynamic` or have all your Go methods accept `interface{}`. But Python, for a long time, actively encouraged this approach, and sadly there's still many beginner tutorials today that present things like "just write a method that takes *kwargs and you don't have to change the function signature!" as an advanced language feature for smart people instead of an awful footgun.*

Flavors and CLOS are not "type systems". They are "object systems" and there is nothing "ugly" about them. Flavors was introduced into a Lisp which did not have a type system. Later CLOS was added to a Lisp which already had a type system: Common Lisp.

Concretely-speaking, an example of a bug being preventd by a typing system: Removing a field from an object in a large vanilla JavaScript project is inherently a minefield that has caused many bugs in the past, whereas the same alteration in a full Typescript project can be made with confidence.

Rust has a more powerful type system that actually fixes MOST of the memory bugs in production

I believe this would count as empirical evidence of very strong static typing reducing bugs. I think this points to what many other comments have been getting at, which is that typing is not a binary yes/no question, but a large, multi-axis (static/dynamic, strong/weak) spectrum with lots difference between type systems, as well as big differences in how people apply those type systems to their problem. You could still work in a static, strongly typed language and represent everything as strings, converting back and forth as necessary, but that's essentially working in a dynamically typed language. You could also take advantage of the tools the type system gives you in order to reap the benefits, creating classes representing the legal values and asserting important invariants.

Not to mention that range checking is also fixable by using optionals rather than assuming the existence of a value.

I’ve worked on reliability at a company everyone has heard of for software that billions use daily. So many bugs would have been blocked by having a type system at all (dynamic languages on backend or JS on web) or by having a less bad type system (changing ObjC to Swift and Java to Kt on mobile). Null pointers/references alone have created so many bugs for us. Bugs that could have been compiler errors.

It makes me so much more productive, by orders of magnitude. And I say this as someone who has worked extensively in several different languages which covers large parts of this spectrum, like C, C++, Java, Python, JavaScript, TCL and others.

It makes it much easier for me to reason about code I have not recently worked on, be it in the current project or in dependencies. It also means I can be way more focused on the problem at hand, since I'm not constantly having to go on tangent goose chases to figure out what exactly I can do with this object that some function returns.

Sure there's the good, fuzzy feeling when the compile doesn't error out. But that's secondary.

How would you feel if I claimed that you could make emotional arguments faster than you could make rational arguments?

Because that is how this debate feels!

I want the simple rationality of my compiler saying "no" if I try to treat my hashmap like an Apple or a String.

As I understand it Python is also strongly typed, while JavaScript is not.

For me, strong and dynamic is the worst possible combination. I actually need to be precise with types, but the language gives me no help.

I think Elixir has the best combination of runtime and tooling and ecosystem out there, and it’s type system is the only thing that prevents me from using it for nearly everything.

Now go and rewrite your dynamic language's runtime in a dynamic language.

For me, full time Rubyist for over a decade, it was enough to "jump ship" to Rust and TypeScript. It's one more reason to forego Ruby, I fear.

I’ve been through several typescript projects where ‘as unknown as any’ makes me wish we didn’t even have typescript in the first place.

If you can’t trust the type system it’s worse than not having one :/

This seems to be a main reason certain people like it. It gives a sense of productivity. However I think it is misguided. It’s a false sense of productivity. Can they commit? Maybe, yes. Will it be right? Maybe, and more likely with types to handhold. But does it mean they understand the data model and the domain of the codebase they’re working in? No. No typing forces you to know what your code is actually doing.

It takes longer to be productive, but you’ll be productive because you know what you’re doing. Not because the IDE held your hand.

Widget factories or scrum farms will no doubt like the “ease” of jumping into a codebase that has typing, but I’m not yet convinced it’s better or that much better for the experience developer. I need to think on it more. For certain though I’ve seen enough in my time to know that how quickly a junior can “just jump in and make some sort of contribution” is not a good measurement.

I'd tend to think the important feature here is strong typing, not static typing, and indeed TypeScript, which is hampered by the anemic type system of its parent JavaScript, it not the best example of strong typing.

Ultimately, strong typing is a hill I'm willing to die on, too. But a lot of people making arguments on this topic are conflating it with static typing, which just isn't the same thing. In general, that gives me the impression you haven't done enough work in enough different languages to really have an informed opinion. The type systems of different languages work within the context of the language as a whole, with tools like REPLs, test frameworks, constraint checkers, static analyzers, and IDEs carrying a lot of the work that might be attributed to a type system. There are a lot of confounding factors here, and if you're only talking about a few languages and you are making mistakes like conflating static=strong and dynamic=weak, you don't have the breadth of experience to understand what the benefits and downsides of strong types are.

Though uncommon, strong dynamic type systems do exist. Scheme is probably the most popular example, although its type system isn't the strongest. This is the approach I'm taking with Fur[1], which attempts to have as strong a type system as possible while still being dynamic. Python is... stronger than many other popular languages (i.e. JavaScript), but still does a lot of coercion (particularly around truth-y/false-y values--duck typing is a bit of a grey area in that it's sort of arguably weak typing, but also arguably indicates a capable type system rather than a weak type system).

But perhaps more critically, weak static type systems also exist, such as C, which is the source of many of the world's most serious bugs. It's highly unwise to assume that static typing is strong typing.

[1] https://github.com/kerkeslager/fur

How are you measuring this?

Java by contrast has a greatly simplified generic system; Scala improves on that with robust type inference, making generics pretty trivial to write and use.

That's more about type coercion which you can avoid in dynamic languages. See === vs == in JavaScript.

Java, I'm sorry for swearing at you all these years. :P

Try ML (OCaml, F#…) or Haskell, they have type inference. No need to declare types most of the time, but they’re there, checked at compile time.

Haskell can do that. https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_gui...

All the TS devs just conflate JS with "no types" and picture drooling idiots that make random changes without knowing the type of anything (probably because that's what they do without 50 IDE popups to guide them). You're never going to convince them of the values of dynamic typing because they have a different mental model of it in their head.

The article puts a few cases forward. What the article is discussing, however, is the majority of software. Built in varying teams. Over long periods of time. Large software, complex software.

I like the idea, feels very pythonic ironically. And I suppose if you don't want the generic, I imagine there is probably some subclass of that which is more restrictive.

Anyway, as a developer I love when people do this. As a developer this sounds like a nightmare to maintain. My coworkers have told me to limit the numbers of 'what ifs' and just roll with it.

Static typing, maybe not so much.

Over the years, I have done programming with C, C++, Java, C#, PHP, Python, OCaml, Lua, Nim, Golang, Rust, Objective-C, Flash, Bash, D, Scala, TypeScript, assembly, PL/SQL, F#, and a few that I am forgetting.

Compile time type checking can definitely make things easier.

But for dynamic languages that I have been programming in for many years to have types shoehorned into them as an afterthought feels like a kludge.

And it's a tradeoff. I got used to developing in Node or Python with vim without auto completion (although I had those things as a kid in IDEs for other languages and they can be great). And without compile time type checks.

You can pass JSON around and literally never do a database migration.

This stuff will lead to more runtime errors initially, but also means more streamlined code. And you have to do thorough testing regardless.

TypeScript might be a choice for a large project with several developers. But I would also argue that an even better choice would be just to use a different language that has the typing system you want built in rather than awkwardly bolted on.

What I see in most TypeScript projects is a half-assed attempt that still results in run time type errors, but with the added "benefit" of an awkward bolted on typing system and the need for more tools as well as losing any dynamic benefit.

They drop the idea of using JSON and make everything related to the database compile time checked if possible. I'm not saying that those checks can't be useful but if are going that route it would make more sense to just drop the dynamic language.

Having all of the dynamism can be a convenience and save you time and effort in other ways. But not if you treat it as a poor man's static language and shoehorn in types in a half assed way using a traditional database.

Part of this is that people think software engineering is about your choice of stack or adding processes to development.

What matters most is probably the feedback loop between the users and the developers. Starting with the requirements engineering. Second to that would be details of the software design and organization. Leveraging existing code effectively can be key. Using descriptive but relatively concise identifiers, short functions, good code organization.

But diving into and evaluating all of that stuff in detail takes effort and a lot of skill and so many make snap judgements based on surface level processes or tool selection.

Replacing types with tests adds giant amounts of boiler-plate code, for little benefit.

We can and do! Use SML!

People just don't find out about the good type systems because the market is crowded out by mainstream shit.

And people write pieces about how good this shit is: "I was going to add an Int to a String but the compiler stopped me! Less [sic] bugs!". With arguments like that, why would you switch camps?

Or sometimes you get fed shit and get told it's inference: "I can replace the first word on the line with 'var'!".

So what are the downsides?

Inference doesn't play well with inheritance or mutability.

If you read Effective Java and see the points about avoiding mutation and inheritance, then these downsides may very well seem like upsides to you.

Why did you stop coding in SML?

SML uses Hindley-Milner (with some modifications to support imperative code). Many statically typed functional languages descend from it: Haskell and OCaml are the most prominent.

> Other languages haven't adopted a similar system so there must be some kind of trade off. What was the downside?

If you're asking why existing popular languages don't adopt it: they can't. HM type inference requires a HM type system, and they've committed to a different one. At best you could get good inference on a HM-typed fragment within the language (though even that would mean making a lot of painful tradeoffs) but it would break down the moment it made contact with existing code.

If you're asking why HM languages didn't become more popular? Historical accident, in my opinion. I don't think it has much to do with the type system, given how fundamentally awful Java's is.

"Aha!" you say, "but by enforcing conditional checks at variable definition and inside function signatures we don't have to check them ourselves in our code and the compiler itself can check them to ensure correctness and optimize performance!"

...and I'd agree with that sentiment but I'd also add that by having to reason about your types constantly you're adding a non-trivial amount of mental overhead when structuring your code. For some people that's how they reason about their code anyway but for others, having to consider whether or not a number is a `u8`, `u32`, or `usize` adds a lot of complexity to the code that could very well be entirely unnecessary depending on the use case.

Consider, for example a program that's meant to be executed on the command line that takes two numbers and adds them together. No matter what language you use you have to convert the raw string input into a numerical type before performing the addition.

In Python you have a simple function, `int()` that will happily turn any string consisting of numbers into a proper integer that can be used for math operations. If it gets something that isn't a number it'll throw an exception which is trivially easy to detect and wrap in a `try`/`except` block with a user-friendly error message. If we wanted to support floating point numbers we could just use `float()` and the code would otherwise be exactly the same.

In strongly-and-statically-typed languages this same process involves considerably more overhead. Before we can select a function to convert a string into a number we must first pick a numerical type and before we can do that we must think real hard about how big of a number we're going to support in this application. Our function signature(s) could also get complicated because, "wait: what type of string are we going to get from the command line?" Something as simple as adding two numbers becomes complicated really quickly!

Comparing the two ways of handling things (strongly, statically typed VS strongly, dynamically typed), Python ends up the clear winner a lot of the time because you got the job done without having to think as much, with less code that's super easy to reason about even though it didn't use static typing.

The other problem is that when you write such trivial programs in strongly, statically-typed languages like C, C++, Rust, etc it requires a lot more mental overhead to look at the code to figure out what's going on/how it works (though with Rust, less so because there's not 1001 awful ways to do things haha).

You probably did this:

  for name in ("John"):
    # "J"
    # "o"
    # "h"
    # "n"

  for name in ("John", "Sam"):
    # "John"
    # "Sam"

  for name in ("John",):
    # "John"

Under a properly modern static typing system, you let that be inferred:

  let var = cache.get("key");

That author will most likely die in some statically statically typed corner he painted himself into.

Citation needed.

This is ENORMOUSLY context dependent. Enough to invalidate the entire point.

My day job is writing code that runs on a server I control. Mistakes there are super cheap to fix. I get a nice crash in sentry with stack and variables for all frames, I fix it, deploy. Done.

If I was shipping code to Mars, well that's the opposite situation.

CONTEXT MATTERS

You can either hire 10 dynamic typing software developers or 30 static typing software developers. Businesses which choose to hire 30 static typing software developers will fall to the companies which hired 10 dynamic typing software developers. It's pure economics.

Static typing fills your codebase with bugs. Whilst an inexperienced software developer might not understand why static typing increases rather than decreases bugs, you can see the increase in bugs in research papers on the topic. As plan as day.

(Hint: You have made your code more complex by using static typing and more complex code contains more bugs.)

> A Turing machine is not "so simple that it can run any any program ...".

Simplicity has nothing to do with it. Turing showed that some very simple machines can calculate recursive functions.

Not every machine that is Turing Complete looks like a tape machine from Turing's papers.

> it's no fun writing code for a Turing machine

Almost every general-purpose programming language is a Universal Turing Machine; so that's like saying it's not fun to write code, period.

> I can see both side of the arguments on many topics, such as vim vs. emacs, tabs vs. spaces, and even much more controversial ones. Though in this case, the costs are so low compared to the benefits that I just don't understand why anyone would ever choose not to use types.

> I'd love to know what I'm missing, but until then: Strong typing is a hill I'm willing to die on.

I genuinely want to know what I'm missing. I also outlined in the post all of the arguments I usually see in favor of not having types and why I disagree with them.

I'm happy, willing, and excited to hear what I'm missing.

- Use notepad for development (don't laugh, I've actually encountered a dev who's choice IDE was notepad).

- Never worked with more than 1 person on a project.

- Never worked on anything but tiny projects.

- Never re-opened a project after having worked on a different project for several weeks.

So, how often is poorly tested code out there? From the popularity of strong static typing, it must be ubiquitous.