The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load???
It’s just so endlessly easier to program with types
* 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.
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.
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 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?
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...
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.
Which languages are missing unions? Off the top of my head, they exist in C/C++ and mypy python.
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.)
Obviously I exaggerate a bit, but we've all seen various incarnations of a lot of those issues.
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.
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.
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 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.
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.
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 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).
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.
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.
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).