I think there are a few reasons why people develop an impression that types are overhead:

* People who are learning to code are writing lots of code but not reading very much code. I think types do the most work when trying to understand existing code.

* Lots of people's first experience with typed languages was something like C++ or Java back when they had much worse error messages.

* The kind of mistakes you make when first learning to code make the type checker feel like a pedantic nitpicker instead of a protective ally.

* Programming instruction tends not to teach technique very much. If you invent techniques that leverage the strengths of types, then great for you. If you don't, then you might program for years until you are exposed to the benefits types can provide.

Also, many beginner programmers work on small code bases in every sense of the word.

These days I will often have to glue together some tiny part of two or three enormous APIs, some of which are "auto generated" from some other system. Think LINQ-to-SQL or WCF.

It's amazing when you can take a 100 MB chunk of code, and simply "navigate" to the thing that you want using tab-complete, in the sense that "somefactory.sometype.someproperty.subproperty.foo" is almost self-evident when you press tab and cycle through the options at each step.

And then when you finally get "foo", if it's the exact unique type you were looking for, then you can be certain that you did the right thing! There's practically no need to reach for the debugger and start inspecting live objects. Just tab, tab, tab, tab... yup, that's it, move on.

If you're working with a "blank slate" PHP app (or whatever), where you've personally written most of the lines of code involved, typing can feel unnecessary.

If you're glueing together Enterprise Bean Factory Proxies all day, then strong typing is practically mandatory.

To be honest, I disliked PHP’s dynamic typing just as much as I disliked Java’s static typing, and that’s after spending over 10 years professionally developing primarily in those two languages (and some python and javascript).

The last couple of years I’ve developed stuff in haskell and elm, but I’m currently getting back into python and javascript. And I’m sniffing around, trying to figure out how to utilize typescript and python type annotations in an ergonomic way, that doesn’t feel like too much overhead.

I’ll easily admit that it’s not as easy to reach the same kind of benefit in those languages.

The magic sauce really is (ideally as global as possible) type inference combined with programming primarily via expressions instead of primarily via statements, with appropriate language support of course.

> If you're working with a "blank slate" PHP app (or whatever), where you've personally written most of the lines of code involved, typing can feel unnecessary.

> If you're glueing together Enterprise Bean Factory Proxies all day, then strong typing is practically mandatory.

Might that not be a problem, though? Shouldn't more software systems be small, elegant and well-architected rather than a spaghetti nightmare navigable only through an IDE?

I like types, I think they are great, I like editor tool, I think it is great. I even like a lot of the luxuries modern systems afford me. But … maybe we could stand a little simplification?

Have you seen the enormous scope of something like Azure Resource Manager? Amazon Web Services releases several new products or major features per day. They all have APIs.

Office and Office 365 is also a behemoth that covers entire suites of business products, front-end and back-end.

If you start to seriously talk about integrating these things with a bunch of third-party components, you're talking tens of gigabytes of binaries.

> But … maybe we could stand a little simplification?

Always. Unfortunately, that runs up against the limitations of our squishy meat brains. Especially when they're numbered in their tens of thousands. Simplification, refactoring, and code reuse requires coordination.

I too am horrified that a mere database engine no longer fits on a standard DVD disc... when compiled into a binary.

But I can download the ISO image in a matter of minutes, and use the system with a few button clicks in an IDE to produce functional software.

I know that the raw numbers should qualify as a nightmare, but at the end of the day, things get done anyway and it doesn't seem to matter that much.

I guess we're just horrified because we know how this particular sausage is made...

I agree with this 1000%. Projects (note not programs or individual source files!) are simply easier to grok (maintain, enhance, debug, refactor) with statically (and strongly) typed languages than dynamic IMO.

Five years ago when switching jobs I’d pursue “full stack” positions because I’d done a fair amount of front end dev in the past. No more, me personally, I’m backend all the way. Dynamic typing (vanilla js) is just harder; more time consuming more cognitive load, IMO.

It's not perfect, but TypeScript goes a long way toward making frontend feel as safe as backend. You still have the potential for weird bugs when interacting with external JavaScript, but your internal code is pretty safe. Also, TypeScript's type system is impressively flexible, and I often find myself missing features (like unions) when working with other languages.

> missing features (like unions) when working with other languages.

Which languages are missing unions? Off the top of my head, they exist in C/C++ and mypy python.

Typescript allows you to have literal type discriminators in their unions, which combined with control flow based type narrowing of unions effectively gives you sum types. That is what he is talking about, because most mainstream langauges don't have sum types and you need to go to strongly typed functional langauges (haskell, scala, etc...) or modern strongly typed langauges such as Rust to get access to such features.

