7 ms·

It's not Java, it's the java culture. Yes, Maven and Gradle are weirdly complex, but they are workable. And .jar files are just downright amazing compared to m

It's not Java, it's the java culture. Yes, Maven and Gradle are weirdly complex, but they are workable. And .jar files are just downright amazing compared to most other things (I'm looking at you madman Python dependencies!) Hint: maybe you could come up with something like npm for Java ? Maybe it's waiting to happen? And Javadocs are mundane but still better than 'nodocs' which is the standard on Node.js which really needs to change, and could start with some standardization and leadership from somewhere ... maybe the Typescript team? Oh, and also, since everything is JSON, and that blends nicely with JS ... my god man that's so much nicer than JSON/XML in Java which is often unwiedy.

paulie_a 8y ago
What's wrong with python dependcies? It's literally a small requirements file. If anything npm and js is the shit show for that.
- abhisuri97 8y ago
  I teach javascript to students coming from Java and Python and, while I do agree npm could be better, students find it to be so much more intuitive rather than have some IDE handle packages (in the case of java) or be stored somewhere in your system path with python. Being able to see the dependency within node_modules and make that connection between you saying "i want to install this" and it appears in your project file system makes a bunch of sense for beginners.
  - paulie_a 8y ago
    I honestly don't get why I was down voted but mkvirtualenv, workon xyz, pip install -r requirements.txt isn't exactly a huge barrier to entry with a python project. Personally I always saw the node_modules directory as something to be ignored. It's a crowded bunch of junk.
    - mythrwy 8y ago
      Fully agree. NPM is a complete three ring circus compared to pip and a requirements.txt file.
    - deleted 8y ago
      [deleted]
    - lostcolony 8y ago
      I admit I haven't used Python that much, but I'd say about 90% of the libraries and projects I had interest in didn't have a requirements.txt. I've used Node a LOT, and I have yet to have a library or project -not- have a package.json. I'll readily admit that Python has the -ability- to be a well maintained environment. THe fact it doesn't default and practically enforce it has led to a culture where it's not often used. And half the mindshare uses conda environments instead.
    - dagenix 8y ago
      I didn't downvote you. However, I do disagree with what you are saying. In Python, the absolute most trivial case, is already a big pain. In order to get a project started, you need to: 1) create a virtual environment (which you can do with virtualenv, python -m venv, virtualenvwrapper, pyenv-virtualenv, Pipenv, poetry, or, Conda - but lets ignore Conda from here on out). 2) next, you may need to activate the virtual environment - but, its easy to forget to do this or to activate the wrong one. And, depending on how you created the virtual environment, you have to do it differently. 3) once activated, you then need to install your dependencies - possibly using pip, or, maybe using Pipenv or poetry. 4) Depending on the type of project you are setting up, you may also need to create a setup.py file, otherwise you won't be able to install the new project you are working on into a virtual environment. 5) Then, you probably need to configure your IDE to use your virtual environment - depending on how you created it your IDE may pick it up automatically, but, it probably didn't. Then, you can get down to work. But, thats the easy case - the more painful case is when you want to either deploy your project or you want to update it. If you didn't use Pipenv or poetry, you're going to need to create a requirements file - probably with pip freeze. You can then go to a different virtual environment and do a pip install -r to install the requirements from that file. Of course, when developing your code, you may have installed modules like py.test that you don't want to install on your production system - but pip doesn't know the difference between a development and a runtime dependency, so, you either need to edit the requirements file generated by pip freeze by hand, or, just live with deploying code you don't want to to production. If you used Pipenv or poetry, at least then you can keep development and runtime dependencies separate. However, both of these tools are less available than pip, so, this generally means you have to install them on your production system - which, given that they are newer, tends to be awkward to do since it may involve pulling down code from github directly. Alternatively, you can do a pip freeze to create a requirements file, but, then you are back to pull in dependencies you may not want. The next thing you're going to want to do is to update some dependencies. If all you have is a requirements.txt file, well, you are pretty much out of luck. If it was created by pip freeze, its going to include all of your transitive dependencies - good luck remembering which ones you use directly and which ones you don't. Maybe you didn't use pip freeze to create it, however, and you created it by hand. Well, now you'll know which dependencies you actually are using, since, you only put those in the file - however, the problem then becomes that since you didn't list your transitive dependencies, whenever you install the requirements, you could get a different set of transitive dependencies - and if you accidentally started using one of them without realizing it, this could break your production system. So, maybe you listed all of your dependencies in your setup.py file - if so, you can always delete your virtual environment, reinstall everything from your setup.py file, and then re-generate your requirements file. However, doing that is a massive, massive pain since it involves a number of commands. If you try to do this, odds are that your setup.py and your requirements files start to fall out of sync and you give up on one or the other of them. Pipenv helps - a bit. Its more of a replacement for the requirements file than for the setup.py file - which leads to the odd problem of not knowing if you should list your requirements in both places or try to have one include the other. Whats made more fun, is that Pipenv's interface includes a bunch of options that don't make much sense (pipenv install includes the options "--selective-upgrade", "--keep-outdated", "--skip-lock", and "--ignore-pipfile" and its not really all that clear what they are supposed to do). What I'd like to be able to do is to either update either a single dependency OR update them all, at my discretion. I assume that some combination or its arcane options are supposed to allow you to update a single dependency without updating all of them - however, if so, its not clear which one is supposed to do that as it seems like both "--selective-upgrade" and "--keep-outdated" might do that. However, worse than not knowing what option you should use, it seems like neither of them actually does work: https://github.com/pypa/pipenv/issues/966 https://github.com/pypa/pipenv/issues/966 has been open for a while and has been dismissed by the maintainers as not a problem, then "fixed", then acknowledged that it didn't actually work, and then they went dark. So, as it stands, if you try to update any dependency, Pipenv is probably going to insist on updating everything - so, have fun testing that. Poetry is probably the strongest contender for making this whole mess sane. But, for reasons that seem to completely defy logic, Pipenv is getting most of the attention in this space. It appears to be mostly a one person project - and so tying a project to it feels risky. Despite all that, it does work pretty well, but, there are still a lot of features that would be great to see and it would be really great to see it get some more attention and manpower.
  - jjjensen90 8y ago
    Just so you know, 95% of the few hundred Java devs I've worked with in the last few years used maven or gradle on the command line to handle packages, including junior developers. I think the Java = IDE concept is outdated (although IntelliJ IDEA is an amazingly well-integrated IDE with Java).
