rodarmor

Very compelling and thoughtfully written article. Thank you!

Spreadsheet-defined functions are a way for spreadsheet users to define reusable functions in a way that reuses the existing spreadsheet user-interface and features that they already know.

I came up with the idea a while ago[0], but it turns out that they were actually independently invented much earlier. With [this paper](https://www.microsoft.com/en-us/research/wp-content/uploads/...) being the canonical origin of the idea.

The idea is that you create a new tab in your spreadsheet, mark some cells as inputs, some cells as outputs, and use existing spreadsheet functionality to derive the output value cells from the inputs. You can use arbitrary formulas, as well as define intermediate values in other cells.

I thought it would be fun to make a demo of sheet functions using IronCalc, which you can try out here:

https://casey.github.io/IronCalc/

The demo was written by an LLM, so I have no idea if the code is any good or not, but it seems to work!

I like the name "sheet functions", since it's a bit less verbose.

The spreadsheet contains a bunch of demo sheet functions, all called in the first `Demo` tab, with the rest of the tabs being the function definitions.

Sheet functions use the first column for input, the first cell of the second column for output, and any spreadsheet can be made into a sheet function by selection the `Function sheet` option in the spreadsheet tab drop down, which makes it callable in formulas by its name.

Hopefully it illustrates the power of sheet functions. If you scroll through the tabs all the way to the right, you can see the `Fractal` spreadsheet, which renders the Mandelbrot set using a sheet function.

This is just a demo, the code is probably horrible, and I'm slammed working on other stuff, so I probably won't take it further myself, but I wanted to share. So far, sheet functions haven't made it into any spreadsheet program intended for actual use, and it's something could be an interesting differentiator for IronCalc.

[0] And made a video: https://www.youtube.com/watch?v=1WkMpa5zfTA

There’s an easy solution: Bruce should place large bets on the prediction markets right before publishing the relevant data. It is legal, ethical, and, for him, risk free.

I wish that Opera Omnia, also by Stephen Lavelle, got more attention. It is mind-blowing exploration of the idea of propaganda and revisionist history, which somehow also manages to be engaging and fun, with an incredibly unique core mechanic.

It would be hilarious if people wound up snorting or boofing their GLP-1s (≧▽≦)

The best example of managing expectations of all time is in the Time Zone Database documentation:

> The tz database predicts future timestamps, and current predictions will be incorrect after future governments change the rules.

General-purpose deduplication sounds good in theory but tends not to work out in practice. IPFS uses a rolling hash with variable-sized pieces, in an attempt to deduplicate data rysnc-style. However, in practice, it doesn't actually make a difference, and adds complexity for no reason.

This is stupid good advice. I use quicksilver as a launcher, and by putting bookmarks in a folder, I can index them and launch them like any other app or document on disk. Thanks for writing this up!

I definitely don't think Just will ever unseat Make. Just doesn't have file-based dependencies, so it's not a build system, just a command runner.

As far as unseating Make as a command runner, I think that might just take Just being available in more places, since one of the main advantages of Make that many users cite is that it's available everywhere. Just is already available in a lot of package repos, but not all of them. Finally packaging Just for Debian[0] would help a lot.

[0] https://github.com/casey/just/issues/429

This is the canonical video on the subject: https://www.youtube.com/watch?v=TmVMh-nT200

One time me and a friend having an animated conversation on the 7th floor of Soda hall at Berkeley and William Kahan came out and gave us a coupon for Sizzlers. I think that was his way of telling us to get the fuck out.

It's usually actually bread baking, not painting, in my experience.

Misread the title as "Which John von Neumann Died at Los Alamos?" and now I really want to read that article.

Don't let the article put you off, the paper, no paywall, is much better and much more concrete:

https://academic.oup.com/ajcn/advance-article/doi/10.1093/aj...

The fact that consumers don't want phones with 7 years of guaranteed updates (if they did, they would be willing to pay more for them, and smartphone makers would happily oblige) means that the impact on resale values would likely be small, or that consumers are unlikely to try to resell their phones.

If this law comes into effect, consumers will pay the increased cost of delivery of 7 years of software updates when they purchase new phones.

Smartphone makers don't sell new phones with a higher price tag and the guarantee of 7 years of software updates, likely because consumers would prefer a lower price and no guarantee.

Thus, the law would effectively force people to buy something that they don't want.

The post doesn't seem to offer any evidence for its claim.

Fortunately, if you're feeling entrepreneurial, you can spin up an Agora* instance and start selling whatever you want for Lightning Payments.

* https://github.com/agora-org/agora/

You bet!

These are definitely not dumb questions!

Liquidity management is one of the most complicated aspects of the Lightning Network, and certainly one of the most counter-intuitive.

The basic primitive that makes up the Lightning Network is a "channel". A channel is between two nodes, has a fixed capacity, is opened by making a on-chain Bitcoin transaction, and is closed by making an on-chain Bitcoin transaction.

While the channel is open, the two parties to the channel can make payments between themselves, but do not have to publish a Bitcoin transaction for each one of these payments. They only have to publish a Bitcoin transaction when they want to close the channel, which nets-out the intermediate transactions made since it was opened.

As a concrete example, let's say Alice and Bob open a channel, with Alice contributing 1 BTC when the channel is opened, and Bob contributing 0 BTC. Initially, their balances on the channel are:

    Alice: 1 BTC
    Bob: 0 BTC

In this state, Alice can send a 0.1 BTC payment to bob, and the channel balances will be:

    Alice: 0.9 BTC
    Bob: 0.1 BTC

Alice and Bob can send each other money, but only up to the amount that they have in the channel. So at this point, Alice can send Bob up to 0.9 BTC, and Bob can send Alice up to 0.1 BTC.

However, at the very beginning, when Bob's balance was 0 BTC, he could not have sent money to Alice. Due to a lack of inbound liquidity, which is, quite simply, money on the other side of a channel, which can be sent to you.

This is an aspect of the Lightning Network that is very different from other payment systems, and from on-chain Bitcoin payments. You must arrange to have sufficient inbound liquidity to receive payments.

You ask a good question: What if I just want to assume that the customer is good for the money and queue it up myself for settlement once I have the liquidity to spare?

Let's imagine that we were in the initial state, Alice had 1 BTC in the channel, Bob 0 BTC, and Alice let Bob make a payment to her of 1 BTC. The new balance would be:

    Alice: 2 BTC
    Bob: -1 BTC

However! When a Lightning Network channel is closed, you divide up the funds from the funding transaction between the parties to the channel. The channel was funded with an on-chain Bitcoin transaction of 1 BTC, so there would be no way to pay out Alice 2 BTC from that initial transaction. Since both parties to a payment channel can close the channel at any time, Alice would be trusting Bob to keep the channel open until he no longer had a negative balance, and avoiding the need for trust is the whole purpose of the Lightning Network in the first place, otherwise we could just trade unenforceable IOUs back and forth.

If you're using htlc.me, that's probably the issue. htlc.me is a testnet wallet, so it can only pay testnet invoices, and agora.download is on mainnet.

Just saw this now, but agora.download is on mainnnet, and test.agora.download is on testnet, so if you're using a testnet wallet, it won't be able to pay the mainnet invoices from agora.download.

Can you explain why it will be an issue for anyone who hosts it? The host determines what content is available. Agora does not yet support user uploads.

The possibility of losing funds exists, but bugs are something you would expect with any in-development technology. And, existing payment services are not without risk. Getting your account frozen and funds taken is pretty common with PayPal, Square, and other payment providers, which is not possible with the Lightning Network.