I don’t think essentialist explanations about how LLMs work are very helpful. It doesn’t give any meaningful explanation of the high level nature of the pattern matching that LLMs are capable of. And it draws a dichotomic line between basic pattern matching and knowledge and reasoning, when it is much more complex than that.

With all the social science research and strategy books that LLMs have read, they actually know a LOT about outcomes and dynamics in adversarial situations.

The author does have a point though that LLMs can’t learn these from their human-in-the-loop reinforcement (which is too controlled or simplified to be meaningful).

Also, I suspect the _word_ models of LLMs are not inherently the problem, they are just inefficient representations of world models.

I don’t personally know anyone who role-plays, so candid question: have LLMs changed the way people play tabletop RPGs?

> you wouldn't get a new tool simply because you might need it

No but you get a framework precisely because it's "batteries included": many apps will need those tools. You don’t have to use all of them, but having them available reduces friction when you do.

> If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in

It already is. Nothing runs at the edge unless you add a middleware.ts. You can build a full app without any middleware. I'm surprised the author of the article fails to acknowledge this, given how much time was spent on finding alternative solutions and writing the article.

I like to learn and improve. A lot of comments here are just baseless negative comments. Please let’s have a real discussion.

The post's author seems to conflate the edge runtime with the server runtime. They’re separate environments with different constraints and trade-offs.

I struggled with Next.js at first for the same reason: you have to know what runs where (edge, server, client). Because it’s all JavaScript, the boundaries can blur. So having a clear mental model matters. But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.

- A company I worked for wanted to be 100% focused on doing one thing. It was spending 10x more than it was making revenue. It went bankrupt.

- Another company I worked for always insisted on not having all eggs in one basket. There was one big revenue maker that dwarfed the others though. The company is still around and doing well.

I have quite a scattered brain too so I get the appeal of "choosing to focus". But looking others do it I see the risks : refusing to experiment and learn new stuff, or find new opportunities.

EDIT: I'd like to add that focusing or not focusing is not a useful dichotomy, it's more about finding the right "exploration vs exploitation" balance.

I’m actually a software developer with 10 years experience and also happen to do data science. And found myself in situations where I parametrized a notebook to run in production. So it’s not that I can’t turn it to plain python. The main reasons are

1. I prototype in a notebook. Translating to python code requires extra work. In this case there’s no extra dev involved, it’s just me. Still it’s extra work.

2. You can isolate the code out of the notebook and in theory you’ve just turned your notebook into plain py. You could even log every cell output to your standard logging system. But you loose context of every log. Some cells might output graphs. The notebook just gives you a fast and complete picture that might be tedious to put together otherwise.

3. The saved notebook also acts as versioning. In DS work you could end up with lots of parameters or small variations of the same thing. In the end what has little variations I put in plain python code. What’s more experimental and subject to change I put in the notebook. In certain cases it’s easier than going through commit logs.

4. I’ve never done this but a notebook is just json so in theory you could further process the output with prestodb or similar.

I have a process that generates lots of data. I put it in a huge multi-indexed dataframe that luckily fits in RAM. I then slice out the part I need and pass it on to some computation (at which point the data usually becomes a numpy array or a torch tensor). Core-count is not really a concern as there's not much going on other than slicing in memory.

The main gain I get of this approach is prototyping velocity and flexibility. Certainly sub-optimal in terms of performance.

As the end-user, not quite my concern.

> and the staggering complexity of what's possible to put inside square brackets and how to decipher its meaning

I might not be aware of everything that's possible -- the usage I have of it doesn't give me an impression of staggering complexity. In fact I've found the functionality quite basic, and have been using pd.MultiIndex.from_* quite extensively for anything slightly more advanced than selecting a bunch of values at some level of the index.

[1] https://pandas.pydata.org/docs/user_guide/advanced.html#adva...

And here the issue is not in font differences (or different pictures of the same thing getting different interpretations): it’s the thing represented that’s actually different.

What happens if you ask the total number of occurrences of the letter r in the word? Does it still not get it right?

The paragraph you mention seems to worry more about mistakes more than tempering attempts though (taking 10x the dose prescribed could indeed be problematic)

How can the bing search version of ChatGPT quote chatgpt? Is it able to use information from live web requests, where it would have found news article about the case?