> But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
No, they don't. You may believe that some frameworks or programming language are ideally suited for some particular tasks, but that is mainly dictated by your prior experience (or lack thereof). The truth of the matter is that a van can very well do the tasks you conceive for a car, trucks, bicycles, motorcycles, etc. If you go with a van, you avoid the problems of having to maintain car, trucks, bicycles, motorcycles, etc. This is called software engineering.
I think that question is more "how many different makes of van can your delivery company afford to maintain?"
Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"
The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.
The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.
Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that. Vehicle fleets are often aging out with these timelines.
So if we either stretch the fleet management analogy to 50 years, or software applications only lasted 3-5 years maybe it IS fair to say the both have either a lot (former) or very little (later) inconsistnency?
> Car models get maybe refreshed annually, bigger changes a couple of times a decade, if that.
.NET gets refreshed annually. The last bigger change was nearly a decade ago. So not all that different.
But I don't think that the analogy stretches, really. e.g. where I am all .NET apps are .NET 8 LTS or 9, and will be all be .NET 10 LTS by middle of 2026. You can upgrade an app to a new model year much more easily than a vehicle. The "software application, on a SDK major version" only lasts 1-2 years.
Yeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks.
I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it.
Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
I'm not a car guy but I most certainly a bicycle lover, so I will jump on you and say you often need more than one type of bicycle. Joan commutes to work? she wants a city ebike. Dan rides at the bike park? He wants a DH bike. Randy ride centuries on the weekend on his TDF road bike and Sally rides with her kids on a mountain bike.
So yeah, we can pick one bike type and force everyone to ride it, and the results will suck & everyone hate it. Your job can be to continually force everyone to follow this policy or you can stop and we'll get a lot of variation. THis is how it happens.
Well, they clearly all know how to ride bikes, so you offer to hire them to deliver using company bikes as a day job. And let them ride whatever they want on weekends.
The "force everyone to ride it" on the weekend part is where
I think the analogy has broken down irreparably. We're talking about cost of ownership of company equipment used during working hours for much more defined tasks. What flavour of bike you enjoy riding on weekends is not relevant.
Programming language are inherently flexible, especially those that aim to be "general purpose". Fine-grained distinction of road bike vs mountain bike apply more to the apps created than the coding tool.
> Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.
Yes, this.
> I'm saying use one tool for one task.
I saw an article ages ago arguing that the number of supported languages should scale with the size of the organisation. Which makes sense to me. The threshold was larger than we might expect though, it was something large like "one fully supported language per 500 devs". In other words, small-medium orgs will have a better time supporting 1 language only.
I know one person who was good at python, and who looked at the "classic" .NET hello world app with usings, namespace, class, main method etc containing the "Console.Writeline" payload, and noped out immediately, saying "if it's that verbose that it takes 10 lines to do what's 1 line in python, imagine how terrible real code must be!"
Personally I think they were wrong about that - it was optimised for larger programs, not trivial ones.
But also it helps me understand the ongoing push towards the point now where "hello world" is is 1 line in 1 .cs file only. And `dotnet tool exec` means you don't even need to install a utility to use it, etc.
In other words, .NET started life as a truck, with many features to support large codebases - usings, namespace, class, method etc. but is also general purpose enough that you can now also write a "bicycle" program.
