Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.
> Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.
I see static types as one of the most powerful communication tools around, as far as code goes. I can't relate at all to people complaining that they waste time. They must work very differently from how I do, is all I can figure. It's that, or they don't realize how much time they're losing to communication-related tasks, or refactoring, or writing (and maintaining!) extra or more verbose tests, or having even one more bug per year make it to production, or whatever, that'd be saved by static types, so aren't correctly accounting for the time savings. One of the two.
Consider these 4 possible combinations for programming languages:
(1) Low-level, static types
(2) Low-level, dynamic types
(3) High-level, static types
(4) High-level, dynamic types
For whatever reason, historically #1 and #4 have been most popular. C, C++, Pascal, Ada, and Java are #1. Python, JavaScript, Perl, and BASIC are #4.
There haven't been a lot of #2 or #3 languages. Some #3 languages (TypeScript and Python with types) have come along, but relatively recently.
A person who experiences only #1 and #4 might notice that they can whip up programs faster in a #4 language than in a #1 language, then falsely attribute that difference to the static types. Whereas the real reason is working at a different level of abstraction.
That would be a good point if you actually could write the final code for CPU's, but you can't since the CPU internals do that for you. So from an application programmers perspective machine code is as low as it gets and C maps really well to machine code so C is a low level language.
> So from an application programmers perspective machine code is as low as it gets and C maps really well to machine code so C is a low level language.
C only "maps really well" to PDP-11 style machine code. If you want SIMD, parallel algorithms, heterogeneous programming, memory hierarchies/domains, etc then ISO C is completely useless.
Exactly. IMO we still don't have a good #3 language - in particular, all of the popular languages that can be compiled into native code are in category #1.
I can remember that in the beginning it felt cumbersome to me because I wasn't all too familiar with that language's type system and so I had all kinds of errors thrown at me.
But it's something you just have to get used to, and now that I understand it much better I feel more productive and have more confidence in my code. And the communication aspect is definitely a great help too. No handwritten documentation can be this consistent, completely independent of who touched the code (though to be fair, it's still difficult to get the naming right).
I can't imagine the people calling it a waste of time got over the hump in the beginning. To me it's obviously a timesaver. It does a tedious, difficult (for humans) task and does it quickly & with perfect accuracy. Beforehand worrying about all the type signatures and interfaces felt like 4D Sudoku across various modules, now I can concentrate on the interesting parts.
I've been a types advocate for years, but it wasn't until working with Typescript that I started experiencing some of the downsides...
To me, ideally, types are supposed to be a benefit not only in safety, but in understanding the intent of a piece of code more quickly. For an api or library interface, review the types to see what its intentions are.
But there's something about the typescript type system, with all the picks and keyof and typeof... sometimes it just feels like it's way too easy to go overboard, to the point that it occludes meaning. I understanding struggling with types if you're struggling with figuring out exactly what your boundary does and does not allow, but when you're struggling with types just because you're struggling with the kabillion different ways that some other typescript programmer chose to use the utility types... there are times when I feel like even Scala is easier.
The problem is that typescript is here to type existing JS, and existing JS has been written without thinking about types. "fresh" TS might be better for that.
Depends of course a lot on the codebase but all typescript codebases that I've seen so far and considered "well-maintained" didn't really use keyof and typeof all that much. The only way I can imagine how one ends up with lots of those keywords is when you start with a dynamic language approach, and then tell the compiler afterwards what that type might be, instead of defining the type beforehand - might that be the issue?
Your criticism boils down to "it's possible to overcomplicate things". Sure if you completely remove static typing then you can't overcomplicate static typing. But is that really an argument against static typing?
No, and I am still in favor of static typing. But I also don't think it's purely up to team discipline. Something about typescript (or more aptly, javascript) incentivizes crazy typing more than other languages. Luckily, the last few years appears to have had more emphasis on designing languages to take these kinds of incentives into account, so I still think the future is bright.
> is a huge help in understanding code you haven’t worked with previously
This is huge for me. As someone who takes on already completed projects, it's a huge help with debugging and understand what's going on without requiring you to know the whole system forward and backwards. Sure, you still need to build a mental map of the general code flow, but you can look at a single function and clearly see the obvious inputs and outputs. Combine that with a a stack trace and you can debug that method as a single unit and then start to look at where it's called and what its downstream effects are. You don't need to start from the very beginning of the call and then follow it through, keeping mental track of what is available and in what form when and where.
It is kind of ridiculous not to have types. I think in the old days handling types felt to heavy for scripting languages, but now with type inference and stuff I don't think it is any longer.
Both of those languages' communities have essentially admitted that not having type checking was a mistake and try to patch it with TypeScript and MyPy.
I see static types as one of the most powerful communication tools around, as far as code goes. I can't relate at all to people complaining that they waste time. They must work very differently from how I do, is all I can figure. It's that, or they don't realize how much time they're losing to communication-related tasks, or refactoring, or writing (and maintaining!) extra or more verbose tests, or having even one more bug per year make it to production, or whatever, that'd be saved by static types, so aren't correctly accounting for the time savings. One of the two.