Surprised "jump flooding" hasn't been mentioned yet, which is the common technique to accelerate this sort of thing (used for color fills, signed distance field construction, outlines, etc.).
As a previous Qt user, I never got on the qml train and stayed firmly in widgets land. Declarative uis work well, until they don't because of custom requirements, and then they simply get in the way. They are harder to debug and understand from a code perspective. Not everyone writes apps that target both desktop and mobile.
I mean, you joke but that's actually fairly true. P4 users always notice when the central server goes down because you can't reliably look at changelist history, draft CLs, and do a host of other operations that are possible on git locally. (using a central VCS confers other advantages of course).
Yea that's a fair rebuttal. At higher ELOs, you start to develop a sense of paranoia about the King. For example, opening the center before castling feels very wrong intuitively, and in this case, pinning one of your few remaining pieces against your own King with an envelope of only two pawns is one of those "maybe I should be concerned" types of scenarios.
I'm sorry but there was a lot of jargon thrown around and circumnavigating standard problems in data consistency but no real takeaway or upshot. Felt like a chatgpt article
It generalizes easily. The main difference is the construction of the Laplacian matrix, which won't be symmetric in a directed graph, but you can still do spectral analysis and standard matrix derivatives, diagonalization, factorizations, etc.
The hash table solution permits an O(n) average solution if you change the hash function to be one that is incrementally computable (most are). Probably way faster than a trie of your entire corpus also...
This isn't an argument. By this logic, you could just as easily say that in the future, people will look back and scoff at the amount of time and energy wasted chasing a form of decentralized currency rife with problems that would never be solved at scale. You can't presuppose a conclusion and then extrapolate from it.
Pretty interesting actually (just skimmed through some of the higher level ideas, have bookmarked for later reading). Is there reference code available also you can share? Thanks for sharing!
Err, tray icons? Filesystem access/watches? Registry? Process API? Native plugins? If _every_ Electron program you use could strictly be a PWA, that says more about your usage than Electron itself.
> I think it's interesting that via Ethereum, I can spend Ether to perform distributed computations on nodes across the globe and that this also serves as a store of value.
I find this "value proposition" highly dubious. You can already rent compute globally and perform computation in an environment orders of magnitude faster than on the EVM. Distributed compute on its own doesn't confer any points as a "store of value." The nature of the compute needs to be something that can be done strictly in the blockchain domain, and as we've seen, the result is a system that's easy to manipulate by spinning up new shitcoins, insider trading, wash trades, and worse - not to mention the loss of privacy given how effective on-chain analysis is. The features that make up a cryptocurrency make it decidedly unsuitable as the basis of a modern financial system. Some of the underlying principles are "neat," but that's as far as the tech goes for me.
I work with realtime graphics. Thousands of things are indeed happening every millisecond and I sure wouldn't want a new hire blindly instrumenting those things just to "see if they happen." There are appropriate tools to measure performance at this granularity.
Recording a metric is not a cheap operation in many contexts. I work with code we typically instrument at a microsecond to millisecond granularity. Sampling profilers typically record instruction samples at most every 200 us or so, so adding instrumentation at a finer granularity than this has a dramatic effect on performance. If a game operates at 60 fps, adding a metric at an inopportune time will render the game unplayable.
No, I haven't been on teams that dysfunctional. These restrictions are born out of necessity. My point was that you seem to have a somewhat narrow view on software as a whole, and you are extrapolating from your personal experience general advice that simply doesn't apply.
Imagine a metric firing on something that happens a 1000 times a millisecond. Imagine a metric firing in a way that grabs a mutex at an inopportune time that creates a deadlock. Imagine a metric firing that suddenly spams your metrics server with data that nobody except you cares about in this one temporal moment. There are so many reasons this is a bad idea. If you must do it, do so locally but there are so many easier ways to determine "if something is used."
"Cleanup tasks" will always be appreciated I am sure, but again I would caution that there is a trap here. It's easy to clean up any number of things as you go, and construct an illusion that somehow, you are being productive.
When I hire people, aside from fixing mistakes in the documentation they encounter, I want them to have all the time they need to learn, ideally with a set of curated onboarding tasks that progressively give them expertise in the system they are intended to operate in. There is a time to "make things better" and, in my opinion, that's after getting up to speed in a sense that lets me collaborate with the team in a productive manner. I won't begrudge someone the opportunity to clean things up, but each individual is the ultimate arbiter of how to be effective at the end of the day.
Lol yes agreed completely. "Cleaning things up" before you understand the domain, codebase, and gotchas sounds like a highly unproductive way to get onboarded. I think suggesting that a new hire start week 1 by adding a whole bunch of metrics that add unnecessary overhead for the team and all users just to see "if something happens" is pretty bad advice, to the point of being something I'd probably wish I had screened at the interviewing stage.