4 ms·

Java shops are certainly where I've witnessed the most disdain for Python. IME the strongest feelings tend to come from people who didn't actually have any sign

Java shops are certainly where I've witnessed the most disdain for Python. IME the strongest feelings tend to come from people who didn't actually have any significant experience with Python, and perhaps don't even have much practical experience with any language that isn't Java. So they tended to consider it to be objectively inferior purely because it's interpreted and dynamically typed. At a previous job I did manage to put a chip in that when I demonstrated replacing one of our Java services with a Python implementation. It was a fraction of the code, and achieved much better latency and throughput. Obviously not every Python program is going to do that. But my point isn't that Python is better, it's that these kinds of things are never so cut-and-dried. Many non-trivial Python programs are just thin shells around a large core of very well-optimized and battle-tested C/C++/Rust code. And Java, for its part, can also accumulate a lot of dynamic language-style performance losses to pointer chasing and run-time type lookups (and GC churn) if you're not careful about how you use generics. As always, the devil's in the details. It's also less able to pull the "actually I'm a C++" trick because using a compacting garbage collector makes it difficult to interop with native code without paying a hefty marshaling tax.

deepsun 1y ago
I have way more experience with Python than Java. In at least 4 companies (including Google that I wouldn't call a javashop) we used mainly Python. Still I believe Java is a better application language. Python is a better scripting language (replacement for Bash). Small apps tend to be easier on Python, but large apps are way easier on Java, both for syntax (types) and ecosystem (libs).
- mey 1y ago
  That is general take as well. A lot of small apps/simulators are in python. Ops scripts tend to be python. Java for the core/data. Refactoring/tooling is easier in Java when you are dealing with a 100k codebase imo. Typescript always. Seen plenty of coding horrors in both ecosystems...
  - zeroc8 1y ago
    Algorithms are a lot easier to understand when they are written in Python. I'm actually right now documenting medium size Java codebase by writing pseudocode, which looks like Python. Just by doing that, I've already discovered multiple bugs, which I didn't catch by looking at the Java code.
    - bunderbunder 1y ago
      That might be the big thing that I think gets glossed over in a lot of these discussions. I agree that I wouldn't want to maintain 100kloc of Python. But, I don't really view that as a realistic hypothetical for a business application. Idiomatic Python tends to require a fraction as much code as idiomatic Java to accomplish the same task. The only time it even gets close is when you have code written by people who go out of their way to make things look like old-school enterprisey Java. So it ends up accumulating a bunch of stuff like class IWantToBeABean: def init(self, arg1: int, arg2: str, arg4: str) -> None: self._field1: int = arg1 self._field2: str = arg2 self._field3: str = arg3 def get_field1(self) -> int: return self._field1 def set_field1(self, value: int) -> None: self._field1 = value def get_field2(self) -> str: return self._field2 def set_field2(self, value: str) -> None: self._field2 = value def get_field3(self) -> str: return self._field3 def set_field3(self, value: str) -> None: self._field3 = value when it could have just been: @dataclass class IDontWantToBeABean: field1: int field2: str field3: str The worse case for Python is when you get people doing the oldschool Python thing of acting like dynamic and duck typing means it's OK to be a type anarchist. Scikit-learn's a good one to put on blast here, with the way that the type and structure of various functions' return values, or even the type and structure of data they can handle, can vary quite a bit depending on the function's arguments. And often in ways that are not clearly documented. Sometimes the rules even change without fanfare on minor version upgrades. The reason why large Python codebases are particularly scary isn't necessarily the size itself. It's that for a codebase to even get that large in the first place it's very likely to have been around so long that the probability of it having had at least one major contributor who likes to do cute tricks like this is close to 1. And I'd take overly verbose like the Java example above over that kind of thing any day.
- bunderbunder 1y ago
  Mostly agreed, though I would add that I'm generally happier with Python as a default for reasonably sized services that don't have a lot of (non-numpy-friendly) compute load and therefore don't have a pressing need for multithreading. Which is a lot of what happens now that we're all trapped in the cloud. Like you say, small apps tend to be easier in Python.
ecshafer 1y ago
> Java, for its part, can also accumulate a lot of dynamic language-style performance losses to pointer chasing and run-time type lookups (and GC churn) if you're not careful about how you use generics. The worst thing about Java is the average quality of Java programmer.The same could probably be said about Python. However I think that there are fewer Python programmers trying to write AbstractFactoryFactory than in Java. Java has a terrible culture of overly verbose, deep inheritance trees that make debugging and development worse, with worse performance.
- xcrunner529 1y ago
  I certainly think so but wasn’t sure if it was just my unfamiliarity or lack of advanced programming knowledge but I attempted what seemed like a very simple patch to a Java project (guacamole) and it was insane how I ended up having to add the new function to like a base and abstract class and interface etc. it was crazy. All the same boilerplate too.

deepsun 1y ago

I have way more experience with Python than Java. In at least 4 companies (including Google that I wouldn't call a javashop) we used mainly Python. Still I believe Java is a better application language. Python is a better scripting language (replacement for Bash). Small apps tend to be easier on Python, but large apps are way easier on Java, both for syntax (types) and ecosystem (libs).

mey 1y ago
That is general take as well. A lot of small apps/simulators are in python. Ops scripts tend to be python. Java for the core/data. Refactoring/tooling is easier in Java when you are dealing with a 100k codebase imo. Typescript always. Seen plenty of coding horrors in both ecosystems...
- zeroc8 1y ago
  Algorithms are a lot easier to understand when they are written in Python. I'm actually right now documenting medium size Java codebase by writing pseudocode, which looks like Python. Just by doing that, I've already discovered multiple bugs, which I didn't catch by looking at the Java code.
  - bunderbunder 1y ago
    That might be the big thing that I think gets glossed over in a lot of these discussions. I agree that I wouldn't want to maintain 100kloc of Python. But, I don't really view that as a realistic hypothetical for a business application. Idiomatic Python tends to require a fraction as much code as idiomatic Java to accomplish the same task. The only time it even gets close is when you have code written by people who go out of their way to make things look like old-school enterprisey Java. So it ends up accumulating a bunch of stuff like class IWantToBeABean: def init(self, arg1: int, arg2: str, arg4: str) -> None: self._field1: int = arg1 self._field2: str = arg2 self._field3: str = arg3 def get_field1(self) -> int: return self._field1 def set_field1(self, value: int) -> None: self._field1 = value def get_field2(self) -> str: return self._field2 def set_field2(self, value: str) -> None: self._field2 = value def get_field3(self) -> str: return self._field3 def set_field3(self, value: str) -> None: self._field3 = value when it could have just been: @dataclass class IDontWantToBeABean: field1: int field2: str field3: str The worse case for Python is when you get people doing the oldschool Python thing of acting like dynamic and duck typing means it's OK to be a type anarchist. Scikit-learn's a good one to put on blast here, with the way that the type and structure of various functions' return values, or even the type and structure of data they can handle, can vary quite a bit depending on the function's arguments. And often in ways that are not clearly documented. Sometimes the rules even change without fanfare on minor version upgrades. The reason why large Python codebases are particularly scary isn't necessarily the size itself. It's that for a codebase to even get that large in the first place it's very likely to have been around so long that the probability of it having had at least one major contributor who likes to do cute tricks like this is close to 1. And I'd take overly verbose like the Java example above over that kind of thing any day.
bunderbunder 1y ago
Mostly agreed, though I would add that I'm generally happier with Python as a default for reasonably sized services that don't have a lot of (non-numpy-friendly) compute load and therefore don't have a pressing need for multithreading. Which is a lot of what happens now that we're all trapped in the cloud. Like you say, small apps tend to be easier in Python.

ecshafer 1y ago

> Java, for its part, can also accumulate a lot of dynamic language-style performance losses to pointer chasing and run-time type lookups (and GC churn) if you're not careful about how you use generics. The worst thing about Java is the average quality of Java programmer.The same could probably be said about Python. However I think that there are fewer Python programmers trying to write AbstractFactoryFactory than in Java. Java has a terrible culture of overly verbose, deep inheritance trees that make debugging and development worse, with worse performance.

xcrunner529 1y ago
I certainly think so but wasn’t sure if it was just my unfamiliarity or lack of advanced programming knowledge but I attempted what seemed like a very simple patch to a Java project (guacamole) and it was insane how I ended up having to add the new function to like a base and abstract class and interface etc. it was crazy. All the same boilerplate too.