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 am developing my own programming language, but I have no specification written for it. When people tell me that I need a specification, I reply that I already have one - the source code of the language compiler.
You are not wrong. But, they are not wrong either.
I feel like if you’re designing a language, the activity of producing the spec, which involves the grammar etc., would allow you to design unencumbered by whether your design is easy to implement. Or whether it’s a good fit for the language you are implementing the compiler with.
The OP also correctly identifies that thoughtful design takes a back seat in favor of action when we start writing the code.
A corollary to the linked article is that a specification can also have bugs. Having a specification means that you can (in theory) be sure you have removed all inconsistencies between that specification and the source code, but it does not mean you can know you have removed all bugs, since both the spec and the source code could have the same bug.
A bug is a difference between specification and its implementation. In no specification exists, there is no bug (strictly speaking). In a more wide sense a bug is a difference between some implementation and user's expectations, but such expectations may be considered to be some sort of non-formal specification.
What do you mean "usable specification"? Usable to produce another compiler implementation for the same language? This IS possible (like clang was designed to match GCC behavior).
Pure specification itself is useless without actual implementation (which does the job), so, trying to write such specification (in a natural language) has no practical sense.
You partly answered your own question by mentioning "implementation". Specification and implementation are two different things, and both are important.
A specification describes the externally observable behavior, constraints, and properties of a system. That's independent of how those properties are implemented.
An implementation is a concrete realization of a specification, that achieves the specified behavior using particular algorithms, data structures, and operational mechanisms.
> Pure specification itself is useless without actual implementation (which does the job), so, trying to write such specification (in a natural language) has no practical sense.
That's a non sequitur, i.e. the part of your sentence after the commas doesn't follow from the first part.
"Pure specification itself" has a purpose, which is to guide implementations. That's the "practical sense".
Having thousands of satellites also allows finding more software bugs, so that in the reality they can be more reliable compared to NASA-style probes (when each one has its unique software).
reply