This looks very interesting. Thank you for the link.
It doesn't support Safari as far as I can see. An extension for Safari (especially on IOS), is quite important. This is perhaps only for me, because my general workflow tends to be quickly scanning a couple of articles that I would want to read later, and I would like to easily bookmark them from Safari.
Secondly, its self-hosted only. This is perhaps not so bad - it just means I have to put some thought into where I would host it.
But again, thank you so much for linking linkding :). I am definately quite interested in trying it out.
You might be missing a German pun there. Dunno if the thing was built by Germans, but the d you missed in the name makes it look like it might be: LinkDing means LinkTHing in English, not "Linking".
I get why but I’ll never not see this as a counterintuitive footgun.
Edit: yes I get why. The logic is there. But my brain just can’t help but see the inverse: eg.
passed = all(test_results)
I hit a case where I actually test nothing and have no results. Did I pass?
Because in my brain I’m always framing things with how a loop can be run zero times. A collection of zero elements is not a case I usually have to manually cover.
Edit again: did all of that confuse you? Because I was completely backwards and wrong. It’s time to clock out for the day.
All the tests also failed, because none passed. Both are true but most people only find out all the zero tests passed because that's the question asked.
If someone wants to consider running zero tests a failure they need to pose the right question for their context.
It's a consequence of enforcing logical consistency. You can't get around that (but if you want to suggest other behaviour and justify it, I'd be interested).
This is a frustratingly common reply to "why is this example unintuitive" across software.
Just because the problem may be higher up the chain, even up to the design of the system, doesn't mean it isn't a problem that has real consequences.
E.g. in this case, one possible solution is to not have the concept of "falsy" and "truthy", forcing 'all' to take a mapping closure (which may necessitate other changes, to the point where you now have essentially a completely different language).
It's useful to call these things out every time they trip us up, if not to fix them, then to avoid them next time somebody starts from scratch.
Okay, I'll respond because you made an interesting point, but you've also pissed me off. Let's follow this through: for a start, just because it's an intuitive doesn't mean it's wrong. However, you made me think that may be we can force at compile time that all() must take a non-empty list of Booleans where we can be sure that the problem domain should never have empty lists. I think with modern typing we can do this with dependent types (but I'm not an expert on this, but you have raised an interesting possibility, thanks).
However there are domain cases where empty lists still make sense, so you're still going to have to account for them in a rational way, and that means logically consistent, and I guarantee we will be back to what you don't like. But that's ok.
Now where you've pissed me off is this bit
> n this case, one possible solution is to not have the concept of "falsy" and "truthy"
and
> forcing 'all' to take a mapping closure
Perhaps you could un-piss me off by explaining what the bloody hell those two are supposed to mean – pretend I'm a language designer that interested in your idea (which actually I am) – what are you asking me to implement?
The poster is basically proposing something like always doing:
def all(lis: List[T], mapf: Callable [[T], bool]) -> bool:
for e in (mapf(l) for l in lis):
if e is False: return False
return True
At least that's my take on avoiding Truthy and Falsy via a mapping closure (or function?). But I don't see it solving OPs issue here when lis is empty... So maybe I'm missing something too.
Also if you didn't want to do a hx-confirm, you could pop up a separate modal on button press. And then when the delete is pressed in the modal use a hx-target to update the specific row.
There are a lot of words the author used to simply say, "I'm going to start my pet project, which I also believe is going to fail very soon for a number of reasons"
Goes without saying, its a browser, browsers are never finished. unless you discarded html/js and started from scratch... but then you'd have no data for the browser and what would be the point of that.
"Goes without saying, its a browser, browsers are never finished. "
But they can be working enough, to be useful. Meaning they can display correctly the pages you want to see.
So the best independent effort of a working browser I know of, is ladybird. And Kling knows how to build browsers, so toying around with a browser from scratch on your own will be a learning experience. But I guess you might learn more, by contributing to a project that stands a real chance to become a working browser.
They are an invaluable resource just don't get too caught up in trying to understand everything they present, they are introductions and about giving you the tools needed to pursue the study of the field, not about giving you a full education. They only take a night or two to read and the bibliographies are within the scope of the introduction they provide, they don't load you down with books that are beyond the knowledge of the sort who would be reading such a book.
https://linkding.link/