qwer

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.

I just finished something similar: http://caines.ca/blog/2018/12/11/a-javascript-to-typescript-...

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?

Sure... I guess you're saying that you can use the typescript compiler just fine as long as you turn off literally the only reason for it?

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"?

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.

If your types are wrong your program is wrong

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.

This sounds like an if-it-compiles-it-works argument.

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.

Clearly... but then again I won't work at a place with any developers less than 11x.

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.

Just slowly go to bed earlier every day. Set your alarm for your go-to-bed time. Read a book if you can't sleep, but not on a bright-screened device.

I used to be such a nighthawk that I'd be waking up daily at 7 pm. Getting old naturally fixes that too.

In that scenario I bet they're even more effective without the condescending "manager" adding nothing.

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.

It's because this is an article about engineering decision-making, not repo management.

I think you really did oversimplify it. Writing a piece of code once obviously affects your speed at writing it again.

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.

I find physical exercise gets me back out even easier than napping. It took me a while to figure that out, but it's been really helpful.

Relatively few, but they're everywhere -- Auto-pilot on airplanes. ABS brakes. Self-driving cars.

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

Come on... The article is clearly written for a general web dev audience (if not, please let me know the more specific audience you've inferred) and starts with this completely unqualified first sentence:

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.

This is just another article telling me about what I should do with my web application without asking me anything whatsoever about my web application. Just because you made a bad choice for your situation doesn't necessarily mean everyone else did too.

There are more words after that though.

Anything involving long-lived feature branches especially ones with multiple collaborators, eg git-flow.

I once wished this were possible too, but in reality it isn't.

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.

First off, I have no motive to be disingenuous. I really don't care how you collaborate on software with your team.

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.

Obviously if you can't break it up into smaller pieces, you can't regularly integrate smaller pieces. That's a tautology.

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.

Are you questioning the daily part (continuous) or the mainline part (integration)?

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 false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now.

Quite true actually! : https://en.wikipedia.org/wiki/Continuous_integration#Everyon...