fyp

Some of these aren't one line but could be (for example the one for node.js can use npx instead)

> In the absence of calamity, fortuitous events, or brilliant new marketing strategies, sale counts are well-described by a Poisson process. That is, you can think of there being an underlying average number of sales per day, and each day will be a realization of a Poisson distribution with that average.

Can someone give a bit more justification for this? It seems like the average rate shouldn't be constant and is heavily dependent on time/date.

If not, is there another justification for why sales mean should equal sales variance?

The only thing I remember from the CKEditor post from last year was that it took "42 man-years" to implement: https://news.ycombinator.com/item?id=18220020

I wonder if it's better understood now and can cost less R&D time.

Ah I didn't realize they were talking about over the history of the library. That makes much more sense.

My theory is that we're just looking at the list of books most frequently assigned by english teachers. Excluding children books, most of these can be found in the new york state education department's literature suggestions: http://www.p12.nysed.gov/guides/ela/part1b.pdf.

The exceptions were "How to Win Friends and Influence People" (rank 8) and "Harry Potter" (rank 9).

I am actually pretty shocked by this. I didn't expect a self-help book (15 million copies sold) to beat harry potter (120 million copies sold, 500 million if you include the entire series, making it the best-selling series in history). I guess people who love the franchise would rather own the book?

Why must the messy code win in this case?

Building a transform tool should be a pretty well understood problem. Just take a look at what photoshop's transform tool does and you will see all the possible extensions you might need to support in the future (rotate, skew, distort, perspective, warp, transform origins, a bajillion modifier hotkeys, etc).

Of course don't go ham and support all of them up front. But with those future use cases in mind, it's pretty hard to write yourself into a corner. I would say Dan's refactoring looks fine other than needing more customization for positioning and handle behavior. But it seems easy enough to just add them later.

Can someone point me to a successful PWA in the wild? I hear a lot of them as a web developer (usually the first thing I do after create-react-app is delete the service worker) but I don't think I have ever seen/used one.

I have a pair of "identical" GPUs which have dramatically different performance. Swapping the order didn't help. It turns out it was because one was blowing hot air into the other. Sigh.

> a friend of mine once got a Google Code Jam World Finals question in a phone interview with Google (...) I doubt there were more than a few hundred people in the world who would've gotten the right answer to the question in a phone screen and almost all of them probably would've realized that it was an absurd phone screen question

Link to the question: https://code.google.com/codejam/contest/2437491/dashboard#s=...

The gist of it is: You are given 4*N points on a 2D plane. Can you draw two perpendicular lines to separate them into N points per quadrant?

I think Dan's missing context is that google code jam questions always have a small and large dataset. In this case, small is N=10 which makes a lot of bruteforce solutions possible and not much different from any other bruteforce puzzles common in interviews. Being a geometry question is the more unfair part if this is a generalist role (but not unfair if your role involves graphics, computer vision, self driving car mapping, etc).

Expecting a solution for the large (N=2500) is ridiculous of course. See analysis: https://code.google.com/codejam/contest/2437491/dashboard#s=...

Pretty spot-on guess! I do have relatively high blood pressure, typically in the 130-150 range.

Doctors have suggested it before but since I am borderline I don't really need to be on meds yet. I think it sounds worse than needing to take pain killers occasionally.

I have had life long headaches that I have given up on fixing. Occasionally when I switch to a new doctor I will mention it just to see if they have anything new to say.

They usually just put me on a concoction of various pain killers (e.g., migraine specific stuff like sumatriptan). These prescriptions actually work great. But so did OTC aleve/advil/tylenol too.

The problem was that I didn't really care for more effective pain killers. What I really want is to fix the root cause and stop having these headaches.

So yea, I can totally see why something like this would fail. If the solution is still qualitatively the same, a small percentage improvement is just micro-optimizations that most doctors and patients won't care much for.

NaN == NaN is always false (at least in other languages I know).

Native lazy loading is an extremely recent feature! https://web.dev/native-lazy-loading/ https://caniuse.com/#feat=loading-lazy-attr

So no, browsers don't have these problems solved out of the box. And it seems like what they are implementing will suffer from the exact problem I described here too.

I think you might also be thinking of bad implementations of infinite scroll which isn't what I am talking about. Have you never use something like photos.google.com? Scrubbing/scrolling to an arbitrary point in time is honestly a great user experience. Would you rather wait hours/days for a webpage to load all the past photos images you've ever taken? Or have to deal with pagination and click through hundreds of pages to find what you want?

I really wish we had more control over the scheduling of async tasks.

For a javascript example I ran into recently, say I am firing off a fetch for each image that comes into view in a large gallery. If I suddenly scroll down to the 1000th image, a naive implementation might fire off 1000 fetches for all the images we scrolled past. Then you'll be waiting a long time before the images in your current viewport is loaded.

