May 30 00:55
If time is relative in the way that your question is suggesting it is, how are you defining after death in the first place?
 
May 9 18:14
@AshishShukla I'm not referring to the sensation of dying while alive. I'm pointing out that the complete cessation of anything happening to you on a biological level is effectively equivalent to death, which inherently means you don't experience anything (which logically includes a sense of time). That's not an answer to your question as to how/why we experience things when alive, I'm pointing out that sitting still on a chair is not a meaningful example for expressing that "nothing happens". For nothing to happen, truly nothing, you are effectively dead, which seems beside your question.
May 9 18:14
@AshishShukla: It seems a bit tautological because "no changes" would also include no memories being formed or any kind of input from any sense being registered, and I'm wondering how this is meaningfully different from being dead in that moment of "absolutely no change".
May 9 18:14
"even when I am sitting completely still physically, I experience the passage of time" Dead people are completely still. You sitting on a chair does not mean you are completely still, things are still happening in your body. It would be a very arbitrary line to draw for you to assert that not consciously moving some parts of your body is the standard for "nothing is happening". Based on the scenario you are asserting, you're saying that you would expect our experience of time to halt based on whether you are tapping your finger (and otherwise not intentionally moving) or not.
 
Mar 30 21:57
Applying that guideline to a specific scenario is the task of the developer who has been made aware of the spirit of the good practice advice via the guideline.
Mar 30 21:57
Its intention is to indicate the need for concerns/responsibilities to be outlined, and it expresses that through examples of why not doing so would lead to negative outcomes.
Mar 30 21:56
@Basilevs Your responses highlight that you've misinterpreted the purpose of the guideline. As you point out yourself, knowing exactly what to do in a specific scenario requires the kind of context and nuance that a general guideline cannot provide. But the part you seem to keep missing is that the guideline isn't there to tell the developer what the solution is, it's there to tell the developer what the problem is.
Mar 28 03:04
Your argument boils down to "it doesn't answer literally everything and therefore it is useless" which completely bypasses the idea that guideline might be informative instead of fully prescriptive.
Mar 28 03:02
The purpose of the guideline is not to provide the explicit and universally correct answer for every scenario, it's to highlight the purpose of delineating concerns/responsibilities as part of your software development process.
Mar 28 03:01
Again, your observation is based on some kind of inference that the guideline is definitely and universally applicable - which is a nonsensical standard for any guideline.
Mar 28 01:06
I feel like we're going in circles with this, so more concretely: why do you claim these are empty buzzwords? Be specific, don't just vaguely call them vague because that's perpetuating the same problem that you're trying to point out.
Mar 28 01:06
"Retroactive application is just easier to interpret and explain." That is precisely my point, you're interpreting these allegedly empty guidelines as if they exclude the idea that you can retroactively correct/refine your adherence to the guidelines. Whether or not you do it retroactively simply has no bearing on the purpose of the guideline - your insinuation that it is built on an expectation of pre-emptively avoiding any mistakes is simply a misinterpretation on your part.
Mar 28 01:06
[..] neither of them mandate that you must write it correctly the first time and then not revisit your implementation with additional insights further down the line. Iterative development is a separate topic of discussion and should not be used as a deciding argument (neither pro nor con) when discussing SOC and SRP.
Mar 28 01:06
This answer is nonsensical. It states that concerns/responsibilities are empty buzzwords and then continues onto precisely describing how to identify and properly handle them. The first paragraph seems to be built on an incorrect assumption that these guidelines mandate that you do everything right the first time you write your code, but that is simply not the case. While it's true that some people pretend like everything can be predicted if you follow their rule, this is (a) not correct and, more importantly, (b) not part of the separation of concern or single responsibility guidelines [..]
 
Mar 29 18:18
@o.m. My point isn't that the information was declassified, it's that the reporter would not have known for a fact that it was still classified. I'm not saying they didn't have an inkling that this information might be classified intel, but the law focuses on knowingly publishing classified information, which is a higher standard than just "he could have considered it maybe was classified". Whether it was classified is irrelevant. What matters is whether the reporter was aware of it being classified. It being shared in a Signal chat lends credence to inferring that it is not classified.
Mar 29 18:18
@o.m.: Classified and press briefing are not the only two binary states for information. It's perfectly possible for the reporter to indicate that he was reasonably aware that he was given information that they did not intend to share, without therefore assuming it was classified information (which is a very specific technical term in this context). In such a case, the reporter did not knowingly publish classified information, they merely published information that was given to them unintentionally. That is not covered by the law in question.
Mar 29 18:18
As to points 1 and 2 combined, can one argue that (unless it was otherwise explicitly referred to as classified) the fact that it is mentioned in a chat reasonably implies it is not classified information, as this is not an appropriate channel for classified information, therefore you did not knowingly publish classified information by publishing the chat content?
 
