14 ms·

Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all. Java is like you say not the greatest

by wwn_se 6y ago

Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all. Java is like you say not the greatest at anything but it is also not the worst at anything. Its great for projects where the you don't know what you should optimize for or don't care. If java is to boring maybe kotlin is the way to go. I really like kotlin and in my personal experience the only downside is that the IDEs is not as good as the java counterparts yet.

BiteCode_dev 6y ago
I've seen plenty of even small Java projects becoming hard to manage as well. The design pattern hell is a thing. You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) Not to say Java is not a great language for big projects, it certainly is well equipped for that, especially because it has superb tooling available on the market. But I've done plenty of big projects in Python, some ended badly, some ended great. Not to mentions dropbox, youtube and instagram are testaments to Python can be used in large projects. So I don't think Python is unsuitable for big sized projects. You certainly do have to worry about different problems than in Java, especially for projects that started without type hints. In my experience though, you reach less architecture dead ends with Python because the language is so flexible that a bad decision early on can easily be transformed or worked around even very late in the project without much fuzz. So I don't use "size of the project" in my consideration to not user Python/Go/Rust/etc over Java.
- Nursie 6y ago
  > You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) I think this joke is probably about as dated as the versions of java it was made about.
  - BiteCode_dev 6y ago
    Unfortunatly, I know a lot of devs that don't even know it's a joke. Singleton is still a design pattern used in the wild.
    - Nursie 6y ago
      I'm not going to argue there are lots of ridiculous patterns out there, which seem to be embraced and encouraged by the various frameworks that a lot of developers seem to rely on. Why bother setting things up explicitly in the way you want when you can declare things as injected, other things as singletons, and then have no real idea why it all went horribly wrong?
      - BiteCode_dev 6y ago
        It's starting to be the same in Python though. Inertia is huge in our industry, and the HN bubble doesn't gives a good picture of it. Behind corporate firewalls I now see things done the way they were 10 years ago: packaging, string handling, concurrency... I assume it's the curse of being popular and old. And java has been popular for longer than Python, so inertia is even stronger. It doesn't matter if it has lambda since V8 if people still believe the best practice is to pass fat objects around.
    - drdec 6y ago
      The cool devs don't use the Singleton pattern anymore, we use @ApplicationScoped. (Poe's Law disclaimer: yes, that was light sarcasm.)
  - dvdkon 6y ago
    Generally the Python codebases I've looked at have been more straightforward and therefore more immediately readable than Java codebases. You could write a simple codebase in Java, but if so many people use it to write complex monoliths, maybe the language does have some (in my view negative) influence.
- doctor_eval 6y ago
  > You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language. You could (and IMO, probably should) just use a new Problem(). Java The Language was very stable for a very long time, so IMO the hype and fads got built on top. First we have a constructor - no, now we need a factory, but how to construct a factory? I know, let’s use another factory! All in the same unmodified language. Likewise, how do we configure an object? First we have methods, but languages are cooler, so let’s build a DSL, no wait let’s use a fluent API so it just looks like a DSL! I one had a dev replace a constructor call with a fluent builder, so now in the single use case where the object was ever created, we got five LOC where previously we had one. His code was idiomatic, it was bad engineering, but it wasn’t Java the language. Java is a pretty great language, but some of the crap people stuck on top of it was (and still is) a nightmare for readability and reusability. I use Go these days, and prefer their more basic approach to engineering, but there is much I miss from Java-the-language.
  - pydry 6y ago
    The crap people created on top was typically responses to deficiencies in the language, whether they knew it or not. Stuff like "everything is a class".
    - BiteCode_dev 6y ago
      Design design does lead community culture. Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles. Also design pattern were all the rage. Those things have a huge inertia, and while Java is not a much more flexible language, the image stuck, to the point that new comers still implement singletons in the wild.
      - pydry 6y ago
        Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance. It was very much a marketed language and a language designed to be sold to top heavy corporations. This fueled a lot of the crappy design decisions, the hype and the culture.
