In coursework, references are often a way of demonstrating the reading one did on a topic before committing to a course of argumentation. They also contextualize what exactly the student's thinking is in dialogue with, since general familiarity with a topic can't be assumed in introductory coursework. Citation minimums are usually imposed as a means of encouraging a student to read more about a topic before synthesizing their thoughts, and as a means of demonstrating that work to a professor. While there may have been administrative reasons for the citation minimum, the concept behind them is not unfounded, though they are probably not the most effective way of achieving that goal.
While similar, the function is fundamentally different from citations appearing in research. However, even professionally, it is well beyond rare for a philosophical work, even for professional philosophers, to be written truly ex nihilo as you seem to be suggesting. Citation is an essential component of research dialogue and cannot be elided.
Hmm... reads a bit like an email a forum moderator might send a disobedient user. This seems strange, verging on unprofessional, for corporate communications.
Restrictions on SNAP are tricky business. You can't ask someone on SNAP to spend time preparing food. Prepared meals are expensive, often not accessible, and sometimes difficult to prepare for people with certain disabilities. It might seem strange, but I have known people, very poor people, who rely on "foods in bar and drink form" out of necessity. I have known poor people for whom eating fruit is physically challenging.
SNAP changes like this may be better on a population health level, to be sure. On this I have no evidence. But each restriction placed on food for people living in destitution may mean some people go hungry. (And this excludes issues of caloric density.) I would like to see better data, but sadly, there is none.
+1 – it's all well and good for me to buy just some vegetables this week, because I have a pantry full of hundreds of dollars worth of basics, spices, a herb garden, bulk (more expensive) rice/pasta, etc. I also have a single 9-5 job so can spend an hour each day cooking.
But if I had an empty kitchen, lacked the funds to invest in bulk purchases, and had 30 minutes to cook and eat, I'd be eating very differently.
What they need to do is handle disability better. When you try to make it one size fits all you're either too generous with the cheap problems or too stingy with the expensive ones.
As others have pointed out, that's not what the restriction seems to be limited to. The distinction isn't based on sugar content but the amount of "processing", which rules out quite a lot of things beyond just candy and soda.
One can say "they probably had data to support it" about virtually any decision. It is not really a defense from critique. It may have been deliberate, but it still feels wrong and bad.
The fact is, most of the systems people use in their day do day that behave the way described simply require no mastery whatsoever. If your product, service, or device is locked behind learning a new skill, any skill, that will inherently limit the possible size of the audience. Far more than most realize. We can rail against this reality, but it is unforgiving. The average person who is struggling to put food on the table only has so many hours in the week to spare to stick it to the man by learning a new operating system.
It seems we’re all experiencing a form of sticker shock, from the bill for getting ease-of-use out of software that we demanded for the past few decades.
Cold take: honestly, just let users learn how to use your software. Put all your options in a consistent location in menus or whatever - it's fine. Yes, it might take them a little bit. No, they won't use every feature. Do make it as easy to learn as possible. Don't alienate the user with UI that changes under their feet.
Is "learning" now a synonym of "friction" in the product and design world? I gather this from many modern thinkpieces. If I am wrong, I would like to see an example of this kind of UI that actually feels both learnable and seamless. Clarity, predictability, learnability, reliability, interoperability, are all sacrificed on this altar.
> The explosive popularity of AI code generation shows users crave more control and flexibility.
I don't see how this follows.
The chart with lines and circles is quite thought-leadershipful. I do not perceive meaning in it, however (lines are jagged/bad, circles are smooth/good?).
I will at least remark that adding a new error to an enum is not a breaking change if they are marked #[non_exhaustive]. The compiler then guarantees that all match statements on the enum contain a generic case.
However, I wouldn't recommend it. Breakage over errors is not necessarily a bad thing. If you need to change the API for your errors, and downstreams are required to have generic cases, they will be forced to silently accept new error types without at least checking what those new error types are for. This is disadvantageous in a number of significant cases.
Indeed, there's almost always a solution to "inergonomics" in Rust, but most are there to provide a guarantee or express an assumption to increase the chance that your code will do what's intended. While that safety can feel a bit exaggerated even for some large systems projects, for a lot of things Rust is just not the right tool if you don't need the guarantees.
On that topic, I've looked some at building games in Rust but I'm thinking it mostly looks like you're creating problems for yourself? Using it for implementing performant backend algorithms and containerised logic could be nice though.
The fight for this kind of legislature has been ongoing for many years as part of a broader program that seeks to shape the kinds of information that can be stored, consumed, and propagated on the Internet. Age verification is only one branch of the fight, but an important one to the many who support government control: it is an inroad that allows governments to say they have a stake in who sees what.
I'll admit this may be naive, but I don't see the problem based on your description. Split each step into its own private function, pass the context by reference / as a struct, unit test each function to ensure its behavior is correct. Write one public orchestrator function which calls each step in the appropriate sequence and test that, too. Pull logic into helper functions whenever necessary, that's fine.
I do not work in finance, but I've written some exceptionally complex business logic this way. With a single public orchestrator function you can just leave the private functions in place next to it. Readability and testability are enhanced by chunking out each step and making logic obvious. Obviously this is a little reductive, but what am I missing?
While similar, the function is fundamentally different from citations appearing in research. However, even professionally, it is well beyond rare for a philosophical work, even for professional philosophers, to be written truly ex nihilo as you seem to be suggesting. Citation is an essential component of research dialogue and cannot be elided.