6 ms·

Citations, or rather, arguments needed. I wouldn't claim Java is the best language, but I don't see obvious deficiencies in JVM, in comparison (good, well thou

by avmich 6y ago

Citations, or rather, arguments needed. I wouldn't claim Java is the best language, but I don't see obvious deficiencies in JVM, in comparison (good, well thought-out comparison) with alternatives. Same for language - not only Java runs a hard task of strong backward compatibility for the third decade, it actually managed to implement some afterthought additions tolerably. So - while in the end the author might still be correct - arguments needed.

jjtheblunt 6y ago
the lack of bit intrinsics and unsigned integers was a show-stopping pain for a cancer genomics startup I worked at, where losing even a single bit here and there has huge performance cost in Apache Spark at the scale of genomic analyses over large datasets.
- avmich 6y ago
  Would be glad to hear details. From APL point of view C could be conidered below "barely tolerable", which doesn't prevent its, C, widespread use. It's hard to have a language convenient for all kinds of problems, so I'd like to learn details in your case.
  - jjtheblunt 6y ago
    the problem we were trying to solve included loading thousands of full human genome sequences into an Apache Spark distributed array, which means, behind the scenes, there's a collection of Linux hosts each with a JVM and those JVMs are running Apache Spark code, which shuffles around subsections of the virtual array among Linux (and thus JVM) instances, as the mathematical operators operate on them. For the genomic data of a single human, we would model our sequencing data as one of (if i remember how i did it) 5 values, for each position in the roughly 3 billion bases we tracked. So the representation of a genome was required roughly 3 billion instances of 3 bits each, but this wasn't how Apache Spark was written to calculate, you end up wasting 2 bits per byte in any semi fast packing scheme, but every byte is being shuttled around endlessly over the network. We fiddled around with various representation schemes but were always forced into wasting bits that we had no fast means (via processor intrinsics) of moving around. That's somewhat vague, but hopefully conveys the essence of the frustration.
distances 6y ago
The author is not talking about death of Java in general. Only the Fedora packages.
- avmich 6y ago
  I'm referring to this - "I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem." Well, personal preferences can differ, but I'd like to see arguments why Java&Co. can be described like this.
  - willtim 6y ago
    Google for "Enterprise FizzBuzz". And that one doesn't even use Spring. Yes it's a joke, but quite illustrative of why many dislike the Java culture and its ecosystem.
    - avmich 6y ago
      One doesn't need to use those traditions which are counterproductive. Java is flexible enough to allow for different styles regarding this approach. However I do see the point of criticism; it's just not enough, in my opinion, to dismiss the language and infrastructure altogether.
      - willtim 6y ago
        It can be difficult to avoid the culture/practices though. Every dependency you use, is code that you are ultimately responsible for. At a minimum you will need to learn how to use them; and you may need to debug and fix them. This is why it applies to other JVM languages too.

by avmich 6y ago

jjtheblunt 6y ago

the lack of bit intrinsics and unsigned integers was a show-stopping pain for a cancer genomics startup I worked at, where losing even a single bit here and there has huge performance cost in Apache Spark at the scale of genomic analyses over large datasets.

avmich 6y ago
Would be glad to hear details. From APL point of view C could be conidered below "barely tolerable", which doesn't prevent its, C, widespread use. It's hard to have a language convenient for all kinds of problems, so I'd like to learn details in your case.
- jjtheblunt 6y ago
  the problem we were trying to solve included loading thousands of full human genome sequences into an Apache Spark distributed array, which means, behind the scenes, there's a collection of Linux hosts each with a JVM and those JVMs are running Apache Spark code, which shuffles around subsections of the virtual array among Linux (and thus JVM) instances, as the mathematical operators operate on them. For the genomic data of a single human, we would model our sequencing data as one of (if i remember how i did it) 5 values, for each position in the roughly 3 billion bases we tracked. So the representation of a genome was required roughly 3 billion instances of 3 bits each, but this wasn't how Apache Spark was written to calculate, you end up wasting 2 bits per byte in any semi fast packing scheme, but every byte is being shuttled around endlessly over the network. We fiddled around with various representation schemes but were always forced into wasting bits that we had no fast means (via processor intrinsics) of moving around. That's somewhat vague, but hopefully conveys the essence of the frustration.

distances 6y ago

The author is not talking about death of Java in general. Only the Fedora packages.

avmich 6y ago
I'm referring to this - "I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem." Well, personal preferences can differ, but I'd like to see arguments why Java&Co. can be described like this.
- willtim 6y ago
  Google for "Enterprise FizzBuzz". And that one doesn't even use Spring. Yes it's a joke, but quite illustrative of why many dislike the Java culture and its ecosystem.
  - avmich 6y ago
    One doesn't need to use those traditions which are counterproductive. Java is flexible enough to allow for different styles regarding this approach. However I do see the point of criticism; it's just not enough, in my opinion, to dismiss the language and infrastructure altogether.
    - willtim 6y ago
      It can be difficult to avoid the culture/practices though. Every dependency you use, is code that you are ultimately responsible for. At a minimum you will need to learn how to use them; and you may need to debug and fix them. This is why it applies to other JVM languages too.