I would say it more depends how the environment is designed and what transport options you have at your disposal.
In suburbia where the grocer is surrounded by a parking lot and there's busy roads to navigate nearby then of course people would drive rather than walk, and thus also end up getting a week's worth of groceries at a time.
In a dense mixed use environment where it is easy enough to navigate on foot then the urge to drive lessens and all grocery shopping can be done more frequently and on foot or by public transport.
I've experienced this personally in Australia, where living in suburbia I went grocery shopping once a week with a car and brought back many bags worth at a time, and also in a more dense neighbourhood where I could get groceries on the walk back from work more frequently and barely used my car even once a month. In Europe I only ever walk or get public transport for groceries as I live in a dense area and don't need to own a car.
There is some evidence of that, where the closer the crowd is to the field the more likely the referees are to call in the home team's favour. There was a study on this, probably close to a decade ago now.
> That's a feature: Where did the string come from if not the user?
Many games and applications store floating point values in text file formats. This has caused bugs in those programs many times over because they didn't realise it was locale dependent and the data parsing broke in another locale.
I don't support the nonstandard use of commas as decimal points in my software, so that's not an issue for me. That's a hill for the Europeans to live and die on. "Gotta be different from everybody else" has a price.
Ah, yes, the Azerbaijanis and the Belorussians, can't forget them. About 27% of the world population in total, if the clanker's more detailed report is to be believed.
Regardless, it's goofy. Everybody should agree on one or the other, and it's too late for the other 73% to switch.
> Many games and applications store floating point values in text file formats.
And why, pray tell, would those games and applications ship with text files containing floating point values that were invalid?
Certainly if they produce the values, strtod() is sure to work, and worrying about errors at that level just doesn't make any sense at all.
> This has caused bugs in those programs
I'm sorry this just isn't true: The programmer caused the bugs in those programs and nobody else.
Meanwhile users who produce text files with floating point numbers in their locale expect program that load those text files to tolerate their locale, and those programs should not be using strtod()!
The floating point values were valid, they were stored in the text files (unknowingly) in a locale dependent way, either by having a program use a locale sensitive functions to write the values, or because the values were written by hand using the developer's native way of number formatting. The values were then read using the locale dependent functions (like strtod) and if run on a machine with a locale that formatted numbers differently (i.e. using comma for decimal separator) they would return incorrect values.
This caused issues in the game as the values would be significantly different than originally designed, and it would be hard to test for since the people testing the game would usually be using a similar locale to the developer writing the game, and therefore they would only become apparent upon release or wider testing. Now the fix was to explicitly specify the locale before reading the data files, but it still took time to find and implement the fix.
I would not agree. That sounds to me like the floating point values were not valid, because they were stored in the user's locale and were not intended for the user themselves to consume, but for the developer (who is not the user), or another person (who is also not the user, even if they are a user).
I understand maybe they "should be" valid, but they weren't, and the programmer should not have written files in the users locale that they did not expect the user to edit personally; that they intended to consume mechanically, even if they found it convenient as a human being to edit the file on occasion.
> differently (i.e. using comma for decimal separator) they would return incorrect values.
My suggestion reports an error. strtod() can also detect this error (that's what the second argument is for), so the programmer was not checking if they were using strtod(). This is also not the kind of error the article is talking about detecting.
I don't think you understand the situation so I'll try explaining it one last time.
The developer stored floating point values in a text file written out by whatever means, in the developer's locale (say en-US). These files were shipped with the application and the values were read in using locale sensitive functions on a user's machine (the developer was unaware of the locale sensitive nature of these functions), and the user's locale was something different like de-DE for example. This resulted in a different value being read in compared to the value expected by the developer, therefore causing issues in the rest of the program.
For example the file stored "1.05" which in the developer's en-US locale is "one and five hundredths", but reading it on a different user's locale (de-DE) could result in the value being "105" (one hundred and five), or even "1" (one).
These files are generally not considered to be edited by users (unless they are modding the game, and then they do so without warranty etc).
> This resulted in a different value being read in compared to the value expected by the developer
> the developer was unaware of the locale sensitive nature of these functions
> causing issues in the rest of the program
Still sounds like "the programmer caused the bugs in those programs and nobody else" and they would not have that the problem you describe had they either used strtod() correctly or had used my parser.
Are you trying to tell me someone else put the bug in that programmers' code? Or do you actually think you have a pair of locales and a single floating point value that will produce two valid but different floats with my parser?
If all you do is write requests and then have the LLMs spit out the code then you're not a programmer, you're a middle manager. So maybe you never actually wanted to be a programmer but instead you liked having things built?
You are delegating work and reviewing delegated work, but not managing. No performance coaching, no career development, no mentoring, no conflict resolution, no influencing opinions, and on and on.
So it looks like you're doing all the management work required by your reports, and if your reports were more capable you'd need to do more of the other things mentioned as well.
My original comment was to signal that if all you do now is write descriptions to feed to agents then you're not a programmer any more but you've become a manager as what you're doing is a management role and not an artistic or engineering one. You've changed jobs and you should be fine with that, just acknowledge it and move on, but stop fooling yourself that you're still a programmer or engineer. You're not, you're a manager now, even if you're not doing most of the things required of a people manager, as in your comment.
That's silly. You may as well say Santiago Calatrava isn't an architect any more because he's delegating the vast majority of the architecture work for his projects.
If 5 hours of thinking time to solve a problem is unthinkable to some people does that mean they have some form of Attention Deficit Disorder, be it a natural thing or introduced by an over-dependence on LLMs? Like stopping for an hour to think through a problem is unfathomable and instead they would rather hit small dopamine spikes every few minutes from talking to a chatbot?
It is a very rare occurrence when corporations and the people running them are punished for killing people. I mean the whole concept of a corporation was created to shield the owners of it from being liable for damages caused by / visited upon the enterprise.
That’s a good reminder of a company that might have a very familiar ethos: Pacific Gas & Electric. Criminally convicted of 64 counts of involuntary manslaughter after towns were destroyed by wildfire. But oh well, what are we gonna do with a limited liability enterprise? At this point their liability insurance covers all the financial penalties they’ll need to spend.
I'd say the bigger issue is not the way it listens for the wake word, it's the recording and processing it does afterwards for a significantly long period of time, recording for much longer than people anticipated, and with a microphone that can pick up conversations from much further away or even behind walls.
This combines with two other dangers, one of unintended recordings when the wake word is triggered unintentionally, and one of intended recordings by third parties based on various other wake/watch words. They already have it in the T&C that they will share this data with law enforcement, so it's not that far fetched that these TVs and other appliances will spy on people in the home far more effectively than even the East German Stasi could have ever imagined.
Not only that but to read every single related T&C from the whole chain of partners, and to keep track of it when it changed, is basically impossible.
This sort of malicious compliance of using T&C to enable bad behaviour by corporations needs to be fixed with laws.
Reminds me of cookie banners, the dark pattern where they've decided to be deliberately verbose and annoying in order to get people to take the easy path and agree to let them continue doing their bad behaviour.
In suburbia where the grocer is surrounded by a parking lot and there's busy roads to navigate nearby then of course people would drive rather than walk, and thus also end up getting a week's worth of groceries at a time.
In a dense mixed use environment where it is easy enough to navigate on foot then the urge to drive lessens and all grocery shopping can be done more frequently and on foot or by public transport.
I've experienced this personally in Australia, where living in suburbia I went grocery shopping once a week with a car and brought back many bags worth at a time, and also in a more dense neighbourhood where I could get groceries on the walk back from work more frequently and barely used my car even once a month. In Europe I only ever walk or get public transport for groceries as I live in a dense area and don't need to own a car.