Python is sufficiently inoffensive that you should just suck it up. It’s well tooled, and generally pretty well thought out.

I agree - Python is great and rather neutral (as soon as snake_case_naming stops causing you nausea and as soon as you stop worrying about types and the fact you can't make a class member truly private) yet it has one thing I really hate - the module/package system. Coming from C# I could never "grok" it in Python (might anybody have a link to a great intro in this subject optimized for a C# mind - I'd be more than grateful) and being unable to split a single namespace into a number of files is outrageous (especially for an ADHD person who can't stand long code files and importing every this and that manually everywhere).

> being unable to split a single namespace into a number of files is outrageous

The usual solution to that is an __init__.py that pulls in the names from its subpackages. I'm sure you'll be able to find an example of that in basically any large open-source Python project.

I have tried this once and it didn't work although pylint has passed with no errors (surely I admit that's because of a mistake I have made but I haven't managed to find and fix it so I've ended up just putting all the code in one file). Anyway it's not what I need as far as I understand (I have described what I need in a comment below, the answer to mixmastamyk).

Import several files into one, then import it elsewhere.

E.g. I have file aaa.py, bbb.py and ccc.py (placed in the same directory but I don't mind adding a line of code to declare their relationship explicitly). What I want is not only to be able to import them all at once in ddd.py but to access everything from aaa and bbb in ccc, everything from bbb and ccc in aaa and everything from aaa and ccc in bbb [almost] seamlessly.

You could create a __init__.py file that imports everything from each of those files:

    from .aaa import *
    from .bbb import *
    from .ccc import *

Then in each of the other files (aaa.py, etc) put:

    from . import *

Thats a circular import and thus not guaranteed to work.

What is the actual problem you're trying to solve?

FFS, why isn’t this the first fact or question?

I don't know what's worse, the vagueness of the question or the fact that people want to answer it without any additional details.

Because the question isn't "Is python the right choice in this situation?", the question is "Should I override group consensus to make a subset of the team happy?"

The group made a decision. Someone (senior, but not leadership) disagrees. What do you do?

Well, I guess I would still want to know why the "senior" disagrees? Is it for a good reason? Is it a QOL thing for them personally?

I still don't know how you decide the question of "do I override the consensus" without addressing the technical issues at hand.

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?

Many over-arching issues come from using a language that isn't designed for your use case. For example, writing any programs that require speed to be your goal are not programs I'd recommend Python for.

Other languages also have advantages in certain areas, e.g. Node.JS lets you reuse the same code on the server-side and client-side, something which is great for those wanting to right games that require the server to simulate them and the client to run them.

Even if the language is rarer, say C or C++, there are still many circumstances where it is better to use those than it is to use Python.

I do not foresee any language to be able to be easily usable in every use case, the generality itself would be a drawback for specific user case. There is a reason there are currently dozens of popular programming languages out there.

C isn't my idea of a 'rare' language. you don't need to explain to me why there might be competing language preferences. I didn't have the impression that the other programmers on the team wanted to use Python for lack of knowing any other programming languages.

I think if you need to copy paste code from server to client you failed the separation of concerns. When is this useful, ever?

> something which is great for those wanting to right games that require the server to simulate them and the client to run them.

Also it's great for SSR.

Don't have to worry about if the join function has different signature per language.

Isomorphic JavaScript doesn't mean you spaghettify your front-end into your backend, that's an absurd thing to assume and assert is true. Yes, your front-end and backend can share npm modules, functions, and templates. This means your HTTP library is fetch or axios (basically, same API) rather than 2 different APIs). You don't have to write a jinga2 copy of your react modules for prerendering. You don't have to write your custom validation rule in 2 different languages. This is useful pretty often.

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.

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.

Does employee happiness not factor in?

e.g. I'm capable in many languages: Python, Java, C, C++, JavaScript, Lua, Go, + more. However I only enjoy writing in Lua or C, working in other languages are a chore: often it must be done, but I'd rather avoid it if I can. If I'm told to write in Python all day, I'll find myself looking for a new job rather quickly...

>Does employee happiness not factor in?

Only when that happiness leads to productivity. It's called "work," after all, you weren't hired to have fun all day.

Programmers that are only doing the job because these days it pays, not because they love what they do, are shit programmers.

And employers who would rather their programmers work for love than money are shit employers.

> Hating a language is generally a sign of inexperience.

It can also be a sign of understanding tool-domain fitness, with the domain not even revealed to us yet by the post author.

Not wanting to use a language because it’s not good for tha problem at hand is different from hate.

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.

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.

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

OP likely sucked into believing the vociferous opinions of a Dunning-Kruger savant.

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.

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?

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.

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.

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.

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.

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?

If there are performance targets that the Python implementations don't reach, perhaps make those targets explicit early during design. (I suppose it's possible that this will just lead to less readable Python implementations, in pursuit of speed, or people start writing larger and larger chunks in Cython... Hard to say from the outside.)

It's harder to make people appreciate enforced type discipline until they've written a large enough system in type-annotation-free Python that it starts really hurting. I attained that painful enlightenment along with the rest of my all-Python team 12 years ago at a now-defunct startup. I still like Python for small programs, especially many kinds of exploratory/prototype work, but nowadays I'm using Scala for most things that go to production.

Have you had bugs show up due to type mistakes? Changes that take longer than they should, since the IDE can't automatically identify the type-consequences of a change? If so, those concrete examples might be motivating enough to gradually introduce type annotations in your existing Python code, which might be a stepping stone to using a stricter-typed language.

