Take care to differentiate strong/weak typing from dynamic/static typing. Many dynamically typed languages (especially older ones) are also weakly typed, but some dynamic langugages, like Python, are strongly typed. 1 + "2" == 12 is weak typing, and Python has strong typing. Type declarations are static typing, in contrast to traditional Python, which had (and still has) dynamic typing.

It's not about the bugs, it's about designing the layout of the program in types first (ie, laying out all of the data structures required) such that the actual coding of the functionality is fairly trivial. This is known as type driven development: https://blog.ploeh.dk/2015/08/10/type-driven-development/

What's even worse, when typing is treated as an indisputable virtue (and not a tradeoff), pretty much every team starts sacrificing readability for the sake of typing.

And lo and behold, they end up with _more_ design bugs. And the sad part is that they will never even recognize that too much typing is to blame.

I think you're missing the point of the blog a bit, as the `1 + "2" == "12"` type of issues wasn't it. It definitely also sucks and much more common than you make it sound (especially when refactoring) but it's definitely not that.

Anyhow, no need to rehash the same arguments, there was a long thread here on HN about the post, you can read some of it here: https://news.ycombinator.com/item?id=37764326

> The other side is those people who do not find those kind of bugs annoying

Anecdotally, I find these are the same people who work less effectively and efficiently. At my company, I know people who mainly use Notepad++ for editing code when VSCode (or another IDE) is readily available, who use print over debuggers, who don't get frustrated by runtime errors that could be caught in IDEs, and who opt out of using coding assistants. I happen to know as a matter of fact that the person who codes in Notepad++ frequently has trivial errors, and generally these people don't push code out as fast they could.

And they don't care to change the way they work even after seeing the alternatives and knowing they are objectively more efficient.

I am not their managers, so I say to myself "this is none of my business" and move on. I do feel pity for them.

> What is missing is mainstream adoption in libraries which is a matter of time.

I don't think that's a big problem anymore. Between typeshed and typing's overall momentum, most libraries have at least decent typing and those that don't often have typed alternatives.

It's because the nature of typing has changed drastically over the last decade or so, in well known languages, going from C++/Java's `FancyObject *fancyObject = new FancyObject()` (which was definitely annoying to type, and was seen as a way to "tell the compiler how to arrange memory" as opposed to "how do we ensure constraints hold?") to modern TypeScript, where large well-typed programs can be written with barely a type annotation in sight.

There's also a larger understanding that as programs get larger and larger, they get harder to maintain and more importantly refactor, and good types help with this much more than brittle unit tests do. (You can also eliminate a lot of busywork tests with types.)

> when types weren't an option we weren't going towards the cliff

Erm yes we were. Untyped Python wasn't magically tolerable just because type hints hadn't been implemented yet.

My info is maybe a bit dated, as it's been a while since we wrote this hackery. We also adopted SQLModel at some point but we had to patch it to work well (I think some of my contributions are now in upstream). As for some of the hacks:

    def c(prop: t.Any) -> sa.Column:  # type: ignore
        return prop

Added types ourselves to the base model like this:

    __table__: t.ClassVar[sa.Table]

    @classmethod
    async def _fetch_one(cls: t.Type[BaseT], db: BaseReadOnlySqlSession, query: Select) -> t.Optional[BaseT]:
        try:
            return (await db.execute(query)).scalar_one()
        except NoResultFound:
            return None

    def ezrelationship(
        model: t.Type[T_],
        id_our: t.Union[str, sa.Column],  # type: ignore
        id_other: t.Optional[t.Union[t.Any, sa.Column]] = None,  # type: ignore
    ) -> T_:
        if id_other is None:
            id_other = model.id
        return sqlm.Relationship(sa_relationship=relationship(model, primaryjoin=f"foreign({id_our}) == {id_other}"))


    def ezrelationship_back(
        id_our: t.Union[str, sa.Column],  # type: ignore
        id_other: t.Union[str, sa.Column],  # type: ignore
    ) -> t.Any:
        model, only_id2 = id_other.split(".")
        return sqlm.Relationship(
            sa_relationship=relationship(
                model,
                primaryjoin=f"foreign({id_our}) == {id_other}_id",
                back_populates=only_id2,
            )
        )

There’s TyepdDict that is decent for a JSON like data structure if the types are simple. It doesn’t have the bells and whistles of Pydantic, but gets the job done for passing predictable dicts around and ensuring consistency while developing

Pretty much anywhere you're tempted to use a namedtuple, you should be using a dataclass[0] instead.

And typing JSON-like data is possible with TypedDict[1].

[0] https://docs.python.org/3/library/dataclasses.html

[1] https://docs.python.org/3/library/typing.html#typing.TypedDi...

Mainly, the seems to be no way, in a dynamic language, to dynamically check if functions get the right types.

To me, this means I don't really understand the python type hinting at all, as adding hints to just one or two functions provides no value to me at all.

I assume I must be not using them usefully, as I've tried adding type hints to some projects and they just seemed to do nothing useful.

default values! Since type hints are *hints*, it is difficult to set default values for complicated types. For instance, if you have lists, dicts, sets in the type signature, without a library like pydantic, it is difficult and non-standard. This becomes even more problematic when you start doing more complicated data structures. The configuration in this library starts to show the problems. https://koxudaxi.github.io/datamodel-code-generator/custom_t...

The issue very much is a lack of a standard for the entire language; rather than it not being possible.