mkozlows 8y ago
It's not just Java culture, though, it's also Java. For instance, you can't have "npm for Java," because that's not how Java works at a very fundamental level. Java gets gigantic monolithic framework libraries because Java's class loader works fundamentally differently from Node's CommonJS module system.
- hyperpallium 8y ago
  Please elaborate.
- sonnyblarney 8y ago
  Wha? I don't think so. An npm-like framework could work for Java. The difference between classloading and node.js 'require' module loader is not super relevant. Frankly - the reason that Maven and Gradle are more sophisticated is because many Java projects are massive compared to most JS projects, the amount of complexity, various kinds of packaging, testing etc. necessitates some inherent complexity in modules. Java modules tend to be a lot bigger as well. Again I think it's a cultural issue.
  - bodas 8y ago
    npm works because you can have lodash v3 and lodash v4 existing at the same time, at runtime. Node sees two pieces of code at different locations on disk, and loads them twice, considering them to have no relationship. This means that a library can turn its API completely inside out and not cause dependency hell. Your dependencies can update their sub-dependencies in their own time. This means there's no pressures against releasing new updates, and leads to the beautiful and very productive chaos that is npm. Java is not designed to work this way.
    - RandyRanderson 8y ago
      > "you can have ... v3 and ... v4 existing at the same time, at runtime" That's exactly what Java ClassLoaders do...
    - step21 8y ago
ilaksh 8y ago
The standard for Node.js is highly modularized code where every module gets a README with examples and usually fairly comprehensive documentation. If you mean that you think Javadocs format and type of details is ideal or ideal for JavaScript then please study JavaScript and Node.js more.
- jonny_eh 8y ago
  And increasingly type definitions too.