Thanks for the thoughts.

We're at a very greenfield stage of development, so part of the problem is that we are yet to feel much technical debt pain from everything that is going on. And a lot of it is invisible. Eg: in the example above, I needed to put aside time to review the code that was created for component X. Because it was written in Python, this review was quite a lot harder than if it was well written code in a more structured language. Most arguments to most functions have no obvious data type documented or constraints around nullability set etc., so figuring out what everything is involves a tremendous amount of reading code and navigating up and down the code hierarchy. Multiply this by every team member who has to understand and ultimately maintain this code and you have a tremendous cost. So in a real way it is definitely costing us already, but its very hard to measure. But as you say, my real worry is about the longer term. It's easy to figure out what a data type is when a function and its caller are right next to each other in the same file. But as things grow and they get split apart, maybe even into different modules or projects altogether it gets massively harder to do. We could go all in on type annotations but I see it as a bandaid compared to the team actually investing in using a core structured language where the typing is a first class citizen.

MyPy and tests.

Do E2E testing, test the API. If you later find out that the implementation is lacking, yoi can swap it out with confidence, if you have 100% coverage of your API spec.

Also, as a sort of management recommendation, you need to set the bounds and find the people that can work with you, not the other way around. (Yes, of course, you work with what you have, but this doesn't mean anything implemented in spare time must become the next cornerstone of the company/product.)

And you must spend a lot of time growing your teammates. Because with a great team a rewrite/refactor will lead to better results, with the same quality team, even in a "better" language you will only get similar low quality results.

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.

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.

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.

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.

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.

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.

I was burntout because I had to spend too much time googling simple errors or basic things i knew well in other languages.

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.

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.

https://www.amazon.com/Dreaming-Code-Programmers-Transcenden...

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.

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!

I wasn't aware choice of programming language is that important.

You have a "great programmer" on the team that keeps on creating stuff that the others can't review or contribute to unless something more common is enforced.

This guy sounds like the stereotypical "rockstar" developer. These types create endless drama and ruin team dynamics by insisting that everything be done their way due to their supposed brilliance. The situation you're in now is exhibit A. Expect more of the same at every turn from here on out.

Also, food for thought: if nobody can review his code, what evidence of his "greatness" exists other than his saying so?

Getting shit done and pleasing clients can be seen as "greatness."

I write a shitload of PHP/jquery - and no one reviews my code. If it's done fast and works as expected my bosses don't care... and they'll listen to me over the front-end dev who wants to use React/Ruby.

Now I don't 'hate' any language and will try new things, but my point is that the definition of greatness can be completely different between companies, especially when the company isn't a tech company.

You're right, but the fact that this guy is hung up on the language at the expense of team productivity makes me suspect he's not the "getting shit done" type.

I'm so old I remember when willingness and ability to learn and use new languages was considered a basic trait of a competent professional programmer.

It's not just the ability to learn and use.

Language learning does not stop when one becomes proficient in it. You keep learning new usage patterns, all the corner cases and nasty surprised and start to remember libraries and their features. You become gradually better and faster in the language you use. After decade or so you can become really good.

For a really experienced programmer there is a drop in productivity even if they are able to learn and use language better than more junior programmers.

Haha yes good luck with that now with "full stack node" programmers etc. In their defense, every framework they use redefines their language to the extent it is a new language :)

> You have a "great programmer" on the team that keeps on creating stuff that the others can't review or contribute to unless something more common is enforced.

What good are they, then? If the decision to use Python has already been made and acted on then a mediocre Python programmer who can actually commit would be more useful that a genius whose code is useless to the project.

Yeah, I feel like the "great programmer" is the real problem, not Python.

It completely depends on what you are building. Are you building a game, telecom service, web application, firmware for a medical device, or a rocket ship. Software is present in almost every single industry and what you are building should likely influence your choice of programming language. It's probably true that you could get the job done in any language, but you should always be thinking about the constraints you have when writing something new.

- What is my budget - How much time do we have to deliver the project - Is there an ecosystem I have to integrate with - Do I have strict performance/safety guarantees - Are there libraries that I can delegate to

Python is a fantastic language, but I wouldn't use it for everything. However, I will agree that just saying "I don't like it" is not a good enough justification for dismissing it. That just seems unprofessional IMO.

Maybe you have never had to maintain a program written in Javascript or Python ;)

In my experience, if you have a language with a compilation-like step, e.g., assembly language, then you automatically have a massive advantage over a language without, e.g., Javascript or Python.

The advantage over languages such as Javascript only grows wider if you opt for a language with a comparatively sophisticated and thorough static type system, e.g., C89.

Now, suppose the Javascript code has 100% test coverage, and the C89 code has 0%. But so what? I was assuming that already. In my experience, the C89 code is still easier to work with.

Not all languages are created equal.

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?

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: https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13...

What are the uncommon languages? And what kind of product are you building?

These days it's as much about the choice of framework as it is about the language.

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.

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.

If none of them can come up with a better reason though. I see no reason not to go with your team's decision.

Sometimes the situation might be: 1. Choose what the less gifted team members are comfortable with and everyone might produce. 2. Let the gifted ones rule, they might do great things, but everyone else are not producing.

You might say that the gifted ones belong in another team, but as we know reality bites...

Ya that's one of those hard things to balance.

A great programmer who lives for obscure languages is someone who is strong in CS and weak in engineering.

They love playing with puzzles.

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

Instead of hate, think in Love. Cliches are cliches because are right!

WHY YOUR "BEST" PROGRAMMERS LOVE TO USE X?

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.