willseth

Read more carefully

It literally doesn’t matter unless it impacts users. I don’t know why you would waste time on non problems.

You gauge with metrics and profiles, if necessary, and address as needed. You don’t scrutinize every line of code over whether it’s “reasonable” in advance instead of doing things that actually move the needle.

Sorry, you’re not allowed to discourage premature optimization or defend Python here.

Then you should have written that. Instead you have given more fodder for the premature optimization crowd.

Good callout on the paper reference, but this author gives gives every indication that he’s dead serious in the first paragraph. I don’t think commenters are confused.

Knowing that an empty string is 41 bytes or how many ns it takes to do arithmetic operations is not general knowledge.

Sometimes it’s as simple as finding the hotspot with a profiler and making a simple change to an algorithm or data structure, just like you would do in any language. The amount of handwringing people do about building systems with Python is silly.

Every Python programmer should be thinking about far more important things than low level performance minutiae. Great reference but practically irrelevant except in rare cases where optimization is warranted. If your workload grows to the point where this stuff actually matters, great! Until then it’s a distraction.

It doesn’t. You’re welcome to do your own research to confirm

“We didn’t have the expertise to build the thing we were building, got in way over our heads, and built a basic POC using legacy technology, which is fine.”

On a trumpet? A clarinet? No, the motions don't simultaneously overlap. The fingering mechanics are slightly different at speed, but you would still start slow while using the higher speed mechanics and tonguing technique, not jump into high speed practice first.

Depends on the instrument. For wind instruments, the motions basically don’t change, and your focus is on synchronizing your mouth with your hands. Tonguing technique is different at high speed but you would typically practice with the same technique at low speed when learning a fast piece.

What’s wrong with Matter?

"[Y]ou're welcome to fork Chromium or Firefox" is the software developer equivalent of saying "you're welcome to go fuck yourself."

It's true that there are security issues, but it's also true that they don't want to put any resources into making their XSLT implementation secure. There is strong unstated subtext that a huge motivation is that they simply want to rip this out of Chrome so they don't have to maintain it at all.

The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.

This is staff, principal, or even EM scope at many orgs. I have never seen anyone with a senior dev title directly managing juniors.

Maybe you were just bad at management and didn’t know it.

You were supporting the tail end of an era that is universally agreed upon as an ecosystem failure. The internet didn't provide a consistent user experience for developers or for users, it generated mountains of legacy baggage, and it was frustrating for everyone.

Ideally, sure, but that would increase the already enormous burden of building a standards compliant web browser. For a healthy web ecosystem it's important that not only trillion dollar companies can contribute or compete.

I think the main reason you see overwhelming support for anchors is that the existing Actions functionality is typically so cumbersome to implement and often makes it harder to understand a workflow. Anchor syntax is a little esoteric, but otherwise very simple and grokable.

YAML anchors may be a sharp tool but no one is forced to use them. I have written many verbose Github workflows that would have benefited from using anchors, and I am relieved to learn I can clean those up now.

Our vet told us it is far more important that house cats get exercise than any potential frustration caused by a laser pointer.

AWDL isn’t FindMy. It’s mostly for Airdrop and also uses Bluetooth for the initial connection then switches to WiFi for high bandwidth data.

I’m not sure it would since the whole Bluetooth stack is already designed for P2P. Apple’s network is a true mesh though and not point to point. If you share locations with your friends on FindMy using iPhones or AirTags you will get updates via the encrypted mesh network (that includes other peoples’ iPhones) without being connected to a WiFi or cell network.

https://support.apple.com/guide/security/find-my-security-se...

The FindMy network is already doing this at scale with location data. Offline messaging might be too niche of a use case for Apple but surely they’ve considered it.

Why wouldn’t you just Google instead of repeatedly insisting on things that are wrong?

https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE

You keep making assertions and generalizations without backing them up with anything concrete while simultaneously moving goalposts. In the cases where you do, you’re just wrong: XSLT is not held back by licensing, it doesn’t “require one liners”, and it has supported JSON since 3.0, which has been around for almost a decade.

You are misinformed about license cost, as I’ve already explained in multiple comments.

Hard to integrate in what way? XSLT is a language focused on several things that it’s very good at but it’s not intended to replace Python or be a general purpose language. Yet there are many common data related tasks where a messy and hard to maintain pile of imperative code can be replaced with a simple XSLT.