Wrong. There was full app compat of WP7 apps in WP8 and Win10 Mobile, and for WP8 apps in W10M. The only full backward app compat break was from WM6.5/WP6.5 to WP7.
I'll give you the benefit of the doubt and assume you're thinking of the lack of device OS upgrades: from WP6.5 to WP7, from WP7 to WP8, and from older WP8 devices to W10M. So no forward compat, but absolutely yes to backward compat.
That's not what they mean. As a developer, the API you used to develop your app was now deprecated with no migration path. That meant your app was deprecated, with no migration path.
For an app platform already a distant third place and struggling to attract developers, pissing off the few devs you do have TWICE was not a smart move.
Even then, that happened at most twice as you say, not three times as the other poster said.
And I disagree with your implicit claim that the WP7 & WP8 Silverlight -> Win10 UWP transition had no migration path. There was >= 90% source code similarity, bolstered if you had already adopted the Win8.1/WP8.1 "universal" project templates. And Microsoft provided tooling to ease the transition. Sometimes it was literally just s/Microsoft.Phone/Windows.UI/g.
Games were a different matter, I'll admit. XNA as an app platform had no direct replacement that was binary compatible with Win10 desktop, but even then, not only was DirectX already available from WP8.0, but Microsoft invested in MonoGame as an XNA replacement precisely because they knew the end of XNA would hit hard. (In fact it was the Windows Phone division that had essentially kept XNA on life support in its final years so that WP7 games would not break.)
"the API you used to develop your app was now deprecated with no migration path."
Seems that's the standard now for .NET desktop dev. Every 2 or 3 years MS crank out a new XAML based framework that's not compatible with the previous and never gets completed before a new framework comes out.
Nobody in their right mind should be touching any Microsoft provided API that isn't already well established (like Win32 and Direct3D).
I'm happy they're at least maintaining (to a limited extent) Windows Forms and WPF and updating their styles to fit with their fancy Fluent design.
But even that is a pretty sad state of affairs, since Windows Forms should be able to get that info from uxtheme (which Microsoft fumbled) and WPF should be able to get that info from the style distributed with the system-installed .NET framework (which Microsoft fumbled and now only exists for backcompat).
For the company with the best track record for backwards compatibility (with Windows), they sure suck at developing and evolving the same API for long.
I might be misremembering, but if I remember correctly, back in 2019 Windows' pre-installed calculator had an interesting issue with the Japanese era change in 2019 from Heisei to Reiwa, due to Emperor Akihito's abdication and the succession of his son Emperor Naruhito. I was not personally involved with this issue but I was aware of it as I was working on the Windows team at Microsoft at that time.
The announced plan was that Akihito would abdicate on April 30 and Naruhito would take the throne on May 1, so that Jan 1-Apr 30, 2019 would be Heisei 31 (平成31年) and May 1-Dec 31 would be Reiwa 1/Reiwa Gannen (令和元年).
The issue was with Windows Calculator's date calculation. If you ask it which day is 61 days after April 1, 2019, it correctly calculates June 1, 2019. The question, though, is what if you have your Windows settings set to show the Japanese era year - should it show "2019" in "June 1, 2019" as Heisei 31 or Reiwa 1?
If I remember right, the answer chosen was "it depends on what your computer's current clock time is!" In other words, if you ask Calculator while your PC's clock is set to April 2019 or earlier, it "wrongly" shows June 1, 2019 as in Heisei 31, but if your clock is set to May 2019 or later, June 1, 2019 is "correctly" shown as in Reiwa 1. This would be true even if the running Calculator and Windows code was already updated with the knowledge that the new era would be called "Reiwa." (Though the date when Reiwa would begin was specified by a law passed in 2017, Reiwa's name was only announced on April 1, 2019.)
(I forget whether this problem was solved in the calculator app itself or whether it inherited the solution from Windows' date and time formatting code.)
The justification was that the change of era would only be finalized when Akihito actually abdicated. In modern times, Akihito's abdication was the first time that the era changed without the reigning emperor dying. Calculator acting as if it knew before May 1, 2019 that Reiwa would begin on that day would thus be in bad taste, because it would be the moral equivalent of Calculator predicting or wishing for Akihito's death on April 30 - never mind that it was already well known that Akihito planned to abdicate on that day instead.
Aside: Why do we use the terms "mutable" and "immutable" to describe those concepts? I feel they are needlessly hard to say and too easily confused when reading and writing.
I say "read-write" or "writable" and "writability" for "mutable" and "mutability", and "read-only" and "read-only-ness" for "immutable" and "immutability". Typically, I make exceptions only when the language has multiple similar immutability-like concepts for which the precise terms are the only real option to avoid confusion.
Read only does not carry (to me) the fact that something cannot change, just that I cannot make it change. For example you could make a read only facade to a mutable object, that would not make it immutable.
> Why do we use the terms "mutable" and "immutable" to describe those concepts?
Mutable is from Latin 'mutabilis' - (changeable), which derives from 'mutare' (to change)
You can't call them read-only/writable/etc. without confusing them with access permissions. 'Read-only' typically means something read-only to local scope, but the underlying object might still be mutable and changed elsewhere - like a const pointer in C++ or a read-only db view that prevents you from writing, but the underlying data can still be changed by others. In contrast, an immutable string (in java, c#) cannot be changed by anyone, ever.
Computer science is a branch of mathematics, you can't just use whatever words you think more comfortable to you - names have implications, they are a form of theorem-stating. It's like not letting kids call multiplication a "stick-piling". We don't do that for reasons.
Same reason doors say PUSH and PULL instead of PUSH and YANK. We enjoy watching people faceplant into doors... er... it's not a sufficiently real problem to compel people to start doing something differently.
afaik yes, its what the for-profit companies like turbotax use as well. While its "modernized" in comparison to older systems it was originally created in 2004 (and you can tell because it has XML galore).
Font sizes and families are also a relatively little-used way to visually distinguish things in a code editor.
Years ago I used to work on C++ code in a commercial editor called Source Insight [1]. At its default settings, it would do things like:
1. Show function and class names in HUGE fonts in declarations and definitions, so you always knew what was a declaration as opposed to a use
2. Show nested parentheses with the outermost parens being biggest and getting smaller as you got further in
3. Show comments in a proportional sans-serif font instead of a monospaced one so that you could tell where the comments were even if you have color blindness
Those features, along with having a C++ parser and code relationship visualizer much faster than the Visual Studio of the day without having to parse ahead of time (a la ctags), made Source Insight a near standard in my company. I still miss it on occasion.
You could also use color intensity (faded or bolded or even fully desaturated), animated shrinking/growing font sizes as your cursor moves between code blocks to emphasize the important vs less important data, background coloring, colored box outlines surrounding related code, etc.
So many ways to focus attention and highlight related areas, but so few IDEs that do anything about it...
I remember Source Insight. It was one of those things that some people loved and others hated.
Re: comments in proportional font; while it's an interesting way to highlight them, the problem is that then precludes you from using ASCII art to diagram things in comments (or from reading such diagrams in existing codebases where they exist).
Still possible in VSCode through somewhat hackish methods (esp. arbitrary CSS injection via createTextEditorDecorationType). Here are some quick screenshots of random JS/Rust examples in my installation: https://imgur.com/a/LUZN5bl
I have independently discovered the benefit of (3), having comments (prose) in a proportional font. I think I'll also enjoy (2) too. I'll see how to configure it for my editor.
This is the first time I've heard of Deno so I'm only going by their Security & Permissions doc page [1], but it looks like the doc page at the very end recommends using system-level sandboxing as a defense in depth. This suggests that Deno doesn't use system sandboxing itself.
To me this is a bit alarming as IIRC most app runtime libraries that also have this in-runtime-only sandboxing approach are moving away from that idea precisely because it is not resistant to attackers exploiting vulnerabilities in the runtime itself, pushing platform developers instead toward process-level system kernel-enforced sandboxing (Docker containers or other Linux cgroups, Windows AppContainer, macOS sandboxing, etc.).
So for example, .NET dropped its Code Access Security and AppDomain features in recent versions, and Java has now done the same with its SecurityManager. Perl still has taint mode but I wonder if it too will eventually go away.
Deno is a V8 wrapper, the same JS engine as Chrome. Vulnerabilities are very common there, not necessarily because it's poorly designed but more because there's massive financial incentives in findings them.
This plus what you mentioned is why I would never trust it to run arbitrary code.
Now in the context of yt-dlp it might fine, google isn't going to target them with exploits. I would still prefer if they didn't continue to propagate "DeNo iS SaFe BeCauSe It HaS sAnDbOxInG" because I've seen projets that were actually executing arbitrary JS rely on it thinking it was safe.
Consumer Reports' reviews of newer Mazdas always stress the infotainment system as a big negative, to the point that I would seriously reconsider them as a result.
Apparently it's a case of "right idea, wrong execution." The deep menu hierarchies and small text make the jog wheel knob controls even more awkward (in CR's view) than a decent touch-screen system plus a few buttons. [1]
Maybe that's one reason that BMW has just abandoned their Mazda-like wheel controller [2], despite having had it for years before Mazda.
(Interestingly CR says the latest Mazdas do have a touchscreen, but touches are allowed when the car is moving only for CarPlay/Android Auto.)
[1] https://www.consumerreports.org/cars/mazda/cx-50-hybrid/2025... - "the CX-50's infotainment system is frustrating and distracting to use while driving. [...] the text- and list-based menu structure forces drivers to glance away from the road for too long. Even simple radio tasks require multiple taps and twists of the rotary controller knob"
S. Jay Olshansky et al., "Implausibility of radical life extension in humans in the twenty-first century", Nature Aging (2024)
Open access, here is the abstract:
> Over the course of the twentieth century, human life expectancy at birth rose in high-income nations by approximately 30 years, largely driven by advances in public health and medicine. Mortality reduction was observed initially at an early age and continued into middle and older ages. However, it was unclear whether this phenomenon and the resulting accelerated rise in life expectancy would continue into the twenty-first century. Here using demographic survivorship metrics from national vital statistics in the eight countries with the longest-lived populations (Australia, France, Italy, Japan, South Korea, Spain, Sweden and Switzerland) and in Hong Kong and the United States from 1990 to 2019, we explored recent trends in death rates and life expectancy. We found that, since 1990, improvements overall in life expectancy have decelerated. Our analysis also revealed that resistance to improvements in life expectancy increased while lifespan inequality declined and mortality compression occurred. Our analysis suggests that survival to age 100 years is unlikely to exceed 15% for females and 5% for males, altogether suggesting that, unless the processes of biological aging can be markedly slowed, radical human life extension is implausible in this century.
Indeed, I have heard that at least early versions of Finale had painfully unmaintainable code that severely slowed its development.
This supposedly was/is in part because Finale's original author Phil Farrand [1] was a musician turned self-taught programmer and Finale was only his second software product.
I'll give you the benefit of the doubt and assume you're thinking of the lack of device OS upgrades: from WP6.5 to WP7, from WP7 to WP8, and from older WP8 devices to W10M. So no forward compat, but absolutely yes to backward compat.