bborud 8y ago
It is a mystery to me why Python never managed to deal with the single biggest reason why it is unusable for serious software development.
- bborud 8y ago
  I'm kind of sad that someone would downvote this without really asking why I might think Python isn't suitable for serious software development. The main reason is that it isn't a language that is nice to users. It shifts the entire burden of setting up an environment to run the Python application in. Which means that installing software tends to be a messy affair at the best of times, and a complete mystery to most non-programmers. The difference between a good professional software developer and someone who is a just hack, is empathy with the user. Having an obvious way to package applications allows developers to be nice to their users. Python never provided that, so rather than producing nice binaries (or something akin to Jar files) it just dumps the problem of assembling the bits in the user's lap. That's a dick move.
sametmax 8y ago
Dependencies in python has evolved a lot in the last 2 years. You can use a simple setup.cfg to make them, and you can use a wheel like a jar if you want.
- passiveincomelg 8y ago
  Unless C libraries are involved. Which is almost always the case.
  - sametmax 8y ago
    First, no it's not. I just checked. 1 out of 12 projects on my laptop have c dependancies. Second, wheels allow installing c dep tranparently now. And the top 20 c dep have wheels for windows, mac and most linux.
    - passiveincomelg 8y ago
      You are right, "almost always the case" was a baseless claim and binary wheels are better than nothing. However, how many projects still have "psycopg2" in their setup.py (or is it requirements.txt? ;) instead of "psycopg2-binary"? I just found out that the latter exists when I checked PyPI.
      - sametmax 8y ago
        I'm not pretending all is fine in the kingdom. But a lot of big Python issues (2 vs 3, encoding, deps) are a in a fantastic state compared to years ago and I think it's important that people don't stay stuck on a bad impression from past mistakes. It's also for me a way to acknowledge the huge work the community has been putting into fixing what's been asked.
- sonnyblarney 8y ago
  Ok, so there's some new mechanisms? That's not so much the issue - as Python package/dependency problems are not so much a problem of 'how it works' - it's an issue because nobody is on the same page. It's byzantine. If python dependencies boiled down to 'point to a directory' well then fine, everything would work that way and we'd build tools around it, docs would be clear etc. etc.. But as someone who uses Python seldom and loves the syntax, I generally stay away from it mostly for that reason. And lack of typing which is obviously another discussion.

paulie_a 8y ago

What's wrong with python dependcies? It's literally a small requirements file. If anything npm and js is the shit show for that.

