Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Should orgs limit the number of languages/frameworks?

news.ycombinator.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Ask HN: Should orgs limit the number of languages/frameworks?

#22

Post by chuckadams »

Yes for production pieces that Must Work Always, but your devs need freedom to experiment when designing new tools, so your list of approved technologies had better be flexible, or you’ll have a different kind of maintenance problem down the line. As well as problems retaining the talent you already have.

Re: Ask HN: Should orgs limit the number of languages/frameworks?

#23

Post by rramadass »

Absolutely; the issue has to do with the "Cognitive Load" imposed on the programmer. Standardizing on a small set of languages/frameworks(ideally one) also has the advantage that developers can better communicate/interact with each other using a common language thus enabling better overall productivity.

The Cognitive Load Theory in Software Development - https://thevaluable.dev/cognitive-load-theory-software-devel...

Cognitive Loads in Programming - https://rpeszek.github.io/posts/2022-08-30-code-cognitiveloa...

Cognitive load - https://en.wikipedia.org/wiki/Cognitive_load

Re: Ask HN: Should orgs limit the number of languages/frameworks?

#24

Post by oftenwrong »

I agree with the other comments that are basically saying to be conservative about adding to your toolbox. Additionally, I recommend using technologies with existing heavy investment from the industry. For example, anything on the top of this list is a safe choice of language in general: https://survey.stackoverflow.co/2023/#most-popular-technolog... . This reduces risks from having to assume maintenance burden, hiring difficulties, finding support, integration with other technology, and more. Adopting some tool that is later abandoned is a frequent source of pain for small companies. Of course, there may be good reasons to stray from this guideline in some cases.

Re: Ask HN: Should orgs limit the number of languages/frameworks?

#27

Post by purple-leafy »

I’d probably live on an 80/20 rule just to harbour innovation. I really believe you can only innovate and create something novel by doing different to everyone else.

So all core tech uses a consistent language or framework eg

- Frontend: Typescript/React/Next

- Backend: C#/.NET or Python, Go

But people can go wild with things like developer tooling or non-core products and experiment. And I mean experiment:

- Try new frameworks, new languages, new paradigms, new targets, new platforms.

Let your devs build and experiment with chrome extensions, flutter apps, Swift games, Kotlin VPNs, Lisp DSLs, python TUIs, ascii games, anything just something different from normal work

If you just do bread and butter dev work 100% of the time and stay consistent with that, you will become a bread and butter shop, and you will stay a bread and butter dev. Period.

Sometimes life needs a bit of spice

At work we use Typescript, React, Next, backends are Node, Python, C# as the defaults.

But I want to build browser extensions for them in React to extend their online SQL editors. And I want to build TUIs with Go to monitor containers and orchestrate project starts. Maybe I’ll write a data processing command line tool in Lisp. I reckon go wild with developer tooling.

Re: Ask HN: Should orgs limit the number of languages/frameworks?

#28

Post by joshstrange »

Unless your company is large I think it makes perfect sense to limit the languages and frameworks you are allowed to use. For example, we use PHP and Vue at my company, if someone came in and said “we should use React/Angular” I’d seriously reconsider that hire and shut down that insanity. Mostly because there isn’t really anything we care about that can be significantly better in either of those frameworks. The same goes for PHP, we do have a few low-level C programs in our stack but by and large PHP is the main workhorse.

We have best practices, we have code examples, we have libraries all written in these languages/frameworks and it would take a _lot_ to consider leaving that behind for something new and shiny. Most importantly we have experience and expertise in these languages/frameworks, the improvement would have to be massive to consider retraining people.

Often there are hyper-specific examples where X language can do Y thing better than PHP but at the end of the day I’ll take a slower process in PHP over a different language because anyone on my teams can work in PHP whereas it’s going to be a small majority (or 1 person) who can work in the different language.

Put another way I’ll take a homogenous less than perfect (perfect = fastest/best language for each job) codebase over an unmaintainable Frankenstein codebase that falls apart when the person who wrote a certain component (and is the only one that understands it) leaves the company.

It’s the same reason I hate “clever” code. I’ll take 10 lines of easy to read/grok/change code over a one-liner every day of the week.

Post reply on HN