The collection literals are discussed regularly an...

# datascience

[voddan]

The collection literals are discussed regularly and I think the consensus is:
1) There are no valid use cases apart from demo ware
2) There is no nice way to introduce them with Kotlin's type system

[breandan]

1.) Could you expand on this a little? It seems there are plenty of use cases for collection literals. Array and matrix initialization is particularly common when working with data (just look at any Jupyter notebook). Maybe I don't understand, what makes a use case "valid" or "invalid"?

2.) In terms of typing, I don't see how [1] is any different from arrayOf(1).

[voddan]

Sure. Array initialization is wildly used for demonstration purposes, for example when you explain to students how to write a data analyzing algorithm. But it practice, when writing actually data pipelines, classifiers, etc, the matrixes are so big (hundreds of columns) that there is no point in manually initializing them in the code. You just load them from files, then use operators to manipulate them. Since the focus of K is production code, I think it will be wise to focus on handy operations for loading data and manipulating it (can be done with a lib) than optimizing for non-production scenarios

[voddan]

My second point is more technical. You are right that `[1]`and arrayOf(1) are identical. This is how Java do it, after all. The problem is that in Kotlin it is recommend to use lists instead of arrays. JDK arrays do not implement the Iterable interface, and thus they can't reuse all the nice operations for lists. Therefore it makes little sense to improve arrays initialization, and instead [1] should create a list if implemented.

[voddan]

Then there is the problem of "Which list should be the default?". Mutable, immutable, persistent list? Optimized for storage, or for speed of access, or for multithreading? If we pick one list, we imply that it is better then others, while in fact it all depends on the usage. IMO it not only goes agains kotlin's values, but also the values of JVM, which is build on an assumption that one can use any implementation she/he sees fit.

[voddan]

Languages like Python do not have this problem because they have only one "standard list implementation" for all purposes, which works fine since performance is not really a Python's goal and AFAIK nobody tries to add immutable collections in the picture.
Java doesn't have those problems because, how I mentioned earlier, it is somewhat okey with arrays as a legacy API.
Swift, being a "low-level" oriented language, is, much like Java, okey with arrays, more so since it is not JDK based.