jimminy

It's just a "jobs" advertisement for a YC company, which has been a perk of YC for 15-ish years.

All such YC company job advertisement posts also show up if you click the jobs section at the top of the site.

I do find it a little odd all the comments in this thread are focusing on it as though it was a straight telemetry/metric decision.

From the update, this feels more like it was problem area for maintenance purposes, then had its telemetry assessed for decision.

"The data pipeline that powers the page has historically proven problematic to maintain and so given the low usage, we decided to switch off the Trending page."

The maintainers likely considered the resources and effort in maintaining it were too high. When they looked at the telemetry and saw it wasn't utilized considerably, they assessed it was better to cut it, than keep it or create an alternative.

If it didn't have a cost associated with it, it would likely have never become a target.

Yeah, my example was bad. I was more trying to point out that determinism of the intrinsic action is a pre-condition to the idempotency, in order to make and verify the assurance required.

You could easily split the deterministic action, and comparison/verification against existing state into two different Pure functions. Being able to perform the verification separately is valuable for addressing the "at most once", "at least once", and "exactly once" assurance described in another comment in this the thread.

I was casually opening my scope up to the outer state, in the example, to express the "assurance" portion of the definition. But you're correct, it's an erroneous example that doesn't pass the more rigorous definition of Pure Determinism, when applied the local scope of the function.

It's not really uncomfortably close to determinism, it is baseline deterministic which is necessary for the verification. The powerful part of idempotence is that it's deterministic + a verified assurance "as if we run it only once."

Deterministic (but not idempotent): send_message(id=1, body) without verifying the state of id, could result in the message being received multiple times.

Idempotent: send_message(id=1, body) would verify that the id token hadn't been consumed, before acting, thus only allowing the message to be sent one time.

It was mentioned in the third paragraph, just not expounded upon further.

"Patryn, who changed his legal name twice, was the co-founder of QuadrigaCX, a Canadian exchange that shut down after Patryn's partner Gerald Cotten suddenly died in India in 2018 while owing users around $190 million in crypto at the time’s exchange rate."

Pop Netflix back in there from the FAANG, and you have MAMANA

These days I look up individual features, and use the date-relative view, to assess how long it's been available. Normally I'll start porting features once they're solid across the main browser set, but with a polyfill or some alternative based on feature detection.

I held off on delivering ES6 native until 2017-2018, and used mainly Bable or sometimes hand written polys up to that point if I wanted to use features from cutting edge. There's some influence from your user-agent analytics as well to determine if there is a meaningful regression to leave people behind.

5 years is just the rough grasp, sometimes the new features are worth integrating sooner if they provide actual functional improvements for users. Generally, syntactic sugar is given less precedence especially when it would negatively impact usability of the product. Saving a few hours for development is far less valuable than saving even a few hundreds of users hours of frustration.

As someone who started doing web development in 2003-2004, I've always aimed for a 5 year support window. This is largely because of how long IE6-IE8 upgrades took for many SMB's and governments to upgrade from in those days.

Back then browsers updated closer to 2-4 times a year, with far lower inertia in how drastic the changes would be. You could learn and mostly remember what features were safe for roughly that period. These days, I tend to look at feature release dates and support on CanIUse or MDN, to see if somethings been in broad use for the past 4-5 years.

It seems like an unusual rephrasing of the saying "reasonable on the face", which means "reasonable upon first appearance, without considering deeper aspects."

It's judging a book by it's cover.

This already kind of existed prior to the pandemic'.

If you bought premium tickets to a show, often you would get placed into VIP list with the venue and/or artist. Venue perks included contact with a VIP manager that could help lock in seating pre-sale, occasionally get discounts, if you asked, and other perks.

It's in the venue's interest to KYC and maintain these higher value relationships. And if you don't patronize them for a period they'll stop reaching out or providing access.

'Might still exist, but my experience was prior.

Yeah, I think the author focused a bit too much on structural pattern matching being a replacement/alternative for if...elif blocks.

It will be much more useful as an alternative to dispatch dictionaries, which are more a side-effect of the language lacking any case based control-flow.

This is the correct answer and is actually somewhat visible if you also look at the DJIA and NASDAQ figures.

The S&P 500 and DJIA are limited to a fixed number of corporations. The NASDAQ is allowed to expand it's number of listed companies over time.

If you look at the NASDAQ figures it's able to show considerable and relevant growth, as more companies have listed. (Still not at 2000's peak, but much closer than the S&P or DJIA.)

The speed of computing a path from vertex to vertex is faster than trying to generate a point at X distance for the pathing object.

So you give the NPC a speed, and it moves as far along the edges between vertexes in each time interval.

The navmesh also helps keep the AI traveling in places that have been marked as safe for travel, without collision or drops.

I explained it pretty clearly what you get when you add a month on January 31st. You get February 31st.

A month is a discrete unit of measure. It is not decomposable into any number of days.

When you increment a month, you get YYYY - (MM+1). Any higher significance is maintained, but irrelevant to the operation. (This applies to the hypothetical statement in the doctor's office, the specific day is indeterminant, but can be assumed the same as current day next month.)

The fact that not all possible days exist is orthogonal to the singular meaning of the operation. It's obviously not greatly valuable to an end-user, but the method of addressing the ambiguity involves a second operation that ensures validity.

End-users want an method that does both the addition and coercion, but you can create consistency if you follow the simple path I laid out in GP.

I'll use your syntax but with the strictly correct definition of the operation.

  Datetime x = new DateTime(2021, 1, 31);
  x.AddMonths(1); // DateTime(2021, 2, 31)
  x.AddMonths(2); // DateTime(2021, 3, 31)
  x.AddMonths(1).AddMonths(1); //DateTime(2021, 3, 31)

  // Ensure Valid, using a coerce to clamp overflows
  DateTime(2021, 2, 31).EnsureValid(); // Feb 28
  DateTime(2021, 3, 31).EnsureValid(); // Mar 31
  DateTime(2021, 4, 31).EnsureValid(); // Apr 30