paldepind2

My theory (which might be completely wrong) is that models do this because it improves quality for vibe coders.

When vibe coding the content of user prompts is ground truth and the only way any human thought affect the code base. So if the vibe coder says "do X not Y", recording int comments that "we shouldn't do Y" is important. It ensures that the agent doesn't accidentally decide to do Y tomorrow, which would frustrate the vibe coder who'd feel that the agent doesn't "remember" what it was told yesterday.

So for people who look at the code the comments are obvious and completely superfluous, but for the vibe coder it's a way to ensure that their tiny (relative to the size of the code base) input is not forgotten.

Lots of praise for Pi in this thread, so I'll offer up a diverging opinion. Given all the hype, I was a bit underwhelmed by Pi. It definitely has some good ideas around customization, but it annoyed me in many little ways.

For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory.

I think there's still space for another harness that's 1/ open-source, 2/ written in a fast compiled language (Rust, Go, etc.) and scriptable in a simple (aka non-JS) scripting language (Lua, etc.), 3/ less opinionated and more sensible so things like XDG isn't a WONTFIX.

You can do that in Copilot in VSCode. There’s a fork icon before every message that creates a new session from that point. The relationships are not maintained in a tree though (not sure if Pi does that).

Ah, ok. Visibility into subagents makes perfect sense. From the "reddit-style" description I was imagining something where the user was conversing non-linearly with the agent at different points in some big tree.

Can you go more in depth on why LLM conversations should branch reddit-style? That doesn't seem immediately clear to me, and I'd be afraid that the different branches would step on each others toes? (also I'm assuming what you're describing here goes beyond the "fork" feature found in many agent harnesses).

What do you use for hosting the PWAs?

Jevons paradox starts with some resource being used more efficiently.

A classic example could be coal. The first steam engines used a ton of coal, but over time more efficient steam engines where created that used way less coal.

One might think that this caused the global coal usage to go down. But the opposite happened, as the overall cost of doing something with a steam engine went down.

Note, that the price of coal itself can remain fixed in this example. So Jevons principle is not (directly) about a resource changing in value.

If LLMs make codes cheaper to produce, then obviously more code will be produced. That's not an instance of Jevons paradox even though the article claims so.

You could say that LLMs means that we can create software with less of the resource that is human software engineers. So one might think that we'll need less software engineers in the future. If, on the other hand, we end up needing more software engineers, then that'll be an instance of Jevons paradox. But the article is not making that claim.

From the article:

> Jevons Paradox: when something gets cheaper, you tend to use more of it, not less.

That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper.

What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), but still the total usage of that resource increases.

Sorry if this is a basic question, but what's you workflow for feeding the papers into the LLM and getting the implementation done? The coding agents that I've used are not able to read PDFs, so I've been wondering how to do it.

I completely agree with the points in this article and have come to the same conclusion after using languages that default to unary curried functions.

> I'd also love to hear if you know any (dis)advantages of curried functions other than the ones mentioned.

I think it fundamentally boils down to the curried style being _implicit_ partial application, whereas a syntax for partial application is _explicit_. And as if often the case, being explicit is clearer. If you see something like

    let f = foobinade a b

in a curried language then you don't immediately know if `f` is the result of foobinading `a` and `b` or if `f` is `foobinade` partially applied to some of its arguments. Without currying you'd either write

    let f = foobinade(a, b)

or

    let f = foobinade(a, b, $) // (using the syntax in the blog post)

and now it's immediately explicitly clear which of the two cases we're in.

This clarity not only helps humans, it also help compilers give better error messages. In a curried languages, if a function is mistakenly applied to too few arguments then the compiler can't always immediately detect the error. For instance, if `foobinate` takes 3 arguments, then `let f = foobinade a b` doesn't give rise to any errors, whereas a compiler can immediately detect the error in `let f = foobinade(a, b)`.

A syntax for partial application offers the same practical benefits of currying without the downsides (albeit loosing some of the theoretical simplicity).

> Local-first was the first kind of app. Way up into the 2000s, you'd use your local excel/word/etc, and the sync mechanism was calling your file annual_accounts_final_v3_amend_v5_final(3).xls

To be precise, these apps where not local-_first_, they where local-_only_. Local-first implies that the app first and foremost works locally, but also that it, secondly, is capable of working online and non-locally (usually with some syncing mechanism).

I never understood why people are so keen to do that in TypeScript. With that definition a `UserID` can still be silently "coerced" to a `string` everywhere. So you only get halfway there to an encapsulated type.

I think it's a much better idea to do:

    type UserID = { readonly __tag: unique symbol }

Now clients of `UserID` no longer knows anything about the representation. Like with the original approach you need a bit of casting, but that can be neatly encapsulated as it would be in the original approach anyway.

Yes, absolutely. I did programming competitions back in high-school (around 10 years ago) and common folklore was that back in the days knowing dynamic programming could win you a medal, but today it was just basic expected knowledge.

> I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness.

I'm a fan of Go, but I don't think it's the product of some awesome collective Google wisdom and experience. Had it been, I think they'd have come to the conclusion that statically eliminating null pointer exceptions was a worthwhile endeavor, just to mention one thing. Instead, I think it's just the product of some people at Google making a language they way they wanted to.

> A quick Google search with "flutter setstate is not refreshing" reveals a struggle that you will face quite often when running Flutter. It sounds like an easy fix, but the nature of Flutter using a bunch of nested Widgets creates, naturally, lasagna code that makes it hard to reason about this.