- slver 6y ago
  > You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) It's a funny joke, but it maligns a harmless pattern identical in FP to a function returning a function. While FP coders would brag about how awesome high-order functions are, we just keep mocking our own style for some reason. Factories are very powerful when used right.
- JAlexoid 5y ago
  The problem with Python today is that it only plays nice with C... which is a problem, since it's integration with JVM is probably more important today than 10 years ago.(Spark, Hadoop, etc)
mnw21cam 6y ago
I write software in Java. I can't stand python - too wishy-washy. But my main complaint about Python is trying to use someone else's software. Then it degenerates into a maze of twisty little passages of trying to install the correct set of dependencies, not knowing where those files are installed (which makes it difficult on a cluster, as you may need to do the install on every node separately). Then you try using pip and it fails because some element of what it is trying to install isn't compatible with your operating system for reason 1. So you try anaconda instead, and that fails in a different way, like it runs a C compiler on some file (!?) which fails because $REASON. I have numerous examples of Python software where I have followed the (detailed, precise) installation instructions, and it doesn't work. Whereas with Java, you just dump the necessary jars into a directory, include them in the classpath, and it works. Don't get me started on R.
- BiteCode_dev 6y ago
  I came to say say that's not a language problem, that's a packaging problem. But that would be misleading. The reason packaging is still a problem in Python are linked to the language: - to get perfs, you need compiled extensions, which java doesn't need. So a Jar can be fast and portable, while in Python it's an "or" proposition. Wheels help, but they still are OS dependent, so you need a build per OS. - PYZ arrived very late in Python, while WAR were a very early thing in Java. Few people even know you can distribute a whole Python program in a single zip file with dependencies using something like shiv (shiv.readthedocs.io). So few people do it, and it's a shame. We do it for 0bin though: https://github.com/Tygs/0bin/releases https://github.com/Tygs/0bin/releases. And it doesn't solve the wheel problem, although nuitka does but it a higher prices to pay. - packaging tooling have been a mess for 2 decades. Setuptools/distutils/setuptools2, easy_install/pip, and setup.cfg/setup.py/pyproject.toml. We failed as a community on this one. It's getting better, but it's a slow process. - the Python community is at least half composed of amateurs. It's a good thing for the dynamism of the community, but it also means the software are not very polished. Hard packaging + amateurs = packages that are releases when they reach "just good enough" stage, not one inch more. It also means you'll get things like leaking stack traces, config files in src and the likes. So yeah, compared to Java, Python packaging and distribution sucks. But compared to rust all packaging and distribution for all languages do, so there is that.
cs-szazz 6y ago
I used Kotlin in a large codebase, and one of my only complaints is the compile times. We use Gradle for our build system, and relative to Java it is slooowwww. But we like the other benefits of Kotlin, so it's worth it in the end. But if they could get compile times down, it'd be the perfect language imo.
- stepbeek 6y ago
  How large is the codebase? I moved to kotlin from scala and find the compilation to be rapid in comparison. Fwiw, I’m normally on a beefy desktop so I might just be brute forcing this issue.
  - cs-szazz 6y ago
    11,503 files, 1,431,195 lines of code. (spread out over <50 Gradle modules). I think the main problem is that Gradle doesn't have the same support as Java for ABI compatible changes, so invalidation of modules are more common.
    - stepbeek 5y ago
      This article points to ABI as an open optimization problem in kotlin: https://blog.jetbrains.com/kotlin/2020/09/the-dark-secrets-of-fast-compilation-for-kotlin/ https://blog.jetbrains.com/kotlin/2020/09/the-dark-secrets-o... I think you're right - ABI compatible changes are likely the culprit.
- cutler 6y ago
  1.5.0-RC was released a few days ago and contains rewritten compiler code which promises significant speed improvements.
  - ta988 5y ago
    It sure does, I updated everything a few days back and was really amazed. Everything is faster, even syntax highlighting.
  - 5y ago
