When starting a new team and more than 50% wants to use Python, it is selected as the production language. The best programmers however wants to use something else, but "to be able to create a great team" Python is selected.<p>What would you do?<p>* You have a couple of very experienced programmers on board that hates Python but uses languages that are not that common.
Write Python and be happy. Writing in uncommon languages maybe looks nice in paper performance terms but it has higher costs of maintenance and hiring over the long term. Assume the 'great programmer' falls under a bus or gets a better offer at another company, how hard will it be to deal with all that legacy code?
Great programmers can be great in (almost) any language. Hating a language is generally a sign of inexperience. There are great programmers who hate languages, but the two don’t usually go together.<p>The choice of language can be important, but it should be done based on sound technical reasoning, not popularity or emotion. I would skip past both sides of this debate and try to make the decision on a technical basis instead.
Who's in charge of the project? In a corporate environment I'd say that this is a project management failure and bodes ill for the project; if you're a startup team then this is also a problem you need to address now or you risk the team splintering.<p>Seems to me that the language choice should be at least partially driven by your problem space and relevant libraries and tools. The people involved can put together their reasons for their preferences, but someone's going to need to be the decision maker.
I know this sounds judgmental, but I would challenge your perception of these "best" programmers. In my experience, truly great programmers only have preferences when it comes to languages.<p>If I have someone voicing very strong preferences or go as far as claiming to "hate" a language as inoffensive as Python, I mentally add them to the "probably middle of the road programmers, needs ego management".
Why is the team being formed? There must be specific needs, goals and timelines. That seems like it would be the primary driver. It sounds like you already have several choices all up to the task. You might burn several days trying to wedge the team into a decision. It could even get heated. So, unless you're looking to eval the temperament of your team members I'd just pick a pony and saddle up. If the tech lead is brilliant and only likes the chocolate doughnuts then you can give some extra deference but don't let a lead list the ship.<p>I would suggest looking up and down your entire stack with a good eye, too. Evaluate it from the outside. Even if it doesn't exist yet. Are there other operations to integrate with? Will selecting one or another affect its maintainability? What happens when turnover strikes?<p>If they're good enough they'll build with any tool. Pick one then see if your team can change your mind within two hours. Use the other five to get busy.
Out of curiosity...what are the other langs and what is the business you're in? Python is a great language for a lot of uses, but obviously not everything.
I struggle with this problem with my small team of programmers.<p>The biggest problem is the unstated motivations at play around ego and ambition. People want to be influential. They want to use the latest technology. They want to be the ones to make important decisions around architecture and style. They have their personalities deeply bound up in the technologies they use, so technical merits and technical problems quickly translate into personal emotions around things - insecurity, defensiveness, secretive behavior, - all of which is unstated and manifests in passive ways.<p>Our problem is sort of the opposite though. We chose Python as the "backbone" language - the glue that holds other things together. However the team is small and inexperienced and mostly only know Python. So they persist in using Python for every other task as well. Unless I make it a hard requirement not to, they will pick it up and use it for performance sensitive things, things that have significant structural complexity where Python's type system weaknesses really hamper it.<p>So we have problems where we have a design meeting and we say "We need an X. X should do Y and Z". We all agree. Then I come back a few days later and team member A announces he implemented X "in his spare time". So we now have an X. Written in Python, which is not the optimal language I would have chosen. Only team member A understands it, so everybody else is a step behind and didn't have any input. Team member A made all architectural decisions for it. X is well written, seems to work and now that we have it, it is hard to argue time is well invested in writing it in a more optimal language.<p>What do I do? "Have a chat" with team member A (ie: discipline them?)? Praise them for taking on an important task? Do we rewrite this component? If I do all these things am I being heavy handed and causing untold harm to the team morale? But what are the consequences if I don't intervene - can we actually end up with good cohesive design if every team member is just steering the whole team in whatever random direction they happen to want?
My strategy, write/prototype everything in Python until you have a performance problem. Then choose Cython, Golang, or Kotlin, etc for systems or modules that require it.
It depends on many factors. Choosing suitable tools for a project requires careful consideration.<p>Python is a popular language, but not the only one. So many languages exist for a reason. Of course you can always find justifications to reject a language, e.g. Python lacks compile time checking, C++ is outrageously difficult, Java code is full of boilerplates, Perl is a write-only language, PHP is just bad, etc. But all these languages are widely used for some reasons. Not only the popularity, you may also need to consider maintainability, performance, portability, libraries, licenses, etc.
Use what the team you have now is comfortable with. You need to balance the need to get your product completed in a limited amount of time vs. the need to spend time on recruiting people and training them (or forcing them) to use something that they wouldn’t be comfortable with and may cause serious bugs and delays in shipping your solution.<p>This is the reality in most big (and older) companies, where choice of language, OS, etc., are dictated by who’s available, what they know and “how it’s always been done”, rather than by other considerations that only the technically minded may worry a lot more about.<p>You didn’t state which uncommon language the experienced programmers like. Since Python libraries are usually written in other languages (like C, or some even in Rust in recent times), you could probably consider giving them the task of writing the low level algorithmic/library work if this is suitable for the product design and if these experienced programmers like a language that can be easily used to write Python libraries. The team members who know Python can work on all the high level stuff.<p>I don’t think there’s an ideal solution for your situation, more so when we don’t have a lot of details here.
The team don't choose the language, the problem does. I don't care if 50% or 100% want to use a language, you must use what is the best tool to solve the problem you have. And if you have to choose between several languages then you create a table to assess every language (knowledge of the language and easy to hire people in the future can be two points of that table), the language with better score is used.
I conceded and let the team use the language that they are most comfortable with. This became one of my greatest regrets. First of all, i was not working full time so i thought it wouldn't be fair to make them learn a new environment while i only contributed slightly.<p>The problem came when I ended up being the main developer with experience in scaling and making our product main stream. It's true that you can learn any language if you understand the problem you are solving, but it would have been much faster if I was in my familiar environment.<p>I was burntout because I had to spend too much time googling simple errors or basic things i knew well in other languages.<p>Don't choose a cool language, choose the one the lead/main developer is most comfortable with.
A rarely-used language (let's say, anything not in the top ten) makes it harder for everyone, but especially the less experienced, to find solutions, answers, knowledge, or a community around it. And it's also harder (after everybody quits who wanted to use Python and needs to be replaced) to find & hire someone who knows it and can work with it.<p>If I'm the experienced programer, I would learn Python. Any excuse to learn something new and keep my mind from turning to concrete as I age. Since I'm so experienced, learning it should be easy for me. And, I get to spend time teaching myself, instead of teaching noobs how to use my pet language.
Majority rule is a bad way to make good business decisions. The best tool for the job should be evaluated with consideration from all team members. Also, good developers should be able to learn and use any programming language.
I was in that situation once. But I was the experienced programmer and the rest of the team wanted to use C. For a web application and gui code. They overrode me but given the number of segfaults and memory leaks the application suffered I was right and should have stood my ground. However given the description of your situation I doubt you'll lose that much productivity by choosing Python. Imho, you are at least twice as productive in Python than in C. But no language exist in which you are twice as productive compared to Python.
There's a really good book, and this is part of the premise. Python is a great language, but I can't see it being viable for large projects. I do want to note that it doesn't say Python was part of problem, but in retrospect it seemed like the project was ahead of its time and the technology wasn't there yet.<p><a href="https://www.amazon.com/Dreaming-Code-Programmers-Transcendent-Software/dp/1400082471" rel="nofollow">https://www.amazon.com/Dreaming-Code-Programmers-Transcenden...</a>
Really depends on the problem. If it's run-of-the-mill performance-non-critical then Python is fine. But if you need distributed fail-safe work then Erlang/Elixir is the way to go.
Generally for backend, Go is pretty good. Rust is a bit immature so would only use it in specialist cases. C and C++ is only used to call other libraries.<p>I found Julia to be good for general purpose workloads as well, e.g. I have a Go server that queries MongoDB and I process the return resulst in Julia, which is a great gluing language!
Just had a similar thing happen with me. Python wasn't the best language for the job and I had already written a prototype. Trouble was that at least one member of the team really didn't want to learn a new language so we said fuck it and decided to do it in Python. While I wish we had chosen the best tool I can see that a team member being viscerally opposed is a bad enough con to override all the pros of the language selection. It sucks but it's reality.
Don't waste productive time bikeshedding. There are only a few languages that are so badly suited to the problem space that they're worth staking out your ground and going for the hard pass. Most of the time, you can productive in most languages, even if the one in use isn't the "best" choice. Be cool and open-minded about it, and you might learn something.
What's the language that the bet programmers want to use? How different is it from Python? Why are they so adamant about using that over Python?<p>Python is a pretty good language. Unless there's a good reason not to do it, I'd go with majority. You gotta trust your team. It's not like the majority is voting to use CoffeeScript.
My thoughts on this: <a href="https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1" rel="nofollow">https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13...</a>
These days it's as much about the choice of framework as it is about the language.<p>Also, for web frontend, python is obviously not ideal, but in that instance you're basically stuck with JavaScript for now.
Depends on the project: if it's fairly big, then choose the most popular static-typed ecosystem. If it's small, then it doesn't matter anyway.
I personally dislike python, but honestly if you're working as a team you work with what the team uses. If they really are such great programmers they should have no problem picking it up.<p>But if they have legitimate reasons for wanting to use something other than python, other than they hate it, give them the chance to explain themselves to the team and see if your team is willing to learn something new. It's always valuable having a team that can work in more than one language.<p>If none of them can come up with a better reason though. I see no reason not to go with your team's decision.
"Hate" is not a good enough reason to break a team. Is a good reason to re-affirm a choice ("I hate JS. LOL is so stupid! "everyone agree"). Maybe to break a 50/50 choice.<p>Instead of hate, think in Love. Cliches are cliches because are right!<p>WHY YOUR "BEST" PROGRAMMERS LOVE TO USE X?<p>If you can't make the team fall in love with that, then that is a strong signal is not that good of a idea... or are not that great programmers after all.