MajimasEyepatch

According to the post, this result was first derived for gluons in a previous paper. That paper was provided to the model as context, and then the model was asked to derive an analogous result for gravitons, which presumably has not been done before. The authors claim it would have taken "considerable time" for human experts to derive the graviton result.

I don't see any reason to believe that this exact problem was solved before in the training data, but it's definitely an incremental result based on a very similar problem that the model had seen before.

To be fair, productivity and writing tools are a better fit for LLMs than a lot of other use cases.

Exactly right. It's totally plausible that someone could build a mental health chatbot that results in better outcomes than people who receive no support, but that's a hypothesis that can and should be tested and subject to strict ethical oversight.

I feel this way about some of the more extreme effective altruists. There is no room for uncertainty or recognition of the way that errors compound.

- "We should focus our charitable endeavors on the problems that are most impactful, like eradicating preventable diseases in poor countries." Cool, I'm on board.

- "I should do the job that makes the absolute most amount of money possible, like starting a crypto exchange, so that I can use my vast wealth in the most effective way." Maybe? If you like crypto, go for it, I guess, but I don't think that's the only way to live, and I'm not frankly willing to trust the infallibility and incorruptibility of these so-called geniuses.

- "There are many billions more people who will be born in the future than those people who are alive today. Therefore, we should focus on long-term problems over short-term ones because the long-term ones will affect far more people." Long-term problems are obviously important, but the further we get into the future, the less certain we can be about our projections. We're not even good at seeing five years into the future. We should have very little faith in some billionaire tech bro insisting that their projections about the 22nd century are correct (especially when those projections just so happen to show that the best thing you can do in the present is buy the products that said tech bro is selling).

As the others have mentioned, the goo.gl step isn't necessary for linkjacking, but it is a reputational risk for Google.

It may help prevent linkjacking. If an old URL no longer works, but the goo.gl link is still available, it's possible that someone could take over the URL and use it for malicious. Consider a scenario like this:

1. Years ago, Acme Corp sets up an FAQ page and creates a goo.gl link to the FAQ.

2. Acme goes out of business. They take the website down, but the goo.gl link is still accessible on some old third-party content, like social media posts.

3. Eventually, the domain registration lapses, and a bad actor takes over the domain.

4. Someone stumbles across a goo.gl link in a reddit thread from a decade ago and clicks it. Instead of going to Acme, they now go to a malicious site full of malware.

With the new policy, if enough time has passed without anyone clicking on the link, then Google will deactivate it, and the user in step 4 would now get a 404 from Google instead.

They're not explicitly asked for, but everywhere I've worked that's tested them has found that they improve conversion rates.

There's a few reasons. The biggest one, IMO, is that it lets non-technical users change things quickly without having to go through the engineering team. Obviously there are limits to that, but in many cases, a product or marketing team wants to modify a form or test a few variations without having to put it into a backlog, wait for engineers to size it, wait for an upcoming sprint, then wait another two weeks for it to get completed and deployed. (Even in more nimble organizations, cutting out the handoff to engineering saves time, eliminates communication issues, and frees up the engineering team to do more valuable work.)

On the technical side, these form builders can actually save a decent amount of development effort. Sure, it's easy to build a basic HTML form, but once you start factoring in things like validation, animations, transitions, conditional routing, error handling, localization, accessibility, and tricky UI like date pickers and fancy dropdowns, making a really polished form is actually a lot of work. You either have to cobble together a bunch of third-party libraries and try to make them play nicely together, or you end up building your own reusable, extensible, modular form library.

It's one of those projects that sounds simple, but scope creep is almost inevitable. Instead of spending your time building things that actually make money, you're spending time on your form library because suddenly you have to show different questions on the next screen based on previous responses. Or you have to handle right-to-left languages like Arabic, and it's not working in Safari on iOS. Or your predecessor failed to do any due diligence before deciding to use a datepicker widget that was maintained by some random guy at a web agency in the Midwest that went out of business five years ago, and now you have to fork it because there's a bug that's impacting your company's biggest client.

Or, instead of all that, you could just pay Typeform a fraction of the salary for one engineer and never have to think about those things ever again.

But presumably you could have built it before, just slower, which is the point. For now, that speed-up just looks like a win because it’s novel, but eventually the speed-up will be baked into people’s expectations.

Normally, if you compile the same code twice on the same machine, you'll get the same result, even if it's not truly reproducible across machines or large gaps in time. And differences between machines or across time are usually small enough that they don't impact the observed behavior of the code, especially if you pin your dependencies.

However, with LaTeX, the output of the first run is often an input to the second run, so you get notably different results if you only compile it once vs. compiling twice. When I last wrote LaTeX about ten years ago, I usually encountered this with page numbers and tables of context, since the page numbers couldn't be determined until the layout was complete. So the first pass would get the bulk of the layout and content in place, and then the second pass would do it all again, but this time with real page numbers. You would never expect to see something like this in a modern compiler, at least not in a way that's visible to the user.

(That said, it's been ten years, and I never compiled anything as long or complex as a PhD thesis, so I could be wrong about why you have to compile twice.)

The biggest ones are the ones that are going to cost $70-80, which is what we’re talking about.