V-2 6y ago
"the IDEs is not as good as the java counterparts yet" How do you mean? What IDEs are you referring to? Kotlin is fully (and very well) supported in IntelliJ Idea - unsurprisingly so, given that it's JetBrains own invention...
crazypython 6y ago
> Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all. Mypy is excellent. It has two-way type inference like Haskell. Good usage means catching almost all type errors before running. So is PyCharm, which is IntelliJ for Python.
- oblio 6y ago
  Except for the fact that absolutely every Java library is typed and maybe 0.1% of Python libraries are typed.
- FridgeSeal 5y ago
  I use mypy + type annotations diligently and while it’s a big improvement upon plain Python, it misses a lot of stuff and definitely not nearly as good as a proper static type system. I’d say it gives you maybe another 15% more “scalability runway” before pythons complexity catches up again.
andrepd 6y ago
Python is good for quick projects, but if you're writing a project with more than 2000 lines of python something's going wrong. The apparent ease of python becomes an unmanageable web of complexity. In the end you woukd have less headaches if you just used a proper statically typed language.
- BiteCode_dev 6y ago
  Dropbox, Youtube, Google, Instagram and NASA tell a different story. And me too. Scaling a Python project complexity is not harder than scaling Java, the things you have to be careful about are just different.
  - FridgeSeal 5y ago
    Are you the only person working on it? How big are we talking here, because I’ve worked on a few Python projects that fall in the region of “a couple to a few thousand lines” both by myself and with a team. Working by myself was significantly easier but Python definitely hits a “tangled mess” point, regardless of how disciplined I was. In comparison one of my personal projects is in Rust and while that’s currently maybe only a thousand lines it’s already significantly easier to deal with.
cutler 6y ago
Though I prefer Kotlin to Java I can't fathom why IntelliJ's Kotlin tooling is still so inferior to its Java tooling when it was JetBrains who invented Kotlin as a Java replacement.
- ta988 5y ago
  What are you missing specifically?

by wwn_se 6y ago

BiteCode_dev 6y ago

I've seen plenty of even small Java projects becoming hard to manage as well. The design pattern hell is a thing. You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) Not to say Java is not a great language for big projects, it certainly is well equipped for that, especially because it has superb tooling available on the market. But I've done plenty of big projects in Python, some ended badly, some ended great. Not to mentions dropbox, youtube and instagram are testaments to Python can be used in large projects. So I don't think Python is unsuitable for big sized projects. You certainly do have to worry about different problems than in Java, especially for projects that started without type hints. In my experience though, you reach less architecture dead ends with Python because the language is so flexible that a bad decision early on can easily be transformed or worked around even very late in the project without much fuzz. So I don't use "size of the project" in my consideration to not user Python/Go/Rust/etc over Java.

Nursie 6y ago
> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) I think this joke is probably about as dated as the versions of java it was made about.
- BiteCode_dev 6y ago
  Unfortunatly, I know a lot of devs that don't even know it's a joke. Singleton is still a design pattern used in the wild.
  - Nursie 6y ago
    I'm not going to argue there are lots of ridiculous patterns out there, which seem to be embraced and encouraged by the various frameworks that a lot of developers seem to rely on. Why bother setting things up explicitly in the way you want when you can declare things as injected, other things as singletons, and then have no real idea why it all went horribly wrong?
    - BiteCode_dev 6y ago
      It's starting to be the same in Python though. Inertia is huge in our industry, and the HN bubble doesn't gives a good picture of it. Behind corporate firewalls I now see things done the way they were 10 years ago: packaging, string handling, concurrency... I assume it's the curse of being popular and old. And java has been popular for longer than Python, so inertia is even stronger. It doesn't matter if it has lambda since V8 if people still believe the best practice is to pass fat objects around.
  - drdec 6y ago
    The cool devs don't use the Singleton pattern anymore, we use @ApplicationScoped. (Poe's Law disclaimer: yes, that was light sarcasm.)