Yes, this. Sum types in most languages are approximated by something like kotlin's sealed classes. Sometimes you don't want to declare a whole new class hierarchy, you just want to say "this function can either return this or this".

Here's my split personality:

I love love love Python for data science, in part because it's dynamically typed. I can bang things out quickly without worrying about the engineering bits, and, since I'm working in an interactive coding environment, it's generally easy enough to just inspect the values of my variables to figure out what they are.

I hate hate hate Python for ML engineering, in part because it's dynamically typed. The same features that make it so easy to hack out a quick data analysis make it absolutely awful to build for durability. For example, since stuff in production runs hands-off, you need to feel pretty confident about the return types of every function in order to feel confident you won't throw a type error at run time. Actually pinning this down can get quite complicated, though, when you're working with a library like scikit-learn that relies heavily on duck typing. Sometimes you end up having to go on a journey down a rabbit hole in order to clearly identify and document all the types your code might accept or return.

(Disclaimer: Hate aside, it's still my preferred ML engineering language. You've got to take the bad with the good, and the language gets you access to an ecosystem that is so very good.)

This is absolutely it. Untyped languages are great for glue-scripts, for exploration (of an API, a dataset, whatever), for quick-and-dirty things. As soon as your logic grows beyond "what can be appropriately expressed in <5 files" and/or "this is going to have a second developer", types become helpful.

I see it completely the other way around coming from the python, dynamically-typed side. For me, statically-typed languages have a benefit on the smaller-side of the scale, but absolutely bomb when the code-base grows. At that point everything is a FooFactory or an IInterface with no help from the IDE anyways because of IOC/DI/attribute reflection magic. And when it's that big, everyone argues over folder, package and inheritance hierarchies and the "right way" to refactor & reuse code, with the inevitable slide into yet another level of inheritance or interfaces. All the while peppered with Singletons, overloads and new abstract virtual base methods with complicated method override rules.

Obviously I exaggerate a bit, but we've all seen various incarnations of a lot of those issues.

The second you’ve “engineered” yourself into losing good IDE support half the benefit or using a strongly typed language goes out the window in my opinion. Though maybe some bias because I make an IDE! :)

Happily with TS it’s possible to have DI and IInstantiationService’s and all that and still maintain good IDE support —- in no small part because the IDE is built with all those, in TS... if it was unusable we’d fix it.

IMO dataframes are the reason why dynamic typing fits data science so well. It's certainly possible to represent a single dataframe as a static type; but representing all the slicing, column removal, joins, etc. is actually pretty hard without dependent tricks. So bypassing types for data frames is preferable. On your ML engineering point, the other side of it is that once your dataframe's schema is finalizes it really should be statically typed so that assumptions can safely be made about what is/isn't inside of it

> representing all the slicing, column removal, joins, etc. is actually pretty hard without dependent tricks

Disagree in the strongest possible terms, tbh.

It's the lack of static typing that gets you 3/4 of the way down your experimental pipeline only for your code to fail because column "trianing_batch" can't be found. Huge productivity loss, even with rapid iteration.

We must work very differently. I couldn't fathom that happening to me, if only because I compulsively peek at samples of the data frame every step of the way, in order to make sure the data look reasonable all the way through.

As helpful a static type system can be, most of them do cause increased cognitive load UNTIL the FIRST RUNNABLE VERSION. Having your code running for the first time is rewarding for devs, especially those who are handling many simple codebases rather than few complex ones.

There are great type system that provide enough ramp for for first runnable version. Rust, for example, has type inference and an unusually helpful compiler.

But most languages, especially the old ones, don't have that. Because of that, coders need full-blown IDEs like Intellij/VS to write comfortably in those languages. Without full-blown IDEs or editors packed with plugins, it is quite a chore to navigate types. There's no hyperclicking, type annotation, docs preview. While dynamic-typed languages usually is runnable since the first character without having to wait for the compilation, so even notepad is acceptable to write with (though that would be really painful).

Having been in both sides, I love types in certain languages (and disdain them in others e.g. PHP). I would still pay the price of compilation and use TypeScript for scripts that lives long rather than using JavaScript. But I think both sides need to understand where the cognitive load arguments came from.

I love types.

I just didn't when I was new to programming. I learned Python because that's what I saw pitched to me all the time. There was a local Python meetup, MIT's CS courses taught Python and Udacity eventually taught Python. I loved the language and learned quickly how to do a bunch of basic stuff

