2 ms·

> You declare your maven dependencies and they can be resolved as source or binary. In eclipse I can click through to any library function and see its source im

• lmm 9y ago
  > Surely, you can view Java dependency sources. It is just that most Java programmers don't care about the sources, they are just care about the jars (the default culture). Not my experience. Actually getting to the source of your dependencies, in practice, is easier in Java - just one click in your IDE - than in any other language. Doesn't that suggest that Java programmers care more about sources than other language users, not less? > In my honest opinion, cross-platform by bytecode has few advantages over cross-platform by source nowadays, on the other hand, cross-platform by bytecode has many inconveniences. Well you're entitled to your opinion but you should probably back it up with something more specific if you want to convince anyone else. > And, (in my taste), single central repository is bad. That's why I don't like Node also. The npm central repository is the source of many Trojans. Many Java and Node developers are not aware of and have no ideas on what they have downloaded through chain dependencies. You don't have to use a central repository if you don't want to, and some people don't, but it's very convenient to have the option if you want it. Maven central requires PGP signatures on anything published there, so it's very easy to enforce that all the dependencies you depend on come from trusted people if you really want to - as far as I know there's no non-JVM language that does that, certainly not with anything like as large a base of signed libraries available. > Normal != good. Agreed, but you started out by claiming that Java's culture is very weird. It isn't.
  • tapirl 9y ago
    > Well you're entitled to your opinion but you should probably back it up with something more specific if you want to convince anyone else. The only benefit of bytecode is to save compiling time. Nowadays, CPU becomes much faster than the time Java was invented, 20 years ago. So the benefit is weak now. Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax. It is not special, for script languages code runs anywhere without compiling.
    • readittwice 9y ago
      > Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax. I was once working on a large project on the JVM: our Fat-JAR was really working on Linux, Mac and Windows. The exact same JAR. And it didn't matter on which system we have built that JAR. This may not be possible for every use case - but I don't think it is a hoax. > It is not special, for script languages code runs anywhere without compiling. IMHO scripting languages like Ruby, Python, etc. are quite hard to deploy, especially if they have dependencies. In comparison to languages like Java, Go or Rust.
    • lmm 9y ago
      > The only benefit of bytecode is to save compiling time. Nowadays, CPU becomes much faster than the time Java was invented, 20 years ago. So the benefit is weak now. In terms of throughput I agree with you. But start-up latency is already Java's weakest point, and having to compile on startup would make it worse. > Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax. It is not special, for script languages code runs anywhere without compiling. True as far as it goes, but certain types of code simply aren't practical in scripting languages. You'll never see people implementing e.g. an image format decoder in a scripting language; they'll use bindings to a native-compiled (C) library instead, with all the problems distributing that entails. This is why things like docker are so popular with Python users: in theory Python is write-once-run-anywhere, but in practice most Python codebases end up depending on one or more native modules and need to have the correct version compiled. Whereas Java bytecode is adequate for things like image codecs, and in the real world you really do see large Java codebases that don't use any bindings to (non-JVM) native libraries.