Mar 18 19:40
@Peter-ReinstateMonica: Politics aside about questioning who is mentally fit or not; there is an inherent contradiction in refusing to trust a signature purely on the basis of it not coming from a person's own hand, but then trusting a person when they claim to have given informed consent. If you take their word for it, then the manner of penning the signature is irrelevant. Holding a pen in your fingers does not in any way prove informed consent in a way that an autopen wouldn't.
Mar 18 19:40
@Peter-ReinstateMonica John Bollinger's point here is that the core issue is not one of penmanship but of informed consent. This is true of pretty much every signature, where it is the informed consent that matters, not the actual product of the signature (it's not about "getting the signature right"). An extreme example would be a president who has lost their arms - would you reject a signed order purely on the basis of them not having penned it themselves even if you were aware of their informed consent?
 
Mar 18 02:45
Are you asking about civil (or even criminal) liability for damage that the tenants incur due to said issue? Or are you talking about tangential considerations like if the main building breaks its entire plumbing for an extended period, whether the landlord is on the hook for (the cost of) providing adequate temporary housing for the tenant (or suspending rent for that time); in the same way they would be responsible if they needed to deal with an extended plumbing issue that originated within the apartment?
 
Jan 28 08:43
Furthermore, your example is biased, as graphs inherently portray binary relationships (i.e. between two components), which inherently enables you to represent it in a tabular (2D) format. Try doing this for a graph where each relationship requires three components, e.g. a historical evolution of a (changing) graph (making time the third dimension here). Systems are human constructs, which are broken down into what we're comfortable working with, which due to the nature of our written medium (historically) has had a strong upper limit on 2 dimensions.
Jan 28 08:43
[..] On the same line of thinking: why do we have multiple currencies when they could all be converted to a single one? Why do we speak multiple languages when they could all be translated to a single one? Why do we have metric and imperial units when we could just use a single unit of (e.g.) length? Just because you can does not mean that it is meaningfully productive or necessary to do so.
Jan 28 08:43
[..] Even a website, which you'd think of as a 2D object, is still a three dimensional canvas (or what's often called 2.5D in video game terminology) due to the existence of z-indexes. The point I'm getting at here is that there is a distinct difference between what something is and what it looks like to you. Which neatly brings us to Plato's cave allegory for an unusually appropriate 2D vs 3D analogy.
Jan 28 08:43
Your question is the equivalent of asking why you'd ever have 3D graphics in a game that you play using a regular (2D) monitor, or by extension why we model 3D levels when we could theoretically do it as a 2D bitmap from the get go. I can navigate a 3D environment (in a video game) using a 2D monitor but that does not negate the existence of the three dimensions of the underlying level that I'm navigating. One of the reasons devs use threedimensional space is because it most accurately models what they're trying to represent, which is a 3D environment (even if rendered on a 2D output) [..]
 
Jan 17 11:25
This entire comment thread is a neverending holy war on which way we should err: what is written, or what we believe was intended to be written? There is no point going back and forth on this - there are clearly different lines of thinking on this. However, this answer plainly states its bias in the first paragraph, i.e. favoring what is actually written. It is a ridiculous standard to try and force answers to use your bias, no matter how many reasons you can come up with why you think your interpretation is the correct one. This is a well written answer regardless.
 
Jan 7 10:44
@JimmyJames "to be racist" is not the same as "to carry a racist message". The paper and ink are not to blame for the message that the author constructed using said paper and ink. It might seem silly for me to imply that you're saying that paper is sentient and is racist; but AI similarly has no sentience and cannot be attributed racism - it's just easier to forget that distinction when AI sometimes appears to behave lifelike, which a piece of paper never does.
Jan 7 10:44
Consider the true meaning of the word "discrimination": to tell one thing from another. We use the word to refer to what we consider to be an immoral and act of biased discrimination (racism, sexism, ageism, ...). However, that's not the only meaning. If I tell you to find a needle in a haystack, and you find it, you discriminated the needle from the hay. Machine learning discriminates good choices from bad choices (based on what it is told is good/bad output), but it does not inject a bias on its own. Any bias comes from the provided measure of what is good/bad output that it learns from.
 
