Kotlin for data analysis
61–70 of 105 posts
Re: Kotlin for data analysis
#62Earlier quoted context omitted.
Kotlin's standard library has ruined me for other languages, especially its collections library. The consistency and comprehensiveness of its approach to collections is unmatched in any language I've tried, including all the big name functional languages. It's hard to get across what's so great about the library in writing because it's not just one standard library function, it's how they all interact with each other…
That's interesting. I've heard complaints about Kotlins standard library in comments like this[1]. I understand they may be nitpicks but they seem annoying in practice. [1] https://www.reddit.com/r/Kotlin/comments/mh2z5u/comment/gt2n...
Re: Kotlin for data analysis
#63Earlier quoted context omitted.
Kotlin's standard library has ruined me for other languages, especially its collections library. The consistency and comprehensiveness of its approach to collections is unmatched in any language I've tried, including all the big name functional languages. It's hard to get across what's so great about the library in writing because it's not just one standard library function, it's how they all interact with each other…
> Python refuses to implement proper lambdas Python has lambdas. What do you mean by "proper" lambdas?
Re: Kotlin for data analysis
#64Earlier quoted context omitted.
That's interesting. I've heard complaints about Kotlins standard library in comments like this[1]. I understand they may be nitpicks but they seem annoying in practice. [1] https://www.reddit.com/r/Kotlin/comments/mh2z5u/comment/gt2n...
Those are literally the same as Java, they’re impossible to fix without breaking interoperability with Java.
Re: Kotlin for data analysis
#65Earlier quoted context omitted.
I'm not sure how someone could see Kotlin as more expressive than Python, unless I am misinterpreting what expressive means. Python has a good language features and helpful abstractions like list comprehensions. What makes Kotlin more expressive? I understand it has some functional features but I've never seen anything dramatically flexible.
Kotlin's standard library has ruined me for other languages, especially its collections library. The consistency and comprehensiveness of its approach to collections is unmatched in any language I've tried, including all the big name functional languages. It's hard to get across what's so great about the library in writing because it's not just one standard library function, it's how they all interact with each other…
Scope functions are also great.
And the syntactic sugar where `foo({ a -> a })` and `foo { a -> b }` are the same makes code so much more readable.
I've done Python for a project at a previous job for a few months and it made me realize just how awful Python is, especially because you can't chain functions on collections as easily as you can in Kotlin. I also made me realize that I don't like dynamically typed languages.
Re: Kotlin for data analysis
#66Earlier quoted context omitted.
I'm not sure how someone could see Kotlin as more expressive than Python, unless I am misinterpreting what expressive means. Python has a good language features and helpful abstractions like list comprehensions. What makes Kotlin more expressive? I understand it has some functional features but I've never seen anything dramatically flexible.
As someone who uses Kotlin for work and Python for side projects (and loved Python years ago in college), Python's list comprehension feature is one of the things I hate the most about the language now. As a simple example using only two collection functions I find it much easier to read val hundredOrLessEvenSeconds = (1..1000) .toList() .filter { it than hundred_or_less_even_seconds = [timedelta(seconds=it) for it i…
List(1000) { i -> i+1 }
Which creates a list of 1 to 1000Re: Kotlin for data analysis
#67Re: Kotlin for data analysis
#68Re: Kotlin for data analysis
#69Earlier quoted context omitted.
Kotlin's standard library has ruined me for other languages, especially its collections library. The consistency and comprehensiveness of its approach to collections is unmatched in any language I've tried, including all the big name functional languages. It's hard to get across what's so great about the library in writing because it's not just one standard library function, it's how they all interact with each other…
That's interesting. I've heard complaints about Kotlins standard library in comments like this[1]. I understand they may be nitpicks but they seem annoying in practice. [1] https://www.reddit.com/r/Kotlin/comments/mh2z5u/comment/gt2n...
These are all reasonable but some are just lack of familiarity with the JDK standard library, or the reasons why things have to work that way to begin with.
For example, ArrayList not being immutable/thread safe. Although there are collections libraries that give you snapshot based collections, like this one:
https://github.com/Kotlin/kotlinx.collections.immutable
... I've never seen anyone use them because this is almost always the wrong design. Atomicity is usually needed at a coarser grain than a single collection, at which point you're needing to think about locking or transactions anyway, and if it isn't then the JDK standard library already offers concurrent lock-free lists or Collections.synchronizedList() which will give you the same effect. Having an object be mutated out from underneath you by a separate thread is a possibility of basically every language with shared memory. Only Rust tries to solve race conditions in the type system and its solution introduces many other problems.
He also complains that integer width/signedness casts only offer help from both the type system and the runtime! That's pretty good compared to other languages. Then he complains unsigned types are about the underlying bits not the semantic meaning of the number - well, yes, this is unintuitive but exactly the same as every other language because of the weirdness that inherently emerges when mixing signed with unsigned types. Java refuses to add unsigned numbers at all and they have their reasons for that! Unsigned numbers are really only meant for working with binary data formats, not encoding that something can't be negative. Use a jakarta.validation with a framework like Micronaut or Hibernate Validator if you want that.
Likewise for date and times sucking. If you use the long since deprecated classes designed in 1995 then maybe those suck by modern standards, although they're great for beginners. So don't use them: java.time is a modern package that treats timezones rigorously, at the cost of being a bit harder to understand.
Re: Kotlin for data analysis
#70I do both Kotlin and Python. More Kotlin than Python to be honest. But I'm pragmatic. Python is where all the action is when it comes to data science, llms, and all the rest. So it's the path of the least resistance. And there's a great argument to not challenge that and just do what everybody else does and put your head down and not criticize any of that. Which is why I use it on a few projects. The library ecosyste…
I work in a codebase that’s mostly kotlin and python and I’ve come to hate the python side. I used to love python, but I feel like the attempts to tack on typing have really undermined it. The “freedom” of being untyped is nice for quick little scripting things, but being typed is an absolute godsend in a real codebase. Instead of making python pseudo-typed with messy annotations, the scientific/research community sh…