> I mean, it's an early leaked build. I predict that the file explorer specifically will be completely replaced, which is why it hasn't been updated at all.
I really hope that _replacement_ will be as feature complete and useful via keyboard as the current explorer. UWP UI components tend to be unnavigable via keyboard.
For example I really like old Win32 listview behaviour to just type in the item name to select it.
> Meanwhile, the big open-source desktop C++ libraries (Qt and WxWindows) still don't fully take advantage of the types and features in the standard library in 2021.
Of course not. C++ and libraries don't go along nicely. STL is not really useful for cross boundary interop due the fact that C++ ABI is not stable.
Shipping libraries that leak STL types all over the place will only give you headache.
If you start from scratch, I'd suggest to use MSIX [0] instead. It makes auto update trivial to implement with PackageManager.UpdatePackage(url_to_your_msix)[1] or plain execute via "ms-appinstaller:?source=url_to_your_msix". It'll do diffs properly and you also get package reflection for free via WinRT apis (such as where app is installed, appdata location, app version, etc).
Assuming I'm not building a UWP app, how do I build an MSIX. The only thing I found was the MSIX packaging tool and the description is this:
"You can run your desktop application installers through this tool and obtain an MSIX package that you can install on your machine or upload to the Microsoft Store. "
I need to look into MSIX. MSI has been handling my needs for awhile now but I hear MSIX is really nice. Thanks for the nudge to look in that direction.
To prevent half assed refactoring in the first place where only namespaces and classes get refactored while folders and filenames remain as they were. It would just further confuse new devs on the project.
_But as the company grew, new engineers who joined couldn’t understand the code. Clever code is usually short and cryptic, written by and for the individual who came up with it, but is hard for anyone else to understand—and nearly impossible to maintain. Guido called this “cowboy coding culture”. He recognized its value in our early stages of trying to implement things quickly, but knew it wouldn’t be sustainable over time, so he decided to speak up in his own quiet way._
And now they'll have to rewrite everything in programming languages where maintenance is not a burden.
No, he is in need of writing production quality software together with his medium to big sized dev team and he doesn't want to introduce maintenance burden into his project 10 years from now. Software will get improved during it's lifetime and not overwritten from scratch every 2 years.
Of course you can write anything in R but that doesn't mean it will be possible to maintain the codebase for the next 10 maybe 20 years including dev team changes.
In other words R is wrong tool to use for building the software just from maintainability standpoint.
I agree that in general one would not use R to engineer software. However I disagree regarding low maintainability.
I've seen very complex R packages that have been around for 30+ years. They are actively maintained. Applying good design principles, unit testing, modularity - all that is very much doable in R.
And you will want to write software in R, especially if the purpose is to support the very activity of working with R packages and to expose the R statistical environment over HTTP. Case in point, the software I link to, in my comment above.
It gives you all the building blocks to implement it yourself.
Remember that Win32 is not UI framework but OS API which allow you to build yourself one (wxWidgets, QT, SWT).