Oct 25, 2024 17:32
"They were tricked through coercive means." That's not coercion. Coercion entails the victim is aware of what it is they're made to do, but they are still "choosing" to do so, for ulterior reasons. The coercive nature implies that the coercer is choosing to enact those undesirable ulterior outcomes if the victim does not comply. For example, robbery is coercion, you are forced to "choose" to hand over your valuables and not fight back, under threat of being hurt/killed. None of this is trickery, the victim is aware that they are being made to do something they don't want to.
 
Oct 20, 2024 20:36
To put it in concrete terms. If I do not believe that God exists, but I choose to follow the teachings, speak about God, state that I believe, and generally do everything that a true believer does; would you then say that I believe in God? Or would you say that I'm acting as if I believe in God? This sounds like a rephrasing of your question but it's actually asking you to define whether you interpret "to believe" to include disingenuous belief. If it walks like a duck and talks like a duck, is it a duck?
Oct 20, 2024 20:36
There seems to be a semantical trick to it. Are you defining "choosing to believe" to mean that you are aware you do not genuinely believe it, but choose to act in the same way as you would if you had genuinely believed it? Secondly, when you ask if it's possible to "choose to believe", are you referring to genuine belief, not lip service? Because if the answer to both of those is yes, then you're operating under specific definitions that contradict one another, i.e. you cannot choose to believe something you don't think is true, if you mandate that belief has to be genuine.
 
Oct 12, 2024 17:00
The question is valid but unnecessarily restricts itself to knowledge, as opposed to any experience of the ego. You're effectively asking "what's the purpose of it all?", which is the root of philosophy, and whose answer is generally pursued by further defining what "it" means in that question.
 
Oct 4, 2024 18:50
Location aside (as this has been answered already) GDPR is a protection for privacy-oriented data. Security camera footage in a public space is in and of itself not privacy-oriented. Tracking specific individuals (and collecting data on it) is privacy-oriented as it centers on identifying the individual. The issue here isn't so much the camera footage taken from the street (assuming you're capturing everything and not specifically editing it towards a particular person), but the indexing that you perform based on that recording is the real privacy concern.
 
Sep 17, 2024 14:33
"Increasingly, there is a tendency to assume that anything not scientifically proven is inherently false." If you're implying that this is explicitly scientifically suggested to be the case, that would be wrong. If you're implying that this is a layman's misinterpretation of what it means for something to not be scientifically proven, then that observation might be relevant but it has no bearing on the concept of things being scientifically verifiable. A fool can believe anything they want to - that belief doesn't change reality, nor does it mean that anything is therefore possible.
 
Sep 17, 2024 08:13
@ohno If John was hired as a lead, are you then implying that he failed to mention this for months, while presumably believing that this kind of lead role was not unique? I.e. multiple leads, not "the" lead. Something smells here. Either your company allows for multiple leads, which means John did not drive you out; or they don't and then John would have very much been aware that you were conflicting with him.
Sep 17, 2024 08:13
[..] I'm struggling to not see this as being problematic on your end (i.e. what it is you do in your team), unless John was actively avoiding making it obvious that he replaced you. More likely, I'm wondering if you never truly took on the full role of leadership, instead continuing to work like you did in your previous position and only rarely making executive calls; which would explain why it took so long for you to notice any collision, while at the same time John had been focusing on other parts of the role that you hadn't been doing (and thus did not notice any conflict).
Sep 17, 2024 08:13
Who did you think John was, before you realized he was your replacement? You said things were already tense with John, but you never clued onto it happening due to a power collision? The fact that it took months for you to even identify friction on your authority calls a lot into question about your powers of observation, both reflected in (a) how much we can trust your account of the events to be accurate and (b) how aware you are of your actions as a leader, and by extension your actions now that you are no longer a leader, which can very easily explain what's happening here.
 
