Google Pay may not work, but NFC payments through yiur bankapp probably do. They did for me.
HN user
themk
It's pretty exciting to see a small chip with an MMU. I wonder if it would be possible to get sel4 running on this?
I'm also curious about the current draw, but I couldn't find anything?
One of the few sites with a fun "you have javascript turned off" message.
This game requires JavaScript. Or, if you've superior taste, take out a pen and paper and start listing animals.
I actually noticed this as a kid. One of the early GTA games north locked minimaps, and I knew the city well. Later ones did not, and I was always more confused.
I've pretty much always had GPS nav locked to North-Up because of this experience.
Pandoc? It might help you. If you are programatically generating content, you can emit the JSON intermediate format. If you are hand writing, you can use something more sane like djot.
From what you just wrote, it appears you misunderstood what I said. Just to be clear:
Red kidney beans (50g): PDCAAS = 0.88, Protein = 11.25g Basmati rice (50g): PDCAAS = 0.7, Protein = 4.5g
Red beans + rice (50g, 50g): PDCAAS = 1.0, Protein = 15.75g
Milk (500g..): PDCAAS = 1.0, Protein = 15.5g
So, from a protein perspective (according to PDCAAS), 500g of milk will give you the same amount of usable protein as the 100g rice and beans meal. There is nothing left on the table.
So, just eating kidney beans, PDCAAS would say that you aren't really getting the full benefit of the "protein on the label". But once you combine it with rice, you are getting the full benefit (according to PDCAAS).
You can't look at the digestibility of the two foods in isolation to make the calculations.
As long as you are eating a varied diet, PDCAAS is pretty pointless. If you have an eating disorder, or food scarcity issues, then it might become important.
PDCAAS is dumb when looking at multiple foods. E.g., beans and rice, when consumed together, are like, 0.99, depending on the ratio. That is, the sum is greater than the parts.
and reading code is harder than writing it.
This is the things thar gets me the most. Code review is _hard_. So hard that I'm convinced my colleagues don't do it and just slap "LGTM" on everything.
We are trading "one writer, one reader" for "two readers", and it seems like a bad deal.
That is quite an extreme take, and one that sounds like it was born from parroting social media takes. Ancel Keys was largely correct, and much of what he said is corroborated by modern science. Probably his main issue was that he was a bit too focused on saturated fat, which is not wrong, but not the only factor. He was wrong that sugar is just empty calories, though he never recommended replacing fat with sugar.
Modern science agrees that saturated fats lead to CVD, but replacing saturated fats with refined carbs also leads to CVD, which Ancel Keys didn't believe (though, to be fair, the populations he studied didn't have access to the types of refined carbohydrates we have today)
The dietary guidelines derived from his work did backfire, but Keys never said to replace saturated fats with refined carbs, which is what ended up happening. He advocated for substituting different fats. But the message that ended up being received was "no fat at all", which no scientist ever actually recommended AFAIU.
The diet he actually recommends is well studied, and found to be protective.
This sounds like they didn't think about it at all. Of course they did, and sure, their techniques were not as sophisticated as today. But there have been plenty of follow-up studies that have controlled more rigorously for those things, and it turns out they were probably right?
Also, the 7 countries study didn't just compare the regions, they also did intra-regional comparisons. Not that I think this particular study is what you should base all your evidence on, but, most others back it up.
The people who run these studies actually know what they are doing. They know the limitations of their methods, and, they have thought about confounding variables. This _always_ comes up in internet debate, like, "ahh, but there are confounding variables so the study must be trash!". It's literally their job to take those confounding variables into account. They don't just grab random people of the street to run these things. And I assure you, they know about the details.
Not the poster, but, usually what people are referring to is all the other stuff that comes along.
Per calorie beef and broccoli are actually surprisingly similar, but broccoli comes with fiber, calcium and vitamin C, while beef comes with saturated fat.
Of course, broccoli is not very calorie dense, so you would need to eat a lot.
More realistically, tofu, which has about as much protein per calorie (and almost as much per gram) as middling lean beef. But has half the saturated fat, more iron, more calcium, and fibre.
You just get more good stuff, and less bad stuff with veg.
Bioavailabilty is a bit of a non-issue. It's measured as if the food you are measuring is the only food you eat. So if it is slightly low on one amino acid, the "bioavailabilty" drops, but noone eats like that. Once combined with other foods, the total "bioavailabilty" tends to increase.
Notably, the epidemiological study people like to dump on the most, largely did use natural experiments (i.e. they chose regions, that, at the time, had very traditional diets, without the convenience of supermarkets to mess it all up). They also didn't rely solely on food surveys, but actually measured the meals.
But all that aside, I don't actually follow a Mediterranean diet, and agree that one has to be careful here, because it is not well defined (or, it might be in some circles, but that differs from what the general population might expect).
The only reason I mentioned it was in response to
The Mediterranean diet is regarded as quite healthy by many health professionals but, it is also high in carbs and fat.
Where I was pointing out that the fats in the Mediterranean diet (by pretty much every measure of what it means to be a Mediterranean diet), are not saturated, and it is usually saturated fats that are considered "bad".
That is, all I was trying to do was clear up the (common!) confusion about fats (they are not all the same).
That seems to be searching for RCT's, which, I'm not surprised would struggle to replicate. Most of these had a duration of less than 5 years, while dietary related health outcomes are the result of decades of following a pattern. It's possibly also unethical, in some cases (i.e. the existence of effective LDL lowering medication would likely complicate things).
Many people seem to disregard epidemiology, especially when it comes to nutrition (I think because it tends to support unpopular positions). But epidemiology has performed some excellent feats in the name of public health: cholera, smoking, pfao.
It is unfortunate that the large time-lines on these things make more rigor difficult, but I wouldn't throw out the epidemiology.
Dietary cholestrol hasn't really been overturned, but sure there is some nuance. Some people do respond badly to dietary cholestrol (like you said, individual advice is sometimes required), but dietary cholestrol is also not a linear response afaiu. That is, if you eat one egg a day, you may as well eat 4, but if you can completely eliminate dietary cholestrol it could make a difference. So, many guidelines don't bother with suggesting it, because it's too hard to eleminate it to the point of mattering for the average person.
All that to say, the science isn't wrong, but the practicalities influence the advice.
Nina Teicholz is not who you should be getting your dietary advice from. She has no qualifications.
I really wish people would stop sharing that article as if it means anything. Nina Teicholz is not who you should be getting your science from.
Her views are not the scientific consensus. She is not a scientist, she is a journalist with an agenda.
When people say "fat" is bad for you, they mean saturated fat. Mediterranean diet is quite low on saturated fat, while still having the good fats.
I think git is overkill, and probably a database is as well.
I quite like the hackage index, which is an append-only tar file. Incremental updates are trivial using HTTP range requests making hosting it trivial as well.
Yes, the inability to edit cards due to the content-addressing seems like a majot drawback.
I thought Meta was "the Party".
My personal favourite analogy is gambling. The constant microdosing of dopamine to get you to hang around and spend just a little more ~money~ attention.
I recently published an internal memo which covered the same point, but I included code. I feel like you still have a "voice" in code, and it provides important cues to the reviewer. I also consider review to be an important learning and collaboration moment, which becomes difficult with LLM code.
It still is a monad. It's just Zig doesn't have language support for monads, so it's less ergonomic.
Just as modular addition over ints in Zig forms a group, even if Zig has no notion of groups. It's just a property of the construct.
Laziness has nothing to do with it.
What that means practically for Zig, I'm unsure.
Passing an interface as a parameter is a monad. (Io -> _) is an instance of Monad in Haskell.
Haskell just has syntax to make using (any) monad much nicer. In this case, it let's you elide the `Io` parameter in the syntax if you are just going to be passing the same Io to a bunch of other functions. But it still is there.
A Monad is a _super_ generic interface that can be implemented for a whole bunch of structures/types. When people talk about "monads", they are usually referring to a specific instance. In this case, the Reader monad is a specific instance that is roughly equivalent to functions that take an argument of a particular type and return a result of any type. That is, any function that looks like this (r -> a) where `r` is fixed to some type, and `a` can be anything.
Functions of that form can actually implement the Monad interface, and can make use of Haskells syntax support for them.
One common use-case for the reader monad pattern is to ship around an interface type (say, a struct with a bunch of functions or other data in it). So, what people are saying here is that passing around a the `Io` type as a function argument is just the "reader monad" pattern in Haskell.
And, if you hand-wave a bit, this is actually how Haskell's IO is implemented. There is a RealWorld type, which with a bit of hand waving, seems to pretty much be your `Io` type.
Now, the details of passing around that RealWorld type is hidden in Haskell behind the IO type, So, you don't see the `RealWorld` argument passed into the `putStrLn` function. Instead, the `putStrLn` function is of type `String -> IO ()`. But you can, think of `IO ()` as being equivalent to `RealWorld -> ()`, and if you substitute that in you see the `String -> RealWorld -> ()` type that is similar to how it appears you are doing it in Zig.
So, you can see that Zig's Io type is not the reader monad, but the pattern of having functions take it as an argument is.
Hopefully that helps.
---
Due to Haskell's laziness, IO isn't actually the reader monad, but actually more closely related to the state monad, but in a strict language that wouldn't be required.
There is nothing special about the [IO a] -> IO [a] in Haskell. You can iterate over it using the "normal" methods of iterating just fine.
forM ios $ \io -> io
But there are better ways to do it (e.g. sequence), but those are also not "special" to IO in any way. They are common abstractions usable by any Monad.The old website was much faster. And you could fit all the information you needed on a single screen. No scrolling. It was great.
AFAIU, for LDL and ApoB, the real danger lies in the area under the curve. Lifetime exposure. That's not to say that lifestyle improvement can't help in other ways, but the damage caused by LDL is very difficult (impossible) to reverse.
So, if you hit the point where you already had a heart attack, you really want to prevent any further damage, but the "accumulated" risk is still there.
I think that's part of what makes LDL so tragic. You should care about it your whole life, but when you are young, you just don't.
Worse, high LDL is becoming a thing in children as well, that's an extra decade of accumulation which has historically not happened.
I don't think people should panic about these things, but I think it highlights the importance of developing good habits early, and the role parents and society has in making those habits easy for young people to adopt.
Would like to hear about the ergonomic problems you have with souffle. We integrate it into our rust tools quite well, and generate typesafe rust bindings to our souffle programs, allowing us to insert facts and iterate over outputs.