Backpressure can save you a little bit here. Say you do the semaphore trick mentioned in the article and only allow a max of say 10 fetches in flight at once. Then if you quickly scroll through, all the subsequent fetches after the initial should fail, including the ones at the viewport you stop at. But since the queue is short, when the images in your current viewport retries it should now succeed.

This works but it isn't ideal. Ideally I would be able to just reprioritize the newer fetches to be LIFO instead of FIFO. Or maybe inspect what's currently queued up (and how big the queue is) so I can cancel everything that I don't need.

The backpressure solutions might just be a symptom of async tasks not being controllable in any way once started which is why you're forced to commit to it or not from the start even if that might not be the best point in time to make that decision.

In theory if you can completely saturate the 1 gbit link for a whole month it's 300TB/month

People were projecting that he will lose last year: https://news.ycombinator.com/item?id=18792890

Yea that's a good point. This matters when your derived data takes linear time to recompute. There are still techniques to make this work (but not automatically afaik). For example it's easy to make them efficient again if your computation is just an associative fold or reversible fold: https://sci-hub.tw/https://link.springer.com/chapter/10.1007...

Since there's a correspondence between proofs and programs (Curry-Howard), maybe you're just looking for a graph-based visual programming language.

But given the failure (of adoption) of dataflow programming languages I don't think there will really be that much of a jump in understanding just by visualizing stuff as graphs.

I found the philosophy communicated by mobx-state-tree to be a lot clearer than redux (particularly stuff around patches, snapshots and async flows): https://mobx-state-tree.js.org/intro/philosophy

Most functional languages have immutable persistent data structures that don't require a linear copy and are fairly efficient.

For example in clojure, sequences are implemented as 32-ary tries so insert/delete/update to any particular index will only cost around sizeOfNode * numParents=32 * log_32(n). This comes with a cost that indexing is now log_32(n) but it's usually a fair price to pay.

In javascript, immutable.js implement these same ideas (as least according to these talks where they talk about index tries and hash array mapped tries: https://youtu.be/I7IdS-PbEgI?t=456)

If you want native support, javascript engines are actually free to swap out their implementation of arrays! I know they already do depending on whether they think your array is sparse("holey") or not: https://github.com/v8/v8/blob/8.1.81/src/builtins/builtins-a.... I also vaguely recall someone saying that unshift (push to front) is automatically optimized by switching to a deque/circular buffer but I might be remembering wrong. Anyway, they can make these optimizations in a distant future but I don't think do today.

I wonder what niche these tools fill. Maybe when you want to do some ad-hoc analysis and want every step in your shell history?

Otherwise it seems more flexible to just fire up a python interpreter and do it in like 3 lines of pandas (or with sqlite and .import like another commenter mentioned)

Can someone give me an example on how to properly use the central limit theorem in the real world?

For example with stuff that are commonly assumed to be bell-curved like test scores, IQ, etc. What are the iid variables being averaged? Each test question?

"A careful search algorithm in a high dimensional space" sounds exactly like what these guys did with chocolate chip cookies: https://sweets.seriouseats.com/2013/12/the-food-lab-the-best...

Also a programmer here but I agree more with your girlfriend's style.

You can either use battle-tested libraries or you can try to understand and reimplement them to suit your use case. The former is safer but the latter is necessary if you want to truly understand and build skills. That said, yea, not when there are deadlines (expecting guests).

It's amazing how good this is for training!

Apparently I am not that great at minesweeper and guess way too often when it's not necessary. This variation kills those bad habits pretty quickly by punishing you 100% of the time for guessing. Along with undo and double checking with the debugger, I've picked up way more patterns/heuristics than in my years of playing.

Coolest thing is that if you're a perfect logician you can always win!

Link to actual game since it's not prominent in article: https://pwmarcz.pl/kaboom/

Are there still ongoing iterated prisoner's dilemma tournaments that we can submit code to online?

The idea that you can submit "code of ethics" to duke it out in a simulated environment is pretty fascinating.

> For a short period of time, because of a blog post someone else wrote, I had a huge waiting list

Why is this short opportunity window unique? So you realized you missed this window but then the environment was already one where this "5x" demand no longer existed? If that's the case would it have been wise to ramp up that quickly? Maybe you did the right thing.

Were there any videos people thought was particularly worth watching?

Is this the right list? https://slideslive.com/neurips#!feed=popular

I have seen the theory that the most optimally emotional ideas are the ones that go viral: https://m.youtube.com/watch?v=rE3j_RHkqJc

A lot of us process the world using rule-based algorithms. This makes us natural programmers but sorely inadequate to handle the world.

For example the rule of "if religious, then don't include in product" is usually pretty sane.

But near a decision boundary, you will always get disagreement. A certain portion of programmers would've arrived at the conclusion that isReligious(santa) == False while some will be dead set that the answer must be True. Both side are confident that the other side is making a fatal mistake because they are confident in their logic skills. But the real problem is that binary logic can't handle these sort of high context fuzzy situation at all.