- dvdkon 6y ago
  Generally the Python codebases I've looked at have been more straightforward and therefore more immediately readable than Java codebases. You could write a simple codebase in Java, but if so many people use it to write complex monoliths, maybe the language does have some (in my view negative) influence.
doctor_eval 6y ago
> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) I LOL’d at this joke (again) because it’s true, but if we’re honest, it’s also unfair. ProblemFactory is a bad idiom, rather than anything to do with Java The Language. You could (and IMO, probably should) just use a new Problem(). Java The Language was very stable for a very long time, so IMO the hype and fads got built on top. First we have a constructor - no, now we need a factory, but how to construct a factory? I know, let’s use another factory! All in the same unmodified language. Likewise, how do we configure an object? First we have methods, but languages are cooler, so let’s build a DSL, no wait let’s use a fluent API so it just looks like a DSL! I one had a dev replace a constructor call with a fluent builder, so now in the single use case where the object was ever created, we got five LOC where previously we had one. His code was idiomatic, it was bad engineering, but it wasn’t Java the language. Java is a pretty great language, but some of the crap people stuck on top of it was (and still is) a nightmare for readability and reusability. I use Go these days, and prefer their more basic approach to engineering, but there is much I miss from Java-the-language.
- pydry 6y ago
  The crap people created on top was typically responses to deficiencies in the language, whether they knew it or not. Stuff like "everything is a class".
  - BiteCode_dev 6y ago
    Design design does lead community culture. Java also had the unfortunate destiny of becoming popular at the time where "OOP all the thing" was a mantra in tech circles. Also design pattern were all the rage. Those things have a huge inertia, and while Java is not a much more flexible language, the image stuck, to the point that new comers still implement singletons in the wild.
    - pydry 6y ago
      Java created that hype to market itself. OOP all the things probably wouldn't have been a thing without it, for instance. It was very much a marketed language and a language designed to be sold to top heavy corporations. This fueled a lot of the crappy design decisions, the hype and the culture.
slver 6y ago
> You know the joke: a dev has a problem, uses Java, and now has a ProblemFactory :) It's a funny joke, but it maligns a harmless pattern identical in FP to a function returning a function. While FP coders would brag about how awesome high-order functions are, we just keep mocking our own style for some reason. Factories are very powerful when used right.
JAlexoid 5y ago
The problem with Python today is that it only plays nice with C... which is a problem, since it's integration with JVM is probably more important today than 10 years ago.(Spark, Hadoop, etc)

mnw21cam 6y ago

I write software in Java. I can't stand python - too wishy-washy. But my main complaint about Python is trying to use someone else's software. Then it degenerates into a maze of twisty little passages of trying to install the correct set of dependencies, not knowing where those files are installed (which makes it difficult on a cluster, as you may need to do the install on every node separately). Then you try using pip and it fails because some element of what it is trying to install isn't compatible with your operating system for reason 1. So you try anaconda instead, and that fails in a different way, like it runs a C compiler on some file (!?) which fails because $REASON. I have numerous examples of Python software where I have followed the (detailed, precise) installation instructions, and it doesn't work. Whereas with Java, you just dump the necessary jars into a directory, include them in the classpath, and it works. Don't get me started on R.

BiteCode_dev 6y ago
I came to say say that's not a language problem, that's a packaging problem. But that would be misleading. The reason packaging is still a problem in Python are linked to the language: - to get perfs, you need compiled extensions, which java doesn't need. So a Jar can be fast and portable, while in Python it's an "or" proposition. Wheels help, but they still are OS dependent, so you need a build per OS. - PYZ arrived very late in Python, while WAR were a very early thing in Java. Few people even know you can distribute a whole Python program in a single zip file with dependencies using something like shiv (shiv.readthedocs.io). So few people do it, and it's a shame. We do it for 0bin though: https://github.com/Tygs/0bin/releases https://github.com/Tygs/0bin/releases. And it doesn't solve the wheel problem, although nuitka does but it a higher prices to pay. - packaging tooling have been a mess for 2 decades. Setuptools/distutils/setuptools2, easy_install/pip, and setup.cfg/setup.py/pyproject.toml. We failed as a community on this one. It's getting better, but it's a slow process. - the Python community is at least half composed of amateurs. It's a good thing for the dynamism of the community, but it also means the software are not very polished. Hard packaging + amateurs = packages that are releases when they reach "just good enough" stage, not one inch more. It also means you'll get things like leaking stack traces, config files in src and the likes. So yeah, compared to Java, Python packaging and distribution sucks. But compared to rust all packaging and distribution for all languages do, so there is that.

