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

> a person on a very limited SNAP budget will get less food under the new restrictions ... make it so that fresh produce and other healthy options are cheaper than the junk food

I'm confused by these statements. How are you deciding to measure the quantity of "food"? If you see food as a means to deliver nutrients, fresh produce is already far cheaper than junk food.

From the perspective of your body, you can sustain yourself much better on a smaller amount of nutrient dense calories than a larger amount of empty ones. Obesity is not merely an overconsumption of calories or a measure of food or body mass.


Juice is not worth the squeeze if the customers who spend more shop online.


You think online retailers don't do these things?


Brick and mortar do it too.


I'm surprised nobody else has mentioned that almost 25% of the entire US workforce is remote and this has dramatically moved shopping over to online delivery.

In-person grocery store trips mean something else now for tens of millions of people, so store security to also has to change with that big of a shift in demographics.


> I'm surprised nobody else has mentioned that almost 25% of the entire US workforce is remote and this has dramatically moved shopping over to online delivery.

How does surveillance prevalent with online delivery services substantially differ from biometric ones?

> In-person grocery store trips mean something else now for tens of millions of people, so store security to also has to change with that big of a shift in demographics.

This just doesn't make sense.

Are you asserting that people going into grocery stores now are more likely to commit theft due to those using online delivery services no longer engaging in on-premise shopping?

Or is it your premise that people who typically use online delivery services only go into grocery stores to steal?


Are you suggesting that a shift to online shopping led to a new demographic going to grocery stores in person? I would have expected that demographic would have went to grocery stores all along. What has changed that introduced a new demographic? And why does it mean security has to change?


Overall foot traffic is down in stores. People who shop online don't go to the store as often, and when they do they expect a worthwhile experience and to probably spend more. They're going to the grocery stores with the craft beer on tap, proper restaurants, etc. They know their online shopping is already monitored and cashless, so it's only a minor annoyance to see that in person. Not many are going to walk away just because of that. Those nicer stores are also in the wealthier neighborhoods where the expectation is safety while they spend extra time with the shiny new amenities in a smaller more peaceful crowd.

The people who avoid online and delivery may not have a choice and are more price sensitive or likely to shoplift, so those other stores also have to increase security.

I'm saying that people have become segregated. The suburbanite middle and upper classes don't "stop by on the way home from work" anymore and they aren't leaving home just to shop unless it's worth the hassle. They expect much higher levels of convenience and safety than ever before. Increased security everywhere makes sense.


The funny part is how they think this will give them the power to take control of what is the defacto standard and circumvent standards.

It will instead further distinguish what is AI slop because it doesn't work and be siloed off to people who don't care about the code so can't fix it.

If people want good interoperable production ready code that can be deployed instantly and just works and meets all current standards and ongoing discussions, we've had it for many decades and it's called open source.


It's not that people care about quality, but that people expect things to "just work".

Regarding the point about accessibility, there are a ton of little details that must be explicitly written into the HTML that aren't necessarily the default behavior. Some common features of CSS and JS can break accessibility too.

None of this code would obvious to an LLM, or even human devs, but it's still what's expected. Without precisely written and effectively read-only boilerplate your webpage is gonna be trash and the specifics are a moving target and hotly debated. This back and forth is a human problem, not a code problem. That's why it's "hard".


I use the web every day as a blind user with a screenreader.

I would 100% of the time prefer to encounter the median website written by Opus 4.5 than the median website written by a human developer in terms of accessibility!


That's really interesting. Are you speaking from experience with websites where you know who authored them or from seeing code written by humans and Opus 4.5 respectively?


So I have been using the human-authored web since well... 1999 or so, starting with old AOL CDs. I've obviously seen a lot of human content.

Back in the old days you might have image links and other fun stuff. Then we entered the era of flash. Flash was great, especially the people who made their whole site out of it (2004 + not being able to order ... was it pizza? something really sticks in my memory here.)

