pull down to refresh
0 sats \ 5 replies \ @elvismercury OP 22 Nov 2023 \ parent \ on: Stranded sats bitcoin
Can you elaborate?
Oh sorry, my reply just got zapped and that was a reminder about your reply, lol
With leaky abstractions, I just meant that we write software in layers to abstract underlying (complex) stuff away.
But more often than not, these abstractions are "leaky" since you still need to know some stuff about underlying layers as in this case, where you still need to care about onchain fees even though lightning should abstract that away. It does mostly but only mostly, thus it's a leaky abstraction.
Another example for a leaky abstraction is SQL. With SQL, we want to tell the database what we want (declarative) but we don't want to tell it how to do it (imperative). It should just take our query and the database engine should figure out what the best query plan is to deliver the results as fast as possible. When I write a SQL query, I don't want to care about which indices or JOINs should be used. But sometimes, the query gets really slow and then you need to dig into query plans and figure out what is going wrong.
But here are two good articles that explain it much better than I can:
- https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
- https://www.mirkosertic.de/blog/2012/08/the-law-of-leaky-abstractions/
From the second article:
As the systems we use become more and more complex, the number of abstractions that software developers must rely upon increases. Each abstraction attempts to hide complexity, allowing a software developer to create code that can “handle” all the variations in complexity that modern computing requires.However, if Spolskys Law of Leaky Abstractions is true, then in order to create software that is reliable, software developers must learn many of the abstraction’s underlying details anyway.
Does that help?
reply
That's a great link, thanks for the share. Love this line:
the abstractions save us time working, but they don’t save us time learning.
reply
Yes and no. Yes, in that it was a nice description of leaky abstractions. No, in that I'm not clear what you mean about how L2 is an example of that.
Is it that, with all this mucking around with min_htlc settings, and even the details of worrying about managing UTXOs for dust, that we're having to care about things that normal people don't give a shit about because they just want to send their money around without thinking about it, as per your SQL example?
Now that I write it out, I'm guessing that's what you meant. But you can tell me if if I've got it.
reply
Is it that, with all this mucking around with min_htlc settings, and even the details of worrying about managing UTXOs for dust, that we're having to care about things that normal people don't give a shit about because they just want to send their money around without thinking about it, as per your SQL example?
Yes, basically.
L2 should abstract onchain fees away. But because force closures can happen, we still need to care about onchain fees.
reply
Leaky abstractions in software mean layers meant to simplify complex tasks still require understanding of underlying details, like needing to know onchain fees in lightning networks or optimizing SQL queries despite its declarative nature.
reply