But I wanted to make Android apps and, ugh, Java confused the crap out of me. It wasn't so much the language, but rather "URI? Where in the world do I get one of those?! Oh, you instantiate a URI with the string. In Python this is just a String..."

Or another time, once I had mastered types, I convinced my Javascript team that Typescript was Worth It. And the ensuing chaos when nobody understood how to use Types and nothing would ever compile for anyone.

All SUPER noob-y mistakes. All because I (or my team) didn't understand how to think in Types. Furthermore, people who can Think in Types often don't know how to articulate that thought process to others.

I'll also throw out there that scripting languages w/o types tend to have a lot less tooling around the language. People are used to being able to type whatever they want and things kinda just work.

Typed languages are very different. The tooling is far more robust and more able to point out errors, but also tends to be more complex than just a simple text editor.

This is changing with VS Code and LSP being a thing, but it still influences those communities in fundamental ways.

(Sorry for being a bit too aggressively argumentative in this comment)

(It turned out to be a productive comment despite the aggressive wording, so upvotes!)

I agree.

And you also see many dynamic languages working around lack of types by describing the types anyway in the documentation. Like jsdoc in javascript before typescript became popular.

You are already doing the hard work of describing your types anyway, but because your compiler doesn't know the types, it can't help you out.

There’s a continuum for sure. Type systems have their own kind of cognitive load, because you have to learn them, how to model your invariants in them, how to understand error messages, avoid common pitfalls, etc. Type systems are usually quite “general” and abstract, and that always comes with cognitive load. Quite often reading the code of a parametrically-polymorphic Python function is way easier than understanding the generalized polymorphism constructs of an advanced static type system.

There are times when the cognitive load of a particular static type system is less than that of a dynamic one, for certain classes of programs and audiences, and times when it’s not. This is fine and we should encourage development of both kinds of type systems and a shared understanding of how to pick the right ones for the job (which is a discussion nearly always missing in these debates).

For the most part this cognitive load already exists in order to write correct programs. Types don’t just appear when a type checker is present. Type systems only add on the additional burden of needing to understand the formalization of that intuition. It’s not an insignificant burden, but it’s a much smaller gap than learning to intuit about programming correctly in the first place.

It depends on what you mean by "correct". If it means "it does what I need it to do and I can move on with my life", then no, the cognitive load doesn't already exist, and formalized type theory in many cases adds an incredible amount of cognitive load.

I know that in many cases "correct" means a lot more than that, such as in proper software engineering contexts when building a program/system that needs to live and evolve for a long time among many people. I write that kind of software all the time, and I always use static type systems for it.

But I also write a bunch of ad-hoc, one-time-use programs, and I'm very glad that I don't need to reason about abstract type theory in order to parse a CSV file and add up some columns to send to a colleague.

No one is talking about abstract type theory; we’re talking about the intuition you use to write maintainable, correct software including CSV munging.

I don’t care if my throw away CSV munger is formally safe/sound or maintainable. I care if it gives me correct results, once, as quickly and effortlessly as possible. Which is why very few people fire up GHCi/rustic/javac for that, but instead use awk/shell/Python or something similar.

OTOH, sometimes the CSV munger one writes today is still in use five years later, when the input CSV has a UTF-8 character for the first time, and suddenly it crashes and no-one knows where the bug could even be.

UTF-8 support is completely orthogonal to static typing. There are dynamically typed languages that handle it great, and statically typed languages which have garbage support for it.

In general I know what you mean though. “What if this CSV parser turns out to be really important?” If you think there’s a high probability of that, do it in a statically typed language then. 99.9% of data munging I’ve done have been throwaway programs to answer a question to inform some decision or help refine a mental model.

Frequently that answer is important and you want extra confidence that you calculated it correctly.

I don't buy this "choose the right tool for the job" thing. I'd always advise you to choose the tool that your company has the most knowledge in. If there's a problem that cannot be solved in that programming language, then you can look for a better tool. But you shouldn't pick a language that nobody else understands, just to save a few lines or some time when doing the initial implementation - just to realize that you now have to constantly keep up the knowledge to be able to support it.

I consider that one of the most important criteria when picking the right tool for the job (if you're writing something to be maintained by other people in a company).

Okay, maybe. But usually this is not part of the description of "choosing the right tool for the job".

> It’s honestly embarrassing to hear all the worthless arguments against types.

I think this forum is written in a language that doesn't have types. My favourite though was lambda-the-ultimate.org, at some point the number one resource on the internet when it came to discussing about programming languages (maybe it still is, I haven't followed it for a while), which was written in an untyped language, PHP (Drupal, to be more exact).