Hacker Newsnew | past | comments | ask | show | jobs | submit | frogulis's commentslogin

Funny that I could guess that the link would be to that CGP Grey video :D

Adam Something has a video responding to it that's worth watching too: https://www.youtube.com/watch?v=oafm733nI6U


"Turning urban areas into obstacle courses for pedestrians" was an excellent way to phrase that problem!

Driving in Melbourne -- I won't generalise to the wider Australia -- is often much the same.

Comparing to the experience of being a passenger on a bike in Saigon, the level of cooperation there is way higher, possibly due to a sort of necessity. I had this feeling while observing traffic there, that, while the latency and throughput of the roads during high traffic times are still kinda awful, at least for bikes there's a slow continuous progress that simply wouldn't exist without cooperation.

Funnily enough, my experience driving in Los Angeles was distinctly not terrible. Traffic was usually good enough to drive in, though there was very little regard for the speed limit on the freeways! I suspect I may have just been lucky to miss the worst of the traffic.


First class functions and iterators are probably examples of what they mean, in terms of language features that obsolete (GoF) design patterns

It occurred to me at some point that what many "fine" foods have in common is fermentation. Tea, coffee, chocolate, cheese, alcohol, cured meats, dry aged meats, others I can't think of right now. Makes sense, as the complex biological processes are of course going to lead to the culinary complexity and variety that is necessary for connoisseurship.


It's a good observation, though many of those are also food for poor people. Wealthy food is often a refined version of what everyone else eats, usually requiring a lot of extra effort and time.

Lobster is a famous example (though I am skeptical of the story that prisoners revolted over being forced to eat it too much; I have been unable to find a reliable primary source). A beautiful example is from the film Ratatouille, where the eponymous dish is contrasted between his mother's peasant stew and the $50 a plate Thomas Keller version.


Apparently the prisoners were forced to eat ground up boiled lobster. Shells and all

Also lobster is really only good because they absolutely drown it in butter


Makes sense, the process is complex, the mixture of micro organisms is complex, and generates many complex molecules giving fermented foods a depth of flavor, a broadness and finesse. Especially when compared to bland, few-ingredients-taken-from-crude-oil "highly processed" foods.

I experience this with my sourdough bread, the smell of the sourdough and the bread vary and are subtle, deep and nice. The bread is dry and stale in a day though, so the bread is the family's favorite, but only when it's fresh. Although freezing it after it has been properly cooled is not half bad.


Sourdough bread too?


Is there any reason today to use RSS over Atom? Atom sounds like it has all the advantages, except maybe compatibility with some old or stubborn clients?


People still refer to all these as RSS, even if Atom is actually in use.


A great summary why Atom is better [1].

Here's an oldie but a goodie regarding RSS vs Atom [2]

[1]: https://ittavern.com/difference-between-rss-and-atom/

[2]: http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared


RSS itself provides no benefits over Atom. In fact, you're quite likely to see a bunch of RSS feeds that use elements from the Atom namespace.

You should just use Atom.


Tangential question: what's an "armory gym"? Google gives me a specific gym (in Australia) called "The Armoury".


As I understand it, it's a US thing. In areas with snow the local military branch had a drill hall as part of the armory, to carry out drills in winter. These were large open interior spaces.

The military moved away from using urban armories. These became repurposed as sports halls, places for events, and so on. For examples, https://fightingillini.com/facilities/ui-armory/5 and https://www.wakefieldma.gov/Facilities/Facility/Details/Dril...


My read is: it's saying that if your executive compensation (etc.) is capped to a portion of the cost of care, and if your execs want to be paid more (etc.), then the required change is for the cost of care to increase.

Nothing special about the 20% proportion, just that it's proportional to a number which results in perverse incentives.


Actually, thinking through it again fresh, I think it does all hinge on what the percentage is - but some other variables come into play (it's not a single percentage fits all) and then it quickly turns to madness because of the complexity of the system.

If the percentage is higher than the unconstrained optimal margin then the cap has no effect. There's no new pressure introduced yet.

If the percentage is lower than the unconstrained optimal margin then the only incentive is to increase the cost to raise the cap until right at the point demand decreases enough that any more cost would actually result in less total revenue. Because medical care is often very inelastic, that'd could quickly be a lot of cost inflation even for just a few percentage point constraint off the optimal margin. This is the part you're highlighting, and that makes sense.

The main counteracting force to this would be that a single insurer does not (theoretically, at least) set the cost of care directly on their own, they (theoretically, at least) compete with each other to negotiate the best care rates to have the most consumers go through them. There are several things which practically get in the way of that though, like how often you can actually change insurance plans or how competitive the open insurance market is (if you even have multiple options, some states only have a single marketplace option) vs just sticking with whatever your work offers.

Between all of that it is where comes back to the common refrains of "and that's why we need to go to a single payer system without profit as the main goal" and "and that's why we need to get rid of the ACA and let the market handle optimal profit naturally". Everybody can't seem to agree which way to go, just that they don't like the current way. Ironically, these approaches effectively map to the 0% cap (single payer, no profit focus) or the 100% (no ACA cap, free insurance market) interpretation options I originally listed.

I'm sure there about a billion other nuances not covered or thought about in this... but at least the comment parses now!


Which is funny, because my mind filled in the word "social media" and I thought it was a fair point, until I got to the word "Cable".


Same. It's almost like everything has been enshittified to the point that the same complaints can be made in numerous places.


> I found the thesis of this article difficult to nail down

By the sounds of it, the author would be okay with that!


Been a while since I've watched/read it, but I remember the ideas in Maybe Not being quite interesting.

To me, the really important idea wasn't a criticism of static types in general.

Instead it was the idea that static typing in most (all?) mainstream implementations conflates concepts that should be separate, specifically the shape of the information that we have (e.g. what fields of what types), and whether a particular bit of information is available and required (e.g. nullability).

He contends that the former belongs in our usual "type definition", whereas the latter relates instead to a given context. For example, my PassportForm type always has a date-of-birth field in its _shape_, but whether it's statically required/present to exist depends on whether we're at a HTTP API boundary, an internal domain function boundary, writing into a database.

It sounded like that kind of "nullability masking" was intended as a feature of Spec, but I don't get the impression it was ever implemented.


I think they were ideas being experimented for Spec2, but I think that's a bit on a hiatus.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: