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.
102 karma · joined December 12, 2007
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).
Just curious: What's your test coverage like?
Have you been on a team that adequately managed a list of thousands of warnings, always finding and fixing just the ones that are "important"?
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 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.
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.
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 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 used to be such a nighthawk that I'd be waking up daily at 7 pm. Getting old naturally fixes that too.
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.
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.
"Releasing early", in the sense of getting these things into the real world as early as possible so they can be iterated on with real-world data is actually pretty crucial if you think about it.
Before self-driving cars hit public urban areas, self-driving trucks have been working on private mining roads (https://qz.com/874589/rio-tinto-is-using-self-driving-416-to...). Auto-pilot on airplanes can still today be turned off or on as desired.
The key here is figuring out how to release gently. The greater the risk, the more iteratively and more gently you should be releasing. If you were building landing gear controllers for passenger planes and your plan for release was to spend a really long time planning really carefully, testing like crazy in non-real-world conditions and finally doing a world-wide, all-commercial flight roll-out at once, I'm likely to pass on air travel for a while (and keep a lookout overhead).
When people talk about releasing early, they're not talking about big bang releases at all. There are alphas, betas, feature toggles, a/b tests, and dark paths for a reason.
> Let’s get straight to the point; choose an SQL database for your web application. I think I can’t make my self clearer.
Yeah there is better qualification later, but there are whole paragraphs of railing against nosql databases for all kinds purposes that they actually CAN make sense in, for certain applications.
With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a single team-blessed deployment artifact that can automatically be promoted for manual testing or release.
Don't get me wrong, feature-toggles are indeed a pain in the ass, but in my experience cherry-picking branches to merge really is much much worse.
Secondly, CI itself is considered a best practice. I don't know how you could expect wikipedia to mark it as anything else?
Here's the top link from google if you really care to learn and aren't just here to be a contrarian: https://www.thoughtworks.com/continuous-integration . There is a wealth of information on this subject that I promise all says the same thing. We can argue about whether or not CI is useful, but the practice of integrating continuously is in all the literature as well as the name itself.
With that said, I've been doing this for over ten years and haven't come across that scenario. You can easily figure out all kinds of tricks to break things down, but usually only after you believe in the value of it.
I'm also interested in your better source. Every book I've read on the subject and the top 4 search results on google say the same thing.
Quite true actually! : https://en.wikipedia.org/wiki/Continuous_integration#Everyon...