This reminds me of the studies done related to traffic lights and stop signs.

Removing traffic lights and stop signs actually reduces accidents because drivers are more careful when driving through intersections which reduces speeds and drivers become more alert.

Developers will adapt to their toolset. If you have a statically typed language, you trust it will deal with type related issues and you become more lax with testing things related to types. When you develop in non-typed languages like Ruby, you tend to write more tests and not trust your compiler (because you don't have one). This is why you will find most Ruby developers are really good at writing tests and embracing TDD.

You're point is valid, but you really quickly move past just how slowly drivers have to be when there aren't traffic lights. As with everything they're a helpful tool for efficient traffic, just like static compilation.

I can't speak for all Ruby developers but I found that I could read a pull request from just about anyone I worked with a and find a spot where they hadn't covered a possible nil with a test. And yes, we had coverage checks.

A type system can keep you from having to write those tests.

> A type system can keep you from having to write those tests.

Because with a proper static lang (hint: not Java, not C#), nil doesn't exist? Right.

Those languages don't have null safety, but plenty of languages do. Rust, Kotlin, Swift, Haskell, etc.

The claim is true: a type system _can_ prevent null-related issues and eliminate the need to account for them in tests. That's not the same as saying every type system does.

Doesn't C# support this by enabling Nullable?

They all have nulls but a static lang will warn you that the value can be null.

This is false. There are plenty of languages without pervasive implicit nullability. Check out Haskell and Rust and Ocaml.

You are right. I should have said some. The point I wanted to make was that having type safety is better for checking null than having no type at all.

It can if you choose to return Optionals instead of nulls.

That's a good analogy, because just like when an intersection gets enough throughput, relying on drivers to navigate their way through becomes unrealistic. Once a codebase reaches a certain size or complexity, it starts becoming really time consuming to follow untyped logic all over the place and you run the risk of a rockstar developer putting a scooter object into the side door of your minivan object.

Static typing gives you assurances and tools with which to test your assumptions in the code, for those times when reading the whole stack is cumbersome, and you need to defend against less careful developers. It also transfers a bit of knowledge between developers in a trivial way that would otherwise be a pain to communicate.

I think this analog is close to the dynamic vs static debate. However, there are probably more factors to consider, such as competence of the driver (will the driver even care to slow down?), location of the intersection (an intersection just around a shallow corner) and value of the driver's car (does the driver care about a little damage?).

In my experience similar arguments hold for software developers. Especially caring can be a big factor; i.e. the "move fast, break things" mentality.

I've been back and forth between typed and untyped languages (somewhere in the range of haskell and tcl) and personally prefer less typing when hacking things together and more typing for high quality software. I'm currently working an infra job where we use both ansible and terraform. They're not direct competitors, but I tend to prefer terraform over ansible when possible, as terraform gives me more "static" guarantees, which translates to more confidence when we apply our code.

One could argue that dynamically typed code is often shorter, and therefore both easier to reason about, and possessed of fewer bugs on a bugs-per-line basis. Not really keen to push that line of reasoning myself, just helping picture one possible argument.

This is true in a local context, but entirely breaks down when a codebase becomes larger than a single person can fit into their brain-RAM. Not arguing or saying you're wrong - just presenting the very quickly reached boundary where the argument breaks down.

It's not just local context. Reading a dense book is still more difficult than reading a less dense book, given a fairly similar amount of information and style in conveying that information. Larger codebases suffer the same problem you mention in a different way, and cargocults in most static languages tend to advocate very verbose writing styles.

Where this falls apart, the more verbose writing style hasn't been proven to convey more information or in a better way. That's an assumption still tossed around.

It is just a fair bit harder to figure out the types as program grows.

Not in my experience. Language engines are good enough to help most of the time,

And typed or untyped, you’re only ever reasoning about the types in the context you’re working in, not the entire program.

Can you actually determine things like that with an engine?

A Python function can be called from within or from outside of your codebase with different callsites passing different types.

I would even argue that shorter can do the opposite. You can squeeze an awful lot of information into a tight space in dynamically typed languages that allow functional programming and especially with terse syntax for often used constructs.

This can make it much harder to actually reason about the code, while making it seem easier to reason about. Most people would agree w/ your reasoning on a short piece of logic, which then at runtime spectacularly fails because the inputs don't adhere to the types you expected. In a statically typed language you would not even have gotten it to compile and while it might not feel like a bug is being prevented and actually feel tedious, every time your IDE (or compiler) tells you that the type on something is wrong, you've prevented a potential bug.

Yes. Shorter means less to compare against for consistency.

My point is exactly the opposite. Shorter does not always equals easier, less to do etc.

Let's say we compare Javascript and Typescript (as they're so close but one has static typing.

    const myFunc = (param) => {
        doSomethingWith(param?.property);
    }

Easy, right? Well, does param actually have `property`? No idea. What type is `property`? Does the function `doSomethingWith` take that kind of input? No idea. Now I have to check that function, which might be coming from I don't know where, I might not even have an IDE that can reliably determine where `doSomethingWith` is coming from exactly. Even if I can navigate there now I have to check that piece of code and any other code it calls with `property`. Maybe `property` itself is an object and `doSomethingWith` assumes it has yet another property. This can easily go quite deep and I will not be able to easily reason about this at all. You can't tell me that someone can have all possible runtime combinations of this in his head for any reasonably sized program.

Now let's take something that is almost equal but slightly longer to read and write, same thing in Typescript. I've had to define the types of these things somewhere once. Big deal.

    const myFunc = (param: SomeType) => {
        doSomethingWith(param.property);
    }

Notice how this is really not much of a difference. Just a type declaration and it gives me a lot of safety. Let's assume SomeType defined `property` as non-null, so no `?` needed, I know my inputs have already been checked. `doSomethingWith` also defines its parameter type correctly and we know what `property` is or isn't. No need to know anything from the top of my head or spend time digging through code myself. The compiler knows that I am passing the correct type of object along and I won't get a runtime error (well, OK, it's Typescript, so let's also assume I'm not in a mixed TS/JS code base where I might very easily get `any` kind of object.

Now syntax will be a little bit different, but I would argue the exact same thing in say Java or Kotlin is equivalently short and readable (yes even in Java!) while benefiting from even more type safety:

    public myFunc(SomeType param) {
        doSomethingWith(param.getProperty());
    }

Didn't really hurt much, did it?

But these are super simple example. It get can arbitrarily complex.

It would be hard for me to agree more.

But Java, Kotlin, and Typescript types are very weak sauce. When types can do more, we can do more with them.

As a Haskell programmer, this argument does not resonate with me. I find most dynamically typed languages (e.g., JavaScript) verbose compared to what I'm used to. Of course, plenty of statically typed languages are verbose too. But static typing is not a sufficient condition for a language to be verbose.

I associate verbosity with object-oriented programming, whether statically typed or not.

As a clojure programmer, I'd say the same of Haskell. Oop is less expressive than FP, and static typing is less expressive than dynamic typing. These are usually just tradeoffs people choose for their problem domain

> static typing is less expressive than dynamic typing

Here's something I can express with static typing that I can't express with dynamic typing: "this function returns a function which returns an integer for every input". There's no test you could write to verify this property. So I'm inclined to say that static typing is more expressive, since it gives me a way to express and verify properties like this.

clojure spec will do this in the way you're asking.

Not even wrong.

Without compile-time types, you are not equipped to express serious compile-time work.

Shorter how? The typing can often be implicit in many languages like Scala which makes it pretty short compared to something like Java. While there is a bit of explicit typing, I think it’s well into diminishing returns to force even shorter code.

> It’s basically self-evident that static analysis reduces bugs.

And yet, per TFA, it’s not; at a minimum it’s clearly not “self evident”.

Why do we developers value our personal experience above studies, while dunking on average citizens for doing the same?

Guess we’re just as human as the rest of humanity; subject to the same urge to trust our own beliefs over contrary evidence.

Because the studies are constructed by equally fallible humans, and almost always badly.

Cold shower attempted, but the plumbing was busted?

Such studies invariably wholly miss the point: when you have a language with powerful type support, error checking is the least valuable work you get out of them. Types do serious heavy lifting expressing semantics.

As a general rule for dev work, trying to make evidence based decisions is fairly difficult. There's just not that much evidence around yet that can make it obvious as to if in your particular situation what the best choice might be.

And at the end of the day you have to contend with being in a work environment where politics and personalities rule, not science (or engineering).

That said I do wish more devs would take an interest in the available quality literature. Unfortunately I'm far more likely at work to run into an Uncle Bob recommendation at work, than a recommendation of ACM's Digital Library.

It is not evident to me. Having used both statically typed and dynamically typed languages my experience is that I can't remember ever seeing a bug in our fairly large rails app that a type system would catch. Nobody's passing strings where hashes are expected, or Widget instances where User instances are expected. The thing to pass to the function is nearly always self evident. If you did it would immediately be caught when a test runs anyway.

However, refactoring code in C# is much easier than refactoring ruby because you can lean on the type system there. However writing new code in C# is often much harder to do in C# because of the constraints of the type system. So really, it ends up being a wash for me.

Even trivial things like a typo in the method name in a method call are not detected at compile time by languages like JavaScript or Ruby (since their "method calls" are in fact just lookups in a runtime hash table...).

If you have not seen them, the reason is probably that the code was tested well enough before you looked for the bugs.

> If you did it would immediately be caught when a test runs anyway.

That's the point though. With dynamic typing you would only (hopefully) catch this with manually written tests. With static typing you get that feedback for free at build time.

With static types, every function signature implicitly comes with built-in tests for free.

Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time.

> Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time.

How would that pass any code review, regardless of static or dynamic typing?

The only time I have ever seen something like this is using `todo!()` while initially writing code. I have never seen someone check in code like this.

What kind of clown show of a programming org are you working at?

This is morally equivalent to "There's no point to having a safety on a gun, because the safety won't stop you from bashing someone in the face with the gun." If you really want to, you can throw exceptions or crash the process or call exit() or call system("shutdown -h now") anywhere in your codebase. That has nothing to do with a type system.

Even faster, at "type time" if you use any decent IDE.

>Nobody's passing strings where hashes are expected

See, When I'm throwing together apps to clean up configurations, I am Pythonifying XML often. And when handling different return values, reshaping it into the useful components I need and trying to analyze data (and dealing with different return formats depending on number of results, aka a dict if there is one value, or a list(dict) if there are more) I have to constantly remember if I am going to be getting a list(dict(dict(dict(str)))) or just a dict(dict(string)), and so on. But that's me cobbling together scripts and not understanding the API by heart well enough.

Have you ever had crashes caused by unexpected use of nil/null/undefined? Using the return value from a function without checking for errors?

If you search your exception tracker for NoMethodError in production, do any results come up?

Yes - in every case it is calling a method on a null reference. And no commonly used statically typed language helps here because they all allow null references. And languages that disallow nulls, if you are one of the 10 programmers on earth working in one of those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway.

> no commonly used statically typed language helps here because they all allow null references

This is false.

TypeScript, Swift, and Rust are commonly used and support non-nullable references.

> those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway.

You don't need escape hatches to deal with "real world data" that may be missing some values. This blog post is my favorite detailed comparison of handling "real world data" in static vs dynamic languages: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

Rust's serde_json docs on "Operating on untyped JSON values" are also a pretty good description of working with "real world data" where you want to examine an arbitrary document: https://docs.serde.rs/serde_json/#operating-on-untyped-json-...

The only requirement for working with "real world data" in a static non-nullable language is to choose whatever kind of behaviour you want when working with the data. Everything you can do with null references, you can do better with option types; there is nothing that null references uniquely permit.

Typescript, swift, and certainly rust are not common languages by any stretch of the imagination. https://www.tiobe.com/tiobe-index/

If you really think TIOBE is a reasonable way to gauge dev mindshare, fine.

1. Python with mypy has `strict_optional`. On by default.

2. C, being “portable assembler” is not really statically typed.

3. Java has had Optional for years, although it’s not the most pleasant to work with it does exist. And JVM languages like Kotlin go well beyond this.

4. C++ has `not_null`.

5. C# supports type-system enforced non-nullable types since 8.0.

You said:

> languages that disallow nulls, if you are one of the 10 programmers on earth working in one of those languages

I hope it’s clear that you are simply incorrect. There are plenty of tools to eliminate nullable references in modern mainstream languages.

> 4. C++ has `not_null`.

Most importantly in C++ only pointers can be null. You can return value types that are not nullable.

Dunno what to tell you dude; my imagination stretches there just fine. Maybe consider going to imaginary yoga class.

There have been people writing at least two of those languages everywhere I've worked for a while. Most of my professional colleagues can write at least one of these comfortably. I'm extremely confident in being able to hire programmers for all of these. They're all in use at every major tech company.

If you really want to stick your head in the sand and cry about how nothing can be better until they're literally top of the charts, I can't stop you, but they're certainly not rare. There's good stuff out there. Lots of people are using it. You can too.

If you'd rather trade links to charts, I trust Stack Overflow's developer survey's methodology a lot more than TIOBE's. 30% of respondents said they've worked with TypeScript, and that jumps to 36% in the professional developer subset. Rust is 7%/6%. That's a hell of a lot more than 10 developers.

https://insights.stackoverflow.com/survey/2021#technology-mo...

They also got 15% of developers who aren't using TypeScript want to use it, and 14% for Rust:

https://insights.stackoverflow.com/survey/2021#most-loved-dr...

My country has about 15% black people about about 7% asian people. My country has about 4% LGBT people, and my city has about 15% LGBT. It would be really weird to hear someone say that black, asian, and LGBT people are not common, especially after knowing and working with plenty of them.

> don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway.

You clearly have little experience with such languages, then.

Python (with mypy) has strict optional on as default and is the most widely used language, according to the latest stackoverflow ranking. Assuming you use mypy of course, which probably takes the usage rate down a factor of 100x but still.. ;)

It makes you actually have to consider scenarios where a variable can be none or not and try to push the validation up closer to where it entered the system.

Static typing doesn't mean type information being available. Most statically typed language allow some version of `let x = 5`. Similarly static types doesn't mean unsafe casting are not performed.

Also in the opposite direction, many dynamically typed language allows specifying types if you want to including python.

> let x = 5

x still has static type, the compiler just infers it based on the assignment, the type information is still there. Agree that implicit/unsafe casting is still and issue in some languages though.