abhisuri97 8y ago
I teach javascript to students coming from Java and Python and, while I do agree npm could be better, students find it to be so much more intuitive rather than have some IDE handle packages (in the case of java) or be stored somewhere in your system path with python. Being able to see the dependency within node_modules and make that connection between you saying "i want to install this" and it appears in your project file system makes a bunch of sense for beginners.
- paulie_a 8y ago
  I honestly don't get why I was down voted but mkvirtualenv, workon xyz, pip install -r requirements.txt isn't exactly a huge barrier to entry with a python project. Personally I always saw the node_modules directory as something to be ignored. It's a crowded bunch of junk.
  - mythrwy 8y ago
    Fully agree. NPM is a complete three ring circus compared to pip and a requirements.txt file.
  - deleted 8y ago
    [deleted]
  - lostcolony 8y ago
    I admit I haven't used Python that much, but I'd say about 90% of the libraries and projects I had interest in didn't have a requirements.txt. I've used Node a LOT, and I have yet to have a library or project -not- have a package.json. I'll readily admit that Python has the -ability- to be a well maintained environment. THe fact it doesn't default and practically enforce it has led to a culture where it's not often used. And half the mindshare uses conda environments instead.
  - dagenix 8y ago
    I didn't downvote you. However, I do disagree with what you are saying. In Python, the absolute most trivial case, is already a big pain. In order to get a project started, you need to: 1) create a virtual environment (which you can do with virtualenv, python -m venv, virtualenvwrapper, pyenv-virtualenv, Pipenv, poetry, or, Conda - but lets ignore Conda from here on out). 2) next, you may need to activate the virtual environment - but, its easy to forget to do this or to activate the wrong one. And, depending on how you created the virtual environment, you have to do it differently. 3) once activated, you then need to install your dependencies - possibly using pip, or, maybe using Pipenv or poetry. 4) Depending on the type of project you are setting up, you may also need to create a setup.py file, otherwise you won't be able to install the new project you are working on into a virtual environment. 5) Then, you probably need to configure your IDE to use your virtual environment - depending on how you created it your IDE may pick it up automatically, but, it probably didn't. Then, you can get down to work. But, thats the easy case - the more painful case is when you want to either deploy your project or you want to update it. If you didn't use Pipenv or poetry, you're going to need to create a requirements file - probably with pip freeze. You can then go to a different virtual environment and do a pip install -r to install the requirements from that file. Of course, when developing your code, you may have installed modules like py.test that you don't want to install on your production system - but pip doesn't know the difference between a development and a runtime dependency, so, you either need to edit the requirements file generated by pip freeze by hand, or, just live with deploying code you don't want to to production. If you used Pipenv or poetry, at least then you can keep development and runtime dependencies separate. However, both of these tools are less available than pip, so, this generally means you have to install them on your production system - which, given that they are newer, tends to be awkward to do since it may involve pulling down code from github directly. Alternatively, you can do a pip freeze to create a requirements file, but, then you are back to pull in dependencies you may not want. The next thing you're going to want to do is to update some dependencies. If all you have is a requirements.txt file, well, you are pretty much out of luck. If it was created by pip freeze, its going to include all of your transitive dependencies - good luck remembering which ones you use directly and which ones you don't. Maybe you didn't use pip freeze to create it, however, and you created it by hand. Well, now you'll know which dependencies you actually are using, since, you only put those in the file - however, the problem then becomes that since you didn't list your transitive dependencies, whenever you install the requirements, you could get a different set of transitive dependencies - and if you accidentally started using one of them without realizing it, this could break your production system. So, maybe you listed all of your dependencies in your setup.py file - if so, you can always delete your virtual environment, reinstall everything from your setup.py file, and then re-generate your requirements file. However, doing that is a massive, massive pain since it involves a number of commands. If you try to do this, odds are that your setup.py and your requirements files start to fall out of sync and you give up on one or the other of them. Pipenv helps - a bit. Its more of a replacement for the requirements file than for the setup.py file - which leads to the odd problem of not knowing if you should list your requirements in both places or try to have one include the other. Whats made more fun, is that Pipenv's interface includes a bunch of options that don't make much sense (pipenv install includes the options "--selective-upgrade", "--keep-outdated", "--skip-lock", and "--ignore-pipfile" and its not really all that clear what they are supposed to do). What I'd like to be able to do is to either update either a single dependency OR update them all, at my discretion. I assume that some combination or its arcane options are supposed to allow you to update a single dependency without updating all of them - however, if so, its not clear which one is supposed to do that as it seems like both "--selective-upgrade" and "--keep-outdated" might do that. However, worse than not knowing what option you should use, it seems like neither of them actually does work: https://github.com/pypa/pipenv/issues/966 https://github.com/pypa/pipenv/issues/966 has been open for a while and has been dismissed by the maintainers as not a problem, then "fixed", then acknowledged that it didn't actually work, and then they went dark. So, as it stands, if you try to update any dependency, Pipenv is probably going to insist on updating everything - so, have fun testing that. Poetry is probably the strongest contender for making this whole mess sane. But, for reasons that seem to completely defy logic, Pipenv is getting most of the attention in this space. It appears to be mostly a one person project - and so tying a project to it feels risky. Despite all that, it does work pretty well, but, there are still a lot of features that would be great to see and it would be really great to see it get some more attention and manpower.
- jjjensen90 8y ago
  Just so you know, 95% of the few hundred Java devs I've worked with in the last few years used maven or gradle on the command line to handle packages, including junior developers. I think the Java = IDE concept is outdated (although IntelliJ IDEA is an amazingly well-integrated IDE with Java).