cs-szazz 6y ago

I used Kotlin in a large codebase, and one of my only complaints is the compile times. We use Gradle for our build system, and relative to Java it is slooowwww. But we like the other benefits of Kotlin, so it's worth it in the end. But if they could get compile times down, it'd be the perfect language imo.

stepbeek 6y ago
How large is the codebase? I moved to kotlin from scala and find the compilation to be rapid in comparison. Fwiw, I’m normally on a beefy desktop so I might just be brute forcing this issue.
- cs-szazz 6y ago
  11,503 files, 1,431,195 lines of code. (spread out over <50 Gradle modules). I think the main problem is that Gradle doesn't have the same support as Java for ABI compatible changes, so invalidation of modules are more common.
  - stepbeek 5y ago
    This article points to ABI as an open optimization problem in kotlin: https://blog.jetbrains.com/kotlin/2020/09/the-dark-secrets-of-fast-compilation-for-kotlin/ https://blog.jetbrains.com/kotlin/2020/09/the-dark-secrets-o... I think you're right - ABI compatible changes are likely the culprit.
cutler 6y ago
1.5.0-RC was released a few days ago and contains rewritten compiler code which promises significant speed improvements.
- ta988 5y ago
  It sure does, I updated everything a few days back and was really amazed. Everything is faster, even syntax highlighting.
- 5y ago

V-2 6y ago

"the IDEs is not as good as the java counterparts yet" How do you mean? What IDEs are you referring to? Kotlin is fully (and very well) supported in IntelliJ Idea - unsurprisingly so, given that it's JetBrains own invention...

crazypython 6y ago

> Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all. Mypy is excellent. It has two-way type inference like Haskell. Good usage means catching almost all type errors before running. So is PyCharm, which is IntelliJ for Python.

oblio 6y ago
Except for the fact that absolutely every Java library is typed and maybe 0.1% of Python libraries are typed.
FridgeSeal 5y ago
I use mypy + type annotations diligently and while it’s a big improvement upon plain Python, it misses a lot of stuff and definitely not nearly as good as a proper static type system. I’d say it gives you maybe another 15% more “scalability runway” before pythons complexity catches up again.

andrepd 6y ago

Python is good for quick projects, but if you're writing a project with more than 2000 lines of python something's going wrong. The apparent ease of python becomes an unmanageable web of complexity. In the end you woukd have less headaches if you just used a proper statically typed language.

BiteCode_dev 6y ago
Dropbox, Youtube, Google, Instagram and NASA tell a different story. And me too. Scaling a Python project complexity is not harder than scaling Java, the things you have to be careful about are just different.
- FridgeSeal 5y ago
  Are you the only person working on it? How big are we talking here, because I’ve worked on a few Python projects that fall in the region of “a couple to a few thousand lines” both by myself and with a team. Working by myself was significantly easier but Python definitely hits a “tangled mess” point, regardless of how disciplined I was. In comparison one of my personal projects is in Rust and while that’s currently maybe only a thousand lines it’s already significantly easier to deal with.

cutler 6y ago

Though I prefer Kotlin to Java I can't fathom why IntelliJ's Kotlin tooling is still so inferior to its Java tooling when it was JetBrains who invented Kotlin as a Java replacement.

ta988 5y ago
What are you missing specifically?