
Ask HN: Forced to choose Python - vgy7ujm
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 &quot;to be able to create a great team&quot; 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.
======
psergeant
Python is sufficiently inoffensive that you should just suck it up. It’s well
tooled, and generally pretty well thought out.

~~~
qwerty456127
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).

~~~
yorwba
> 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.

~~~
qwerty456127
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).

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

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

~~~
chickenfries
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.

~~~
calciphus
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?

~~~
chickenfries
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.

------
anigbrowl
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?

~~~
codefined
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.

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

~~~
Can_Not
> 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.

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

~~~
daurnimator
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...

~~~
krapp
>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.

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

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

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

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

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

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

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

------
zmmmmm
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?

~~~
philipkglass
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.

~~~
zmmmmm
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.

~~~
pas
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.

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

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

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

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

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

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

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

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

------
kyo3
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...](https://www.amazon.com/Dreaming-Code-Programmers-Transcendent-
Software/dp/1400082471)

------
xiaodai
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!

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

~~~
vgy7ujm
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.

~~~
blacksqr
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.

~~~
nabla9
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.

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

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

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

------
nhumrich
My thoughts on this: [https://hackernoon.com/yes-python-is-slow-and-i-dont-
care-13...](https://hackernoon.com/yes-python-is-slow-and-i-dont-
care-13763980b5a1)

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

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

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

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

~~~
vgy7ujm
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...

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

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

They love playing with puzzles.

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

