It's in the blog post, but more were created by the transition than removed. There were less than 10 issues found and none were anything that users were concerned about.
We opted to keep it strict (no implicit `any`) through the entire transition but only apply it to ts files, so we are indeed completely free of type errors now. We only have 50 cases of (explicit) `any` in 85K+ LOC and they're in type def files.
Let me be the first person you've met to doubt the value of the type system. I do like the in-editor support, but you pay for it with about 25% more code.
I'm certainly not advocating undoing it, but I personally wouldn't do it again (though the team has mixed opinions).
> I'm confused how people can advocate TDD and not like static types too seeing as static typing gives you robust automated tests for the minimal cost of adding type annotations every now and then.
For me personally as a TDD person, I just don't care about testing types. I test values. The type-checker just doesn't do much that I actually care about (better in-editor support is nice though). I know it's not a fashionable answer these days, but for me it's true. I don't see the pay-off in doing both, and types alone are not enough.
I don't know where this misconception started, but you can't just run javascript through a typescript compiler. There is a huge amount of valid javascript that is not valid typescript. Try something like `const testVar = {}; testVar.asdf = "asdf";`. Node web frameworks, for example, are based entirely off this ability to monkey-patch the request object.
Well let me first remind you that you're in a javascript thread. OO Pascal is strict enough that you're not going to get the opportunity to see things work when they get types that they didn't expect because the compiler is unforgiving. So that's going to be hard for you to imagine, but it happens in javascriptland. A function in javascript meant to take a number to output "X hours ago" could very easily get the string "3" and still do exactly what the user expects. That's what I mean by an incorrect type that is internal only, and not a user-facing bug. This is an overly simplified example too. With duck-typing you can often get away with all kinds of not-the-type-that-the-method-expected and live to tell the tale.
I haven't touched OO Pascal in 15 years, so I can't speak to how you would write tests for it, or if there's even a testing framework. I will tell you that I left the if-it-compiles-it-works attitude around that time too though.
That's not necessarily true though is it? If the "1" in the "1 hour ago" message in the header of your reply wasn't the expected type of the writer of the output function but ultimately still shows up as "1 hour ago" to the user, there's no user-facing defect. I can promise you that this happens all the time in javascript. You're in a thread about Javascript.
> have you ever tested what happens when you pass "null" into a function
Not that I recall. Javascript will throw an appropriate error when it detects that your duck isn't quacking correctly. No one writes validation logic everywhere on internal units, so there's no functionality to verify with a test.
With that said, null is decidedly not "just a type". It's also a value. I generally avoid using null everywhere as much as possible too, because it's a pretty terrible concept.
> Some type systems allow you to even specify valid subranges of types, and combined with algebraic data types, it's effectively impossible to misuse.
Sure but you're in a thread about javascript and typescript. And let's be honest: the vast majority of type systems do not support that.
Well don't lose sight of the goal. The goal is less bugs. Static typing is just for internal quality. Users don't give a rat's ass if your types are correct as long as the program works. Proof: Many wildly and massively successful programs are duck-typed.
Nobody ever cared to use tests to replicate what a type system does. That's a straw man. Tests go straight for the actual goal by testing actual values. Correct values are what are necessary. Types on the other hand are neither necessary nor sufficient.
> the easily observed phenomenon that some developers are 10x more productive than other developers.
How are you measuring? LOC? Semi-colons per hour? story points? If you're measuring in "dollars earned", how do you think their managers are measuring? And can they tell the difference between a 10x programmer and an 11x programmer?
I wouldn't have noticed if it hadn't been pointed out but it's definitely a term for a pretty outdated female-only position so I think the point isn't so extreme.
I can almost never detect this kind of stuff because it doesn't affect me directly and I'm sure the dev meant no ill-will, but once pointed out, I can see how projects named like this would get under people's skin.
"made, the MArkDown Executor"? :D It's pretty easy to be more inclusive.
I know this goes against the usual attitude about remote work around here but...
That flow-chart at the bottom is hilariously true. I've been a part of remote work as both a manager and an engineer, and this is exactly how it is because of different locations, the lo-fi aspect of existing remote collaboration tools, and the activation energy required to communicate more often (and if you're in different timezones, good luck to you!).
If you're an engineer that wants to really understand what you're trying to build and why, or if you want to be part of the problem-identification stage rather than just implementing someone's specs, this type of arrangement will drive you insane.
Some engineers are perfectly happy with a detailed spec though. For them, I completely understand the lure of remote work.
I think it's more nuanced than that and one can consistently hold both viewpoints at the same time. You just need to have the experience that a soa-first approach is even worse than the ball of mud.
I was a CS TA 20 years ago and it was the same. Literally everyone was doing it to some degree.
Back then you would hand in printed source code. People would occasionally photocopy someone else's, scratch the name off the title page and write in their own name like I wouldn't notice something that stupid.
I actually caught some phd students in some cheating that was almost as blatant.
The professors generally don't care either. The whole thing burned me out pretty quickly. I realized the school was just full of a bunch of people going through the motions, and CS degrees don't really indicate any particular expertise on their own.