What would you do?
* You have a couple of very experienced programmers on board that hates Python but uses languages that are not that common.
from .aaa import *
from .bbb import *
from .ccc import * from . import *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.
The group made a decision. Someone (senior, but not leadership) disagrees. What do you do?
I still don't know how you decide the question of "do I override the consensus" without addressing the technical issues at hand.
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.
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.
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.
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...
Only when that happiness leads to productivity. It's called "work," after all, you weren't hired to have fun all day.
It can also be a sign of understanding tool-domain fitness, with the domain not even revealed to us yet by the post author.
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.
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".
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.
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?
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.
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.
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.
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.
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 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.
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.
https://www.amazon.com/Dreaming-Code-Programmers-Transcenden...
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!
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.
Also, food for thought: if nobody can review his code, what evidence of his "greatness" exists other than his saying so?
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.
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.
- 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.
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.
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.
Also, for web frontend, python is obviously not ideal, but in that instance you're basically stuck with JavaScript for now.
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.
You might say that the gifted ones belong in another team, but as we know reality bites...
They love playing with puzzles.
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.