Jul 4, 2024 00:44
Your comment on Microsoft further suggests that you don't have the full picture on semver. Having backwards compatibility is not proof of not doing semver the right way. Implying that it is means that your take on what constitutes a major version upgrade comes with way more strings attached than is actually the case according to the semver guidelines.
Jul 4, 2024 00:42
You have examples of it being done badly, but I have plenty of examples of it being done the right way. But this isn't an anecdote listing exercise.
Jul 4, 2024 00:41
Semver can (and should, and was created with the intention for it to) be applied in a way that helps clients deal with breaking changes rather than increase the issues. Badly applying a guideline is not the guideline's fault, it's the dev team's fault.
Jul 4, 2024 00:40
I will end on the observation that I'm not denying that your observations about how semver could be used have happened; but I am going to assert that your observations are not the full picture.
Jul 4, 2024 00:39
@Basilevs You've steered this discussion into a very different field now. This isn't a discussion on what semver prescribes anymore, this is a technical opinion across the entire SDLC for an application. You do you, but this cannot be productively discussed in this format.
Jul 3, 2024 08:38
@Basilevs: My suspicion is that you're judging the overall guideline by your firsthand (or secondhand) experience with a dev team that exhibited flaws with their versioning and deprecation methodology that were problematic for their clients; but the problems you are describing are in actual fact not caused by semver's guideline, just by developers badly applying it (and potentially pointing at semver as the supposed justification for their bad decisions).
Jul 3, 2024 08:38
@Basilevs [..] That is the polar opposite of "semver just forces all clients to take responsibility for integration of a breaking change" as you claim. It seems like you think that applying semver somehow increases the amount of breaking changes that get introduced (as per your mention of "a carefully managed upgrade plan that does not affect them in particular"). This is not the case. Semver does not increase the breakage, it tells you to contain the breakage (that was already going to happen), specifically to avoid having to force the client's hand on a schedule that's not their own.
Jul 3, 2024 08:38
@Basilevs: I get the feeling you misunderstand semver. Semver does the opposite of forcing the client's hand. A non-semver service which introduces a breaking change would forcefully overwrite the old way into the new one, forcing all clients into immediate action. A semver service would introduce this breaking change on an alternate path, providing the option to stick with the old way for as long as it would not be deprecated, allowing clients to upgrade to the new version at their own pace. [..]
Jul 3, 2024 08:38
@Basilevs: Sure, needing customer sign-on is a fact of life for services that operate in a buyer's market. I agree with you there. But semver is not a marketing strategy and you shouldn't judge the guideline by decisions made for ulterior reasons which are unrelated to the guideline's content. Semver itself does not inhibit deprecation. Developers (who also use semver) might inhibit deprecation due to their customer's demains. Semver is a strawman in all of this.
Jul 3, 2024 08:38
@Basilevs: [..] The clients don't own the product, for starters. Also, refusing to bump majors or deprecate existing functionality enables clients to stick with stale versions. Service owners should be charting their own development, marking that progress with minor/major version upgrades as appropriate, and deprecate old versions when they're outside of the owners' support range (e.g. too different from the newer product, too many inherent support issues, security issues, ...)
Jul 3, 2024 08:38
@Basilevs "Clients tend to then do X" != "The guideline prescribes this as the correct approach". As per semver.org: "Deprecating existing functionality is a normal part of software development and is often required to make forward progress. [..] Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API." Service owners should not be bulled into staying with the same major version just because clients don't want to upgrade. [..]
Jul 3, 2024 08:38
"you never change the signature of a method once it is published" This may be somewhat of a nitpick but I'd rephrase this to not introducing breaking changes. Extending the signature in a way that does not break the old usage (e.g. upgrading an int to a double, or adding an optional param) don't break existing consumers and don't cause issues. Also, while an edge case, critical bugfixes are allowed to make breaking changes if and only if the endpoint was flawed on release to the point of being unworkable (at which point you're not breaking it, since it wasn't working in the first place).
Jul 3, 2024 08:38
@Basilevs: Semver doesn't particularly inhibit deprecation. All it really preaches is to not inherently have the release of a new endpoint also entail the deprecation of the old endpoint (which is what inherently happens when you apply breaking changes to the existing endpoint). Semver gets you to create new endpoints when they have breaking changes, and while it does include advice on not deprecating previous endpoints at least until a reasonable grace period has elapsed since the release of the new endpoint, it makes no statements about never deprecating old endpoints.
 
May 2, 2024 01:49
Several people have already written responses to you that very much address this exact point about models being unproven, but your responses indicate that you think people are saying that the models have been disproven. Unproven and disproven are two very different concepts and your responses do not make it seem like you really acknowledge that distinction.