> You describe your project in a simple craft.toml
I don't like it. Such format is generally restricted (is not Turing-complete), which doesn't allow doing something non-trivial, for example, choosing dependencies or compilation options based on some non-trivial conditions. That's why CMake is basically a programming language with variables, conditions, loops and even arithmetic.
Platformio is not simple by any means. That few .ini files generate a whole bunch of python, and this again relies on scons as build system.
That's a nice experience as long as you stay within predefined, simple abstractions that somebody else provided. But it is very much a scripted build system, you just don't see it for trivial cases.
For customizations, let alone a new platform, you will end up writing python scripts, and digging through the 200 pages documentation when things go wrong.
> Make all of your leaf classes final. After all, you're done with the project - certainly no one else could possibly improve on your work by extending your classes.
It's actually a good advice. A class not designed to be extendable should be marked as final.
Especially since it takes like 2 seconds to make said classes unfinal and there are no negative consequences of doing this.
But 1999, that was peak "inheritance is how we fix everything" thinking.
About the only reason to not do this is if you are writing a library. Even then, it's better to make extensions available through things like closures (not really available in 1999).
In fact, I'd go so far as to say that classes not being final or sealed (C#) by default is another failure to set sensible defaults, akin to "everything is mutable unless explicitly marked const".
Properly designing classes for inheritance takes proactive care and is, in my experience, almost never done unless the author has been forced to by external forces (through APIs or agreements with other developers).
A lot of problems mentioned in the article are solvable by adding more mass - for supplies and spare parts. New generation reusable rockets can allow this. In the past it was costly to launch a rocket, so systems were designed to be compact, but complex/fragile. Cheap space access changes this equation.
Someone needs to analyze samples which can't be contaminated. Like samples from an asteroid. As I know, for a couple of years ago there was a delivery from one.
System APIs requiring passing a null-terminated string are also painful to use from other languages, where strings are not null-terminated by default. They basically require taking a copy of a string and adding a null-terminator before performing a call.
For a couple of months I tried to ask a very tricky question involving Linux sockets API and its strange behavior in some cases causing unexpected slow-downs. The tricky part was that I used my own programming language to interact with sockets and thus examples provided were written in it. Since it was my first question on Stackoverflow I decided to create my post in the playground (or how it's called, I don't remember). The answer of a couple of gatekeepers was shocking - they said that it's likely a problem with my language and not with Linux sockets API and I should rewrite my examples in C instead. I never did this for obvious reasons. One of suggestions was to update my OS, since it was somewhat outdated, which isn't that good advice too. Later I have found myself what was the problem - it wasn't something wrong with my programming language, but I just managed to hit some connection limits in the kernel.
I presume this happens nowadays frequently. All easy questions are answered by chat-bots or have ben already answered and hard questions don't pass gatekeeping.
> Rewriting it in C can prove that the problem is not in your programmin language
It's a lot of work of rewriting it in C. It's doable, but impractical. And such rewrite may introduce new bugs.
Proving that the problem isn't in my language wasn't necessary - there were no room for it to introduce such kind of bug. Language bugs are usually manifest themselves in a way different way, (like broken binary code leading to crashes or accepting invalid code). That's why I have created my question in a first place - while I was sure, that it wasn't a language bug.
> Outdated OS can be the problem as well.
Outdated OS can't be a problem. Basic socket functionality was implemented eons ago and all known bugs should be fixed even in pretty outdated versions of the kernel.
> What kind of advice did you expect?
Eventually I have found myself, that in my test program I create too much connections for a TCP server and its internal connection queue overflows. But it took some time to find it, way longer compared to what could be achieved if my SO was answered. The problem was not so hard to spot considering that I have described what exactly I do. Even providing code examples wasn't necessary - textual description was enough.
Could very well be that your language was the issue and writing a small proof of concept for the specific use case that's problematic in a battle tested language other people know is a standard trouble shooting step. Especially if it was a rare limiting error, that sounds like a trivial thing to be implemented in C with a simple for loop and some dummy data perhaps.
Same with the OS. Only because socket functionality is decades old doesn't mean that you can't hit a recently introduced bug, that could have been fixed in a new version. That also is a standard troubleshooting step.
It doesn't make for bad advice only because you're too lazy to do it.
Hi. It can parse C/C++ and perform auto completion correctly, it does partially support LSP, I'm finishing the full integration but in the meanwhile it's using my own C/C++ parser which works up to the latest MSVC standard, it is written in C because it's the main language I use and I'm comfortable with... It renders text using the WinAPI functions.
In order to perform correct C++ parsing you need to handle includes properly. In order to do this your IDE needs to communicate with some build system (CMake, MSBuild, Make) to retrieve include directories. Is it implemented somehow? Or maybe you use your own some-sort-of build system?
I don't really like complex build systems like CMake or Ninja, I just use a build.bat file which works for basically all projects I use it for. The IDE does not communicate with any build system whatsoever. It stores .h and .c files in a ".trprj" file (just a text file with info on the project and saved data) and upon loading it, it retrieves all .h files and basically recursively walks and find other includes.
It is not a complex system, but that's exactly the design choice I was going for.
When LSP support is ready, that will be much simpler, altough, it really defies the purpose I am building it for, so I'm not really 100% sure about that choice.
Come on. Are you an employed developer? If so, even if you have that much power over the flagship product of the company, that you can use it to pad your résumé, do you think the same happens at Microsoft? By all means, the bugs may speak of skill issues (or may not: there's also crunching, mandated AI... Who knows), but the Cloud-first, push-ads, force-account etc. enshittification is the implementation of a vision I doubt was collectively composed by devs, let alone a single dev.
The ads pushing would be just as possible with a fully native start menu.
Using React for it was probably done since it's just objectively easier and faster to tweak a React app than native components (see various folks complaining about WinUI).
I was addressing the concept of developers taking it upon themselves to rewrite the menu (in whatever; React is beside the point) in order not to seem redundant and to pad their résumés.
my guess is many junior developers without guidance and perhaps a little vibe coding. could be that these new developers are not comfortable anymore with C++ and MFC so they use what they learned in their courses directed at web standards
Sounds like bullshit, I'd rather bet that Microsoft wanted to make some Cloud OS, web friendly thing and expected it to be as successful as Visual Studio Code
Also, I don't think that integrating react app into Windows is trivial
I don't like it. Such format is generally restricted (is not Turing-complete), which doesn't allow doing something non-trivial, for example, choosing dependencies or compilation options based on some non-trivial conditions. That's why CMake is basically a programming language with variables, conditions, loops and even arithmetic.
reply