Then we entered the era of early Bootstrap. Things got really bad for a while -- there was a whole Bootstrap-Accessibility library people ended up writing for it, and of course nobody actually used the damn thing. The most frustrating thing at this point (2010?) was any dropdown anywhere. Any bootstrap dropdown was completely inaccessible using typical techniques, and you'd have to do something tricky with ... mouse routing? Gods it's been 15 years.

CAPTCHAs for stupid things became huge there for a brief moment -- I remember needing to pass a CAPTCHA to download ... was it Creative drivers? That motivated me to make a service called CAPTCHA-Be-Gone for other blind people for a while.

Then we see ARIA start to really come into its own... except that's a whole new shitshow! So many times you'd get people who thought "Oh to add accessibility, we just add ARIA" and had no fucking idea what they were doing, to the point where the most-common A11y advice these days has become "Don't use ARIA unless you know you need it."

Oh then we had this brief flash (~10 years ago?) of "60 FPS websites!" -- let's directly render to the fucking canvas, that'll be great. Flutter? ... Ick!

Nowadays the issues are just the same as they ever were. People using divs for everything, onclick handlers instead of stuff that will be triggered with keyboard... Stuff that Opus just doesn't do!

I guess I've only been using Opus 4.5 for about a month but just ... Ask it to build something? Use it with a screen reader? Try it!


> Then we see ARIA start to really come into its own... except that's a whole new shitshow!

I am not blind, but my experience trying to write accessible web pages is that the screen readers are inconsistent with how they announce the various tags and attributes. I'm curious what you think about the screen readers out there such as NVDA, JAWS, VoiceOver, TalkBack, etc. and how devs should be testing their web pages.

Many of the larger corporate clients tend to standardize on the exact behavior of JAWS and I am not sure that is helpful. It's like the Internet Explorer of screen readers.

If you want to know why a page ends up riddled with ARIA overriding everything, that's why. In even the best cases, the people paying for this dev work are looking for consistency and then not finishing the job. It's never made the highest priority work either since testing eats up a ton of time.

To reinforce my original point, I just don't think LLMs can write anything but the most naive code and everyone has opinions and biases completely incompatible with standardization. It's never "done" and fundamentally fickle and political just like the rest of the web.


Knowing obscure things you need to do for accessibility is actually something I would expect an llm to be pretty good at.


Satisfying constraints like these isn't merely about knowing the spec and having lots of examples. Accessibility requirements are even more subjective than ordinary requirements already are to begin with.


I think at least we have gradients and less muted colors coming back.

We also have way better typography than 20 years ago, and I think that's what truly makes older designs "look old". They were restricted to web-safe fonts and had to put stylized text and wordmarks into low resolution images. We have better browser support for SVGs too.


I'm having a hard time thinking of a good time signature that accents on a subdivision smaller than an eighth. Can you give an example?

I also don't know any musicians that would count everything. I usually hear "and", "and" "uh", "ee" "and" "uh", etc. between the downbeats and numbers are typically used to count whole notes.


I don't think so. Most of these are based on the box art.

I'm not saying web design is the same thing or easy, but I am saying the major elements of the design were decided on already and there's little chance it was done without those same people involved.


Fun game, but the animation style is too distracting for me. Maybe there should be an option to disable it or have it stop automatically.

I didn't initially expect it would be a problem, but the constant squiggly movement gets very annoying.


> The Uncle Bob approach of extractNameMatchingTransfersWithinSettlementWindow() doesn't actually help - now I need to know what settlement windows are anyway, and I've lost the context of why 3 days.

When the name is long, it should be more than one function. Finding the transactions within a settlement window seems distinct from matching them up.

The comment about 3 days isn't necessary when "numDays" is a variable in the SettlementWindow class (or other relevant scope). I'd be a lot more comfortable reading code that makes this concept a proper abstraction rather than just seeing a comment about a hard-coded 3 somewhere. Magic values are bad and comments don't demystify anything if they get out of sync with the code.


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

Search: