Comment by SideburnsOfDoom
3 months ago
> Do you also make everyone drive the same vehicle
Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc.
How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2 "general purpose" models, and then other ones suited to specialised tasks.
But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..
> 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?
1 reply →
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.
>> Yeah, .NET is a truck and React is a bicycle
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.
2 replies →
> 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.
> Yeah, .NET is a truck
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.
but they all delivers, just that they don't suit your taste doesn't mean it can't