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...
* 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.