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.

> 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.

> 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

    let f = foobinade(a, b)

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

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).

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).

Comments URL: https://news.ycombinator.com/item?id=45263710

Points: 2

# Comments: 0

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

    type UserID = { readonly __tag: unique symbol }

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.

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.

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.

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

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?

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.

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.

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

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

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.