I don't think there's a time I can remember when Norm Abram (probably now one of the greatest or at least most prominent carpenters of a generation) ever mentioned the particular tool brands he was using.

And looking back on earlier seasons of This Old House, he was hand-nailing thousands of nails a day (nowadays he and everyone else often uses pneumatic tools for this).

I'm sure he prefers a certain brand, but unlike popular YouTube personalities and more 'celebrity' builders, he isn't a brand ambassador for Craftsman, DeWalt, Milwaukee, Ryobi, etc.

But yeah, when you talk about 'builders' (the more common carpenters you encounter on most job sites), it seems like most of them will die on a sword defending whatever brand(s) they've sunk a fortune into.

I'm a DeWalt guy, mostly because I invested in a 20V Max drill a long time ago and have a ton of batteries for all my electric tools now. But I used to use Makita before switching systems. I wouldn't call myself a master carpenter by any means, but like AvE, I find good and bad in almost all the 'top tier' lines from tool manufacturers.

You want it written in C for a 16bit bargain basement ALU? I can do that. You want two implementations, one in Pascal and the other in PHP? Not a problem. You want my advice? No? That's fine too, the advice is expensive and who knows after all these years if it's even worth anything.

At my first job we used to build some hydraulic models in hard wood that where works of art.

Our wood shop was so good they made a museum quality piece of furniture for our retiring boss and it was better than the best Chippendale furniture when new.

I do like the grips and ergonomics of some brands more than others.

The one piece of concrete advice I got was “Whatever brand you get, go for the 20V, not the 12V”. Last week I saw that same guy at work showing off his 12V driver. So I’m pretty sure nothing matters, and I’ll probably just get the brand with the prettiest color.

The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it.

“Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.

That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.

There are many maintenance mode projects where the switch to 3 represents absolutely no upside and is all downside risk. Not everyone is developing web apps in constant flux that are exposed to the Internet. That is a tiny fraction of python’s use cases.

A security system and fire insurance is at most around $2000/month, and it's a cost that is understood and often required by law. Diverting a $100k+/year employees to spend their time on tech debt is quite a bit more expensive.

Companies rightly try to minimize time devoted to tech debt.

If you built software using Python 2 at any point in the past 5 years, you have no right to complain about the added technical debt of updating to Python 3. But not wanting to incur that technical debt in the first place would also have been a good reason not to use Python 2 in the first place; whether that means adopting Python 3 early or simply using a completely different language.

Congratulations. You're fired.

"Hey boss, we're using an outdated programming language for which security updates are no longer provided, because we were told there's no budget for fixing technical debt."

"Congratulations, you're fired."

Same outcome either way... might as well make some effort to do the right thing along the way...

People will continue to use py27 going forward with likely a pay-for-support runtime because that’s cheaper and less risky than changing a million lines of python code.

Like it or not, there are a lot of teams that choose to incur technical debt to avoid what is seen as needless work on something that is working fine at the moment.

Python2 will almost certainly still remain in widespread use and it will still get security updates through alternative distribution channels. It's not that much work fixing such relatively rare issues versus migrating a major codebase.

But hey, if some 3rd party group effectively forks the language and maintains a Python2 branch after the official EOL date, good on them. But I'd argue that using that is risky in the same way that using a Pale Moon or Waterfox is (arguably) riskier than using mainstream Firefox.

For what it’s worth, Perl 6 can load Perl 5 libraries: https://github.com/niner/Inline-Perl5

Python3 broke compatibility for spurious reasons. The language didn't change that much, it could have kept compatibility with minor concessions.

> Java or COBOL maybe have done a better job of not breaking backwards compatibility...

Literally every single other major language has done a better job at it. That's a big part of why they are major languages. Also, most of these are statically typed, so any minor breaking change is far less risky to pull off.

> ...but Python 3 isn't exactly Perl 6 here.

Well, maybe if Perl6 didn't happen Perl wouldn't be irrelevant today.

C++'s upgrade woes make Python 3 look downright trivial in comparison.

If you're talking about ABI breaking, that's a different story. Python breaks the ABI in every major release as well. That generally requires a recompile, not a major code migration.

Security through obscurity, baby...

Every non-tech business that maintains technical infrastructure finds itself doing that kind of tech-debt work regularly (if, often, chronically behind the vendors recommended schedule) for every platform they use Py2 to Py3 may (or may not, really) have been a bit more painful than a (multistep, because those types of shops never do it timely enough that a single-version-bump makes sense) .NET framework, Visual Studio, SQL Server, and Windows Server upgrade (and, yeah, those often happen together as multistep upgrades in slow enterprise shops), but it's not a fundamentally different kind of problem (and replacing dependencies that didn't make the same upgrade, often because they were abandoned years before the firm made it's upgrades, is often a part of that.)

The thing about debt is that ignoring it doesn't make it go away magically. If business relies on tech for crucial functions, it's only a matter of time before debt comes due.

If you don’t push your clients/employer to have room in their budgets for these types of things, you are the one being naive.