Can you expand on this OP? I've never had problems with `setState` nor "lasagna code" in Flutter. From a quick search I mostly seem to find questions from people who are still learning Flutter and getting basic things wrong.

How often do you break your phone that you've save sooo much? Mine is at least 2 years older (I got it 2 years before the Fairphone 4 was released) and I've spend 0$ dollars repairing it.

RAID is not backup, but in some circumstances it's better than a backup. If you don't have RAID and your disk dies you need to replace it ASAP and you've lost all changes since your last backup. If you have RAID you just replace the disk and suffer 0 data loss.

That being said, the reason why I'm afraid of not using RAID is data integrity. What happens when the single HDD/SSD in your system is near its end of life? Can it be trusted to fail cleanly or might it return corrupted data (which then propagates to your backup)? I don't know and I'd be happy to be convinced that it's never an issue nowadays. But I do know that with a btrfs or zfs RAID and the checksuming done by these file systems you don't have to trust the specific consumer-grade disk in some random laptop, but instead can rely on data integrity being ensured by the FS.

I was a bit confused by the remark that comptime is referentially transparent. I'm familiar with the term as it's used in functional programming to mean that an expression can be replaced by its value (stemming from it having no side-effects). However, from a quick search I found an old related comment by you [1] that clarified this for me.

If I understand correctly you're using the term in a different (perhaps more correct/original?) sense where it roughly means that two expressions with the same meaning/denotation can be substituted for each other without changing the meaning/denotation of the surrounding program. This property is broken by macros. A macro in Rust, for instance, can distinguish between `1 + 1` and `2`. The comptime system in Zig in contrast does not break this property as it only allows one to inspect values and not un-evaluated ASTs.

[1]: https://news.ycombinator.com/item?id=36154447

This is honestly really cool! I've heard praises about Zig's comptime without really understanding what makes it tick. It initially sounds like Rust's constant evaluation which is not particularly capable. The ability to have types represented as values at compilation time, and _only_ at compile time, is clearly very powerful. It approximates dynamic languages or run-time reflection without any of the run-time overhead and without opening the Pandora's box that is full blown macros as in Lisp or Rust's procedural macros.

> I'm not very familiar with these relations, but shouldn't function returns be covariant? `String => Cat` is a subtype of `String => Animal`?

You're right :) I mixed up covariance and contravariance for function parameters and return value in my comment.

> For function parameters, doesn't it depend on how the parameter is used?

I don't think so, but maybe there's specific circumstances I don't know of? Function parameter types is a constraint on _input_ to the function. Changing that to a subtype amounts to the function receiving arguments that satisfies a stronger constraint. That seems that something that would hold no matter how the parameter is used?

> Wait, if I recall correctly, covariance has long been established as a mistake.

Perhaps you're just missing some words here, but, just for clarity: it doesn't make any sense to say that covariance is a mistake. Covariance applied in specific places, like Java's mutable covariant arrays which leads to unsoundness, can be a mistake, but covariance itself in fine and essential in languages with subtyping. Function parameters should be covariant, function returns should be contravariant, mutable data structures should be invariant, etc.

Correct me if I'm wrong, but neither vertical tabs nor tab groups are fully ready and shipped.

From a quick search, it seems that you need to make edits in `about:config` to enable tab groups and use nightly to access vertical tabs.

My understanding is that it will be much harder as ARM is way less standardized than the Intel x86 platform. This is something that Linus Thorvalds has talked about in the past [1]. Think about how huge an effort it is to get Linux to run on Apple’s ARM machines or how some distros have a Pi specific variant. I guess getting macOS to run on other ARM machines could be similar challenging.

1: https://www.pcworld.com/article/410627/why-linux-pioneer-lin...

Absolutely. I did a little bit of iOS development at some point and was genuinely shocked by how bad the documentation was and by how often WWDC videos was the best documentation available.

To give a concrete example: At WWDC20 Apple showed off a new Core Data feature called "derived attributes" [1]. Only many months later did they add the bare minimum of written documentation covering a fraction of what was shown off at WWDC [2].

1: https://developer.apple.com/videos/play/wwdc2019/230/ 2: https://developer.apple.com/forums/thread/120159

> Suppose the war ends. Will the Europeans keep boycotting the cheap russian gas?

I think they absolutely will, yes. It will cost some money, just like spending more money on defense will, but from what I can see, no one in the European politic elite imagines a world where we can go back to buying gas from Russia.

Thanks for expanding! I think your original comment would have made more sense with some of these arguments included. Point 1 is especially prudent. It really would have been trivial to see if the bed is actually running an SSH server on some port.

I don't really understand the take here. The post makes it very clear what is concrete evidence, what is speculation based on that, and the reasoning is much better than what you give it credit for. For instance, what would you suggest the "remote-connectivity-api" SSH endpoint URL and the authorized public SSH key is for if not for remotely SSHing into the bed's computer?

I think the key feature is _cooling_ the bed, with warming secondary to that. That arguably sounds like a great nicety to have, notwithstanding all the downsides mentions in the post.

That's true, but then, I'm not saying that the Quest is an offline-only device without cloud features. I'm saying that Meta didn't invest $63 billion just to create a "suction pipe for hoovering up that data". They have much bigger ambitions than that.

And in what way are they then selling that data (which is what the person I replied to talked about)? Just the fact that the data is being sent to a server doesn't mean much. Tons of modern products relies on literally recording your data and sending it off to a server.