3 ms·

I agree to some extent, however, IDEA often helps you with that (e.g. by converting arrays with Arrays.asList(array)). And I have to disagree: Any of them would

I agree to some extent, however, IDEA often helps you with that (e.g. by converting arrays with Arrays.asList(array)). And I have to disagree: Any of them would not have been perfect. An array is sometimes significantly more performant and requires less memory than a list. In the different collections, you see a history of 20 years of developer experience improvements coupled with an almost religious emphasis on backwards compatibility in the language and standard library. In every (long term) JS/TS project I worked on, about 20% - 50% of the development time went into upgrading libraries and keeping everything running on the current node version. It was maddening. Stuff like the different types of collections are a very small price to pay, IMHO, if you can be sure that your current Java project will with very high probability also run on a current JVM 10 years from now.

mcv 4y ago
> Any of them would not have been perfect. An array is sometimes significantly more performant and requires less memory than a list. That's actually why I prefer List, because a List is an interface and can be an ArrayList or another type of List and I don't care about the implementation, as long as it's a List. But Array is an array that's not a List, and Iterable is also an interface, and I think a List is also an Iterable, but I'm not sure, and I suspect not every Iterable is a List. And then there's Stream which should have been a set of convenient functions that are part of List or Iterable right from the start, but they're not. And what the hell is a Spliterator and why do I need one to turn an Iterator into a Stream? I understand that there are reasons for this, and I totally agree that the js/ts dependency situation is far from ideal, but it's still maddening to have so many different collection types, when js/ts just has an array that's not even an actual array, but it still works fine, and all the new stuff just gets added on top of it. One of these days someone should invent a new programming language that finally gets all of this right once and for all, but I bet people will find ways to improve it again.
- lmm 4y ago
  > I understand that there are reasons for this, and I totally agree that the js/ts dependency situation is far from ideal, but it's still maddening to have so many different collection types, when js/ts just has an array that's not even an actual array, but it still works fine, and all the new stuff just gets added on top of it. It "works fine" for basic cases but it doesn't give you anything like the same capabilities. JS/TS have no easy equivalent of array or stream, anything you could write in js/ts you could write in Java by only using ArrayList. Java's collections library is big and complex but almost everything that's in there is there because it has a use case, and while it's showing its age now it was well designed for its time. > One of these days someone should invent a new programming language that finally gets all of this right once and for all, but I bet people will find ways to improve it again. Your best hope is a language with Haskell-style typeclasses where you can not only add new implementations of existing interfaces, but also retrofit new interfaces onto existing implementations. No library is going to be perfect from day 1, and a big part of the reason why Java Stream is awkward is that it had to be retrofitted into the existing collection library.

mcv 4y ago

> Any of them would not have been perfect. An array is sometimes significantly more performant and requires less memory than a list. That's actually why I prefer List, because a List is an interface and can be an ArrayList or another type of List and I don't care about the implementation, as long as it's a List. But Array is an array that's not a List, and Iterable is also an interface, and I think a List is also an Iterable, but I'm not sure, and I suspect not every Iterable is a List. And then there's Stream which should have been a set of convenient functions that are part of List or Iterable right from the start, but they're not. And what the hell is a Spliterator and why do I need one to turn an Iterator into a Stream? I understand that there are reasons for this, and I totally agree that the js/ts dependency situation is far from ideal, but it's still maddening to have so many different collection types, when js/ts just has an array that's not even an actual array, but it still works fine, and all the new stuff just gets added on top of it. One of these days someone should invent a new programming language that finally gets all of this right once and for all, but I bet people will find ways to improve it again.

lmm 4y ago
> I understand that there are reasons for this, and I totally agree that the js/ts dependency situation is far from ideal, but it's still maddening to have so many different collection types, when js/ts just has an array that's not even an actual array, but it still works fine, and all the new stuff just gets added on top of it. It "works fine" for basic cases but it doesn't give you anything like the same capabilities. JS/TS have no easy equivalent of array or stream, anything you could write in js/ts you could write in Java by only using ArrayList. Java's collections library is big and complex but almost everything that's in there is there because it has a use case, and while it's showing its age now it was well designed for its time. > One of these days someone should invent a new programming language that finally gets all of this right once and for all, but I bet people will find ways to improve it again. Your best hope is a language with Haskell-style typeclasses where you can not only add new implementations of existing interfaces, but also retrofit new interfaces onto existing implementations. No library is going to be perfect from day 1, and a big part of the reason why Java Stream is awkward is that it had to be retrofitted into the existing collection library.