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.
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.