sally1620

There are a lot of these type of articles that conclude that "we", the developers, need to fix this problem. But if you read the original article by Prof. Wirth, it is not up to "us".

It is the reality of the software industry. Time-to-market is the only rule. and it dictates how we write software: Agile, Scrum, don't reinvent, deploy early, fix it later, technical debt.

There are many of us who care about quality of our work. But in performance reviews, the only thing that matters is how many features you shipped. You cannot demonstrate the quality of your work in your performance review. Or better yet, the fact that the software you wrote is going to be bug-free for next 10 years.

VSCode team's highest priority is Javascript/Typescript, everything else is just trailing behind. Python and C++ are the very well supported ones. .NET is still really bad.

Technical advancements are always held back by politics. This is one of the main advantages of GPL, there is no CLA to sign.

"cross-platform" software that only runs on Linux and Windows.

Apple definitely doesn't have monopoly over anything. They are popular, but their market share doesn't put them in a monopoly category. And of course Apple doesn't like cross-platform Apps, especially PWAs. Because how else would they make money off of them. It is all about business.

Runs on a platform is very different from "officially supported"

Testing your own code is quite a conflict of interest. Of course you are going to make sure that all your tests pass. And argue that the corner cases that you didn't test will never happen in production.

Most of monorepo tools for Mercurial are upstreamed already and are available in a standard Mercurial install.

I don't think anyone in this thread is CTO of a company size of Facebook. For a medium size company, you can easily use Mercurial or Perforce.

That is actually one of the advantages of the BSDs. Kernel and base system are in one repo and released together. It simplifies development and testing. and an easier upgrade for end-users.

What author misses is that multi-repo is also not dumbass proof. Our team of about 60 people owned about 5-6 git repos that compiled into one SO. Every simple bug fix required multiple diffs to multiple repos.

The real argument that the author is making is that worse is better. Monorepo requires good tooling and a disciplined team. Multi-repo is worse but it is easier to manage when dealing with inexperienced programmers who want to have their own repo for their shiny little microservice.

IMO, the difference is that multi-repo has limitations and mono-repo has challenges. You will never get atomic commits and precise versioning in multi-repo. With mono-repo, there are a lot of challenges that can be solved with good engineering.