Yes, but if you happen to have a few million spare dollars laying around that have become unappetizing to you, it won't be hard to find someone who thinks they are appetizing :)
0.15% of world population was mobilized to fight in the Russo–Japanese war. That would correspond to ~12.5 million combatants today. Napoleon's invasion of Russia saw more casualties from combat, starvation, and disease, but it involved a smaller fraction of world population.
I assume you're going off the 1.365M + 1.2M combatant strength listed in the Wikipedia article?
Those are figures for the total size of those national armies at the time. It'd be like saying the Iran war involved 3M people because the U.S. has about 2.1M in uniform and Iran has just under 1M counting reservists. Meanwhile there've been precisely zero boots on the ground in Iran, and the total number of military personnel directly affected is on the order of tens of thousands.
The text of the article has the Russian far east strength at about 95,000 at the start of the war, with another 410,000 trained in over the course of the war. The best proxy for Japanese (and Russian) combat strength might be the Battle of Mukden [1], which had about 250K Japanese and 292K Russian troops. These numbers are smaller by a factor of about 5x.
The present-day Russo-Ukrainian war is significantly larger. Estimated Russian deaths are 500K+, higher than the total number of Russian soldiers involved in the Russo-Japanese war.
If you continue reading the article, it mentions that Russia had mobilized almost a million soldiers in the Far East by the end of the war, and that mobilization largely happened after the Battle of Mukden. Without the naval defeat at the Battle of Tsushima, Russia would have had the upper hand at that point, and the war would likely have reached a different conclusion.
Industrial armies were massive. By the standards of that era, current US military strength exceeds 60 million. But they mostly relied on reserves, which were slow to mobilize. Japan's quick decisive victories ended the Russo–Japanese war before it had a chance to escalate further, potentially reaching the scale of the Eastern Front in WW1. But even then, the Battle of Mukden was one of the largest land battles in history until that point
To some extent yes, but the Soviet Union and Warsaw Pact was never really as threatening as western propaganda made it seem. In basically all metrics that matter - population, GDP, military spending, technological advancement, etc. - the eastern bloc was a distant second to NATO. That makes its collapse far less disruptive to the world order than when the former hegemon falls.
But since the industrial revolution 80 years is something.
I hope it's a trend: but living in Europe right now, I do feel like our strongest ally are giving our enemies reason doubt the deterrence we've collectively built over the past 77 years.
We had to deploy armed troops to Greenland to deter an ally from invasion.
The deterrence to war we've spilled blood building for 77 years.
Economics is part of why we haven't had wars, collective deterrence probably had something to do with it too. Without NATO who is to say how many smaller nations Russia/USSR would have invaded for the fun of it.
The bit about "but the UI" sounds like a developer thinking "UI is a solved problem" in the same way MBAs are told "coding is a solved problem".
Product people do seem to think it worth exploring "personalized software for everyone" like literally each person gets their own custom UI. This does sound like a support mess but it's not obviously wrong when you think about the Microsoft Word alternative.
To me software engineering was often about: how do we structure the project so that the crappy code the other students/co-workers write don't break everything?
Not because everyone writes bad code. They do, at-least the do first time you read their code. You only think someones code is decent when you spent 3 hours trying to refactor their PR, and realized that the compromises they made were perhaps reasonable.
(This is an important lesson to learn)
Whether code written by others is poor or not is also besides the point.
You cannot keep everything in a large project in context (biological or not).
Software engineering (not computer science) is about: managing complexity. Structure your project in layers or abstractions or packages or silos or verticals or objects or whatever.
But break complexity into bits, so that everything isn't in mind all the time.
Nothing new about that. And poor engineering can be papered over with hard work. It's just easier to reach the point where poor engineering really bites ;)
And building the correct structure for your problem/program is still a huge part of the job. If you completely delegate structure, you still get a clusterfuck.
I have found working with LLM's is best when I provide as much structure and constraints as possible, and reduce the degrees of freedom that the LLM can exercise, so that it is forced to fit its logic inside the structural boxes I have laid out.
If you just delegate everything to the LLM to get an absolute morass.
At an even more fundamental I tend to think about software as managing _risk_, where complexity is just one component. A large portion of my career has been about making difficult decisions around accepting particular sorts of software risk to reduce other types of risk, like my coworkers continuing to receive paychecks, for example.
Put even simpler: code is a liability, and understanding is an asset.
It's easy to add more code, but it also increases the risk, especially if you are the only one who understands how it works. As more people on the team understand it, the risk decreases. It becomes less likely that the code interacts in an unexpected way with other parts of the system, and it also becomes more likely that the existence of the code is justified because noone felt the need to replace it.
If you fire the team and replace it with another, you now have a lot of code and zero understanding. That understanding first has to be mined before you can close the asset/liability gap.
In the age of LLMs, it becomes easy to produce 10x as much code as before, but I don't think you can put the same multiplier on how fast you can increase the understanding. It may even be <1 if you are not being mindful about your LLM use.
I think a lot of people will tell you that now it's much easier because they can just ask their LLM how it works, but in practice I don't think people are able to absorb enough from these purely need-based interactions to arrive at understanding that translates into sustained long-term increases in productivity for large projects.
The thing I keep seeing is greenfield AI projects built by ill-conceived, self-styled software factories. They grow incredibly quickly, and then reality sets in and the pace slows. Demonstrating this is difficult. There are real productivity increases to be had here no doubt, but the long tail is still expensive.
Exactly. And LLMs will only accelerate your rate of understanding so far by helping you find and organize information, at the end of the day you are still limited by your own mental bandwidth.
The difference is, the total cost for a human to write/modify code files is much higher than for an LLM. A lot of time has been spent designing program languages so that human time is more optimized. LLMS dgaf if the code is structured cleanly or is a mess.
So even if you end up with a mess of a codebase, as long as you define your test cases and they all pass, what is in the middle doesn't really matter.
reply