Around the web
Magic links—when a service sends you an email with a uniquely identifiable link, and clicking that link logs you into the service (typically on the web)—are an alternative to password-based authentication. Well, they're moving the problem of password management onto you and your email provider, just like OAuth2, OpenID, and many other passwordless authentication systems. Zitadel weigh up the pros and cons, and determine that there may be better alternatives for your application.
The answer to this question should always be “yes”. Not because of any specific beef with git, though I have those: I found mercurial much easier to use particularly in the common “star” topology that is also the way most git-using teams are set up.
No, I think in general we should be strongly committed to our values, very selective about the principles we abide by to uphold those values, and weakly associated with the tools and processes we use to work according to those principles. If we decide that we value “working software over comprehensive documentation”, that we will work according to the principle that “Simplicity--the art of maximizing the amount of work not done--is essential”, and that git, or Jira, or TestRail, or vim, or whatever, is generating work that we don't need to do, we should be ready to find an alternative.
While I'm on the “here’s a thing people do that there’s no evidence helps” thing, there’s no robust evidence in favour of TDD, yet we all do it and claim that it’s worse—maybe even unprofessional—not to do it. Myself included. Why is that?
It has come to my attention that people hating on Perl are still talking about Perl 5. It's understandable that they didn't notice Perl 6—it got renamed to Raku—but Perl 7 is "Perl 5 with modern defaults" and was announced two years ago. I happen to think that Perl is a nice tool, albeit "unopinionated" in the modern parlance, but if you don't like that please at least don't like the modern version.
Performance analysis? Analyse the performance of your application, not some microbenchmark posted by a technology evangelist!
Ken Kocienda on the anti-weak-typing shade. His experience that the type errors aren't the significant source of bugs is consistent with my experience (and remember that C-type languages had a way more expressive type-as-design language than predecessor languages), but I think this is probably because of the “decades” of doing it. Rather than the decades of experience showing that the type errors don't manifest.
I love dynamic programming and feel way more productive when I’m not fighting a compiler. At the same time I accept that e.g. Apple platform experience suffered from people looking at ObjC (or Google:Java) and thinking “no thanks, I’d rather write Typescript and React Native”. Both can be true.
The type supremacists definitely have the superior marketing, at the moment. It seems to be an easy sell: it is possible to have this bug. This tool stops you having this bug. Therefore this tool is best. Never mind that the people not using the tool don't, in practice, have this bug. In practice my most common ObjC bug (which Swift doesn't ameliorate, but SwiftUI does) was “forgot to connect outlet/action”, and that's something you write a test for once in
-awakeFromNib (the method that gets called when you “un-pickle” a serialised UI) then use in every project: because the language is dynamic, you can introspect your UI at runtime to work out what should be hooked up and whether it is. But that data isn't relevant to the “this could, in theory, happen” argument: you could in principle pass a
BrazilNut to a
Bolt because it expects to collaborate with anything that quacks like a
Nut, therefore all software is impossible in this system.
Extra checks to make sure my software isn't evidently wrong are helpful—and both computers and compilers have got so much faster over the last few decades that it's possible to have both a richer set of checks and a faster build, which is just amazing. Once those checks stop me doing good software design, and aren't optional, they are a hindrance.
And as Marcel Weiher argued back in 2014, static types often provide “safyness”, not safety. But not all of them also act as design hindrances. I find the progressive approach—particularly Typescript, which is designed with a sympathy towards the ways that types interact with software design—does a good job of pairing design liberality with comfortable safyness.