mkozlows 8y ago

It's not just Java culture, though, it's also Java. For instance, you can't have "npm for Java," because that's not how Java works at a very fundamental level. Java gets gigantic monolithic framework libraries because Java's class loader works fundamentally differently from Node's CommonJS module system.

hyperpallium 8y ago
Please elaborate.
sonnyblarney 8y ago
Wha? I don't think so. An npm-like framework could work for Java. The difference between classloading and node.js 'require' module loader is not super relevant. Frankly - the reason that Maven and Gradle are more sophisticated is because many Java projects are massive compared to most JS projects, the amount of complexity, various kinds of packaging, testing etc. necessitates some inherent complexity in modules. Java modules tend to be a lot bigger as well. Again I think it's a cultural issue.
- bodas 8y ago
  npm works because you can have lodash v3 and lodash v4 existing at the same time, at runtime. Node sees two pieces of code at different locations on disk, and loads them twice, considering them to have no relationship. This means that a library can turn its API completely inside out and not cause dependency hell. Your dependencies can update their sub-dependencies in their own time. This means there's no pressures against releasing new updates, and leads to the beautiful and very productive chaos that is npm. Java is not designed to work this way.
  - RandyRanderson 8y ago
    > "you can have ... v3 and ... v4 existing at the same time, at runtime" That's exactly what Java ClassLoaders do...
  - step21 8y ago

ilaksh 8y ago

The standard for Node.js is highly modularized code where every module gets a README with examples and usually fairly comprehensive documentation. If you mean that you think Javadocs format and type of details is ideal or ideal for JavaScript then please study JavaScript and Node.js more.

jonny_eh 8y ago
And increasingly type definitions too.

bborud 8y ago

It is a mystery to me why Python never managed to deal with the single biggest reason why it is unusable for serious software development.

bborud 8y ago
I'm kind of sad that someone would downvote this without really asking why I might think Python isn't suitable for serious software development. The main reason is that it isn't a language that is nice to users. It shifts the entire burden of setting up an environment to run the Python application in. Which means that installing software tends to be a messy affair at the best of times, and a complete mystery to most non-programmers. The difference between a good professional software developer and someone who is a just hack, is empathy with the user. Having an obvious way to package applications allows developers to be nice to their users. Python never provided that, so rather than producing nice binaries (or something akin to Jar files) it just dumps the problem of assembling the bits in the user's lap. That's a dick move.

sametmax 8y ago

Dependencies in python has evolved a lot in the last 2 years. You can use a simple setup.cfg to make them, and you can use a wheel like a jar if you want.

passiveincomelg 8y ago
Unless C libraries are involved. Which is almost always the case.
- sametmax 8y ago
  First, no it's not. I just checked. 1 out of 12 projects on my laptop have c dependancies. Second, wheels allow installing c dep tranparently now. And the top 20 c dep have wheels for windows, mac and most linux.
  - passiveincomelg 8y ago
    You are right, "almost always the case" was a baseless claim and binary wheels are better than nothing. However, how many projects still have "psycopg2" in their setup.py (or is it requirements.txt? ;) instead of "psycopg2-binary"? I just found out that the latter exists when I checked PyPI.
    - sametmax 8y ago
      I'm not pretending all is fine in the kingdom. But a lot of big Python issues (2 vs 3, encoding, deps) are a in a fantastic state compared to years ago and I think it's important that people don't stay stuck on a bad impression from past mistakes. It's also for me a way to acknowledge the huge work the community has been putting into fixing what's been asked.
sonnyblarney 8y ago
Ok, so there's some new mechanisms? That's not so much the issue - as Python package/dependency problems are not so much a problem of 'how it works' - it's an issue because nobody is on the same page. It's byzantine. If python dependencies boiled down to 'point to a directory' well then fine, everything would work that way and we'd build tools around it, docs would be clear etc. etc.. But as someone who uses Python seldom and loves the syntax, I generally stay away from it mostly for that reason. And lack of typing which is obviously another discussion.