Do you have a dumb question that you're kind of embarrassed to ask in the main thread? Is there something you're just not sure about?
This is your opportunity to ask questions. No question too simple or too silly.
Culture war topics are accepted, and proposals for a better intro post are appreciated.
Jump in the discussion.
No email address required.
Notes -
Yes.
At the trivial level, code with strong or moderate typing are far less likely to introduce a pretty wide variety of fairly annoying bugs. You can theoretically hire coders who aren't going to make that sort of mistake, but then you have to hire coders who don't make that class of mistake, and they have to put time and focus into it. Compile time can be the difference between iterating in seconds or minutes (or in one miserable case, tens of minutes). If you need portability (whether Windows to Linux, or x86 to ARM to Mac Silicon), some languages are much more frustrating than others.
At the less obvious, the availability of good and strong debuggers matters less for desktop (where the span is more Firefox Inspector Mode to Visual Studio) than embedded or microcontroller worlds (where the low end might be 'you get nothing, good day sir!'), but for applications requiring multithreading or complex performance or memory management, the higher end still matters. There's a tradeoff between succinctness and clarity of code, as evidenced by Java vs Kotlin vs Scala.
While you might consider them extremes of the "special requirements", some languages handle certain matters and frameworks better than others. MVVM makes a lot more sense in Java or C# than JavaScript, and may make sense for a common project type. Many things interfacing with hardware or certain databases may only have library support for a handful of languages, especially in industrial automation world -- at best you're going to end up writing a shim, at worst you may just be stuck. Some languages have really clever tricks justifying their use for certain specialty purposes (Matlab and matrix arithmetic) but are absolutely obnoxious otherwise. ((Some, like VC++, introduce weird user-environment-specific errors that can drastically increase your support costs and reduce user-friendliness, thank you msvr###.dll errors.)) For many internal-use tools, having something that you can build-and-leave-for-a-decade can push you away from languages with a history of breaking changes.
For smaller businesses, you go to war with the army you have, and I say that as someone who's written more than a fair share of internal-use C#, Java, and Python code.
I don't think they're the only part of business success: the road is paved with the skulls of LLCs that had great software but struggled on the business side, or just bad luck. And there's definitely a coding fandom that endlessly chases the Next Best Thing, either to (charitably) keep themselves sharp or (less charitably) keep their resume up to date, in preference to mastering one language well, or building lasting projects, or just getting tasks done. You can definitely end up bike-shedding. But it's a mistake to not consider it seriously and in depth.
More options
Context Copy link