Users matter a ton to windows. Specifically, the users with a hundred thousand or more licenses. Their unhappiness threatens Windows' profits in a meaningful way. Why do you think all the new secure boot and TPM features were added to Windows 11? All that work wasn't free to implement. But big businesses really want that degree of secure fleet management, and they're the customers who matter.
So going back to the GP - pay for software where you're in the largest organized user class. That's how you get power. Paying alone doesn't suffice.
Large entities asked Microsoft to stop simply bundling Copilot with all those services and instead relabel the services so that their usage could be counted as AI usage in their quarterly report whether or not they actually engage with the AI features?
I think it's clear the source comment was referencing end users. It's patently obvious at this point that a large number of people who directly use Windows are frustrated with it, and perceive it to be degrading rather than improving over time.
A corporate end user isn't a customer. The customer is the corporate department of purchases. What I mean in my original comment is that if you as an end user purchase software, then you will be listened to by developers.
It's definitely a shock when something else changes the date object you've been holding on to. The problem with mutable values has never been when you (that is, the local context) change them. It's always that you can't trust that nothing else (some very non-local code) does.
That's a fair observation, and yet anecdotally I agree with the parent comment. In my career I fixed quite a few bugs about dates being passed around and unexpectedly modified, while I struggle to remember the same problem with objects in general (could be a case of selective memory).
If I had the guess, I'd say it's a combination of:
- the difference between the mental model and the implementation. Dates are objects but "feel" like values: dates are parsed from a single value, and when stored/printed they collapse back to a single value (as opposed to custom objects which are generally a bag of properties, and when printed/stored they still look like an object)
- most common date operations causes the original date object to be mutated, which implicitly causes developers to mutate the passed value even if that's not what they explicitly meant
So the default combination is a calling code that expects date to be treated as a value, and the called code accidentally mutating the data because it's convenient to do so. If anything then causes the original value to be saved back in the db, the data gets corrupted.
Most experienced developers will remember to make a copy of the date object both in the calling code and in the receiving code, but the default remains dangerously easy to get wrong.
What parent commenter meant was language level support of immutable objects. There is const, in for example JavaScript, but it supports only immutability of variables, not objects themselves. That later one is possible in C++ for example, where const can be used for both. Of course, it’s still possible to fake immutability with interfaces in some languages, or have a real one forced by implementation (like with Temporals), but it’s much nicer to have an indicator forcing that.
I would like to add, that both variable and object immutability should be the default, and mutability should have a keyword, not other way around how in C++ and Java.
You've described three different features with three different sets of semantics. Which set of semantics is honored? Unknown!
This is not software engineering. This is an appeal to faith. Software engineering requires precise semantics, not whatever the compiler feels like doing. You can't even declare that this feature has no semantics, because it actually introduces a vector for UB. This is the sort of "feature" that should not be in any language selling itself as an improved C. It would be far better to reduce the scope to the point where the feature can have precise semantics.
Typically it's configurable. For example C++ 26 seems to be intending you'll pick a compiler flag to say if you want its do-nothing semantics, or its "tell me about the problem and press on" semantics or just exit immediately and report that. They're not intending (in the standard at least) to have the assume semantic because that is, as you'd expect, controversial. Likewise more fine-grained configuration they're hoping will be taken up as a vendor extension.
My understanding is that C3 will likely offer the coarse configuration as part of their ordinary fast versus safe settings. Do I think that's a good idea? No, but that's definitely not "Unknown".
Any idea how the situation is handled where third party code was written to expect a certain semantic? Is this just one more rough edge to watch out for when integrating something?
I mostly agree with your sentiment, but saying "math is not art" is the same as saying "writing is not art". Calculation isn't art. But math isn't calculation. Math is a social activity shared between humans. Like writing, much of it is purely utilitarian. But there's always an aesthetic component, and some works explore that without regard to utility. It's a funny kind of art, accessible to few and beautiful to even fewer. But there is an art there.
Incorrect. Art is practice. It's literally what the word means historically. Put in "Etymology of the word 'art'" in your favorite search engine or LLM.
If someone is entering a prompt to generate an image in a model I have access to, I don't really need to pay them to do it, and definitely don't need to pay them as much to do it as I would an actual artist, so it is deceptive for them to represent themselves as someone who could actually draw or paint that. If the product is what counts then truth in advertising is required so the market can work.
I would die of embarrassment if I had bad code in a project for me. I am at my limit for tolerating bad code in projects for others, where the economics don't support taking the time that would be required to fix the deep problems. Code for me is going to be good. I won't accept anything less. I need a countervailing force, reminding me of the beauty of clear expression of complex ideas.
Basically irrelevant to taxpayers. Their salaries or triple their salaries will add up to a difference of a couple dollars on the average tax bill. Doge didn't actually cut any of the big expenses. It was only intended to cut the effective things.
Handling negative feedback on a PR is a necessary skill for a developer. A manager should only get involved if it becomes hostile. Negative is very far from hostile.
Handling negative feedback doesn't involve going to anybody - neither the manager, nor the person who gave the PR. Someone giving negative feedback is not supposed to be a conflict in need of resolution. We are talking about a situation where there is a conflict that needs to be resolved, ie that it has already become hostile.
If they are going to their manager, and then the manager, rather than convincing them that they are over-reacting, is instead going to you and telling you that there's something wrong with the feedback you gave, you should handle that negative feedback.
It doesn't matter what I consider a conflict. The fact is someone went to their boss with a conflict because it rose above their threshold of what a conflict is. If one of the parties involved feels there is a conflict in need of mediation, then there is a conflict in need of mediation. Very likely the issue is that the second party didn't realize what they said would cause conflict, which is exactly why the boss should be talking to them.
No one is saying that the boss should be looking for and trying to mediate "conflicts" no one wants them to resolve.
I’m pretty sure the top comment thread was edited because I can’t figure out what we’re debating.
I think the original comment said something to the effect of “employees shouldn’t ever resolve their own conflict, their boss should do it for them”.
I was only trying to illustrate that there are some people out there who are incredibly sensitive and will make a conflict out of the color shoes you’re wearing. Sometimes it’s good to empower an employee to speak their mind about their coworkers hideous color shoes, no need to force boss man to relay the message.
It's more a viewpoint thing. Any construct cryptographers find that runs in constant time is something that could be optimized to run faster for non-cryptographic code. Constant-time constructs essentially are optimizer bug reports. There is always the danger that by popularizing a technique you are drawing the attention of a compiler contributor who wants to speed up a benchmark of that same construct in non-cryptographic code. So maybe it's not intended as sabotage, but it can sure feel that way when everything you do is explicitly targeted to be changed after you do it.
Given that neither the police nor jails are relevant to corporate violations of the law, do you have a point other than that you don't understand either of those?
So going back to the GP - pay for software where you're in the largest organized user class. That's how you get power. Paying alone doesn't suffice.
reply