Live data from Hacker News

Kotlin and linear programming

tomstechnicalblog.blogspot.com

41–46 of 46 posts

Re: Kotlin and linear programming

#41
post #30

Earlier quoted context omitted.

Python is often a second class citizen in these areas, even if much is made about its widespread support in the data science realm. I don't want to say it's hype is overblown... but a lot of the pain points and cracks in the seams are glossed over. Take spark, for instance. You run into extreme performance issues the second your data has to be serialized to cross the py4j gap. An many essential parts of its API requi…

Scala is a lot simpler than Kotlin once you get into the details - it uses a few simple but very general features rather than a lot of ad-hoc language-level functionality. A lot of the time what looks like some complex construct in Scala is actually two or three separate features combining in a way that makes perfect sense once you look at the pieces, and you can click through to see how the thing is implemented in p…

Interesting perspective, thanks. I'm not proficient with scala, and most of my attempts to learn more of it were to be able to read some bit of code in a tool or library that was giving me trouble. So... grains of salt and a that.

That being said, having gone through at least one book, and have read lots of code - I still find it very difficult to parse in my brain.

It feels more complex to me, because there seems like there are so many implicit things going on, where something like Kotlin makes efforts to be explicit (yet still strikes a nice level of conciseness). But that could also be my inexperience with scala.

Re: Kotlin and linear programming

#42

Earlier quoted context omitted.

Python is often a second class citizen in these areas, even if much is made about its widespread support in the data science realm. I don't want to say it's hype is overblown... but a lot of the pain points and cracks in the seams are glossed over. Take spark, for instance. You run into extreme performance issues the second your data has to be serialized to cross the py4j gap. An many essential parts of its API requi…

> In any case, a "not-java" language that can talk java is freakin amazing I don't understand why this is such a big draw for people when literally any jvm language[1] has this feature. Languages like jython, ABCL, clojure, jruby, groovy, and perl6. Kotlin is certainly not unique in this regard. 1: https://en.wikipedia.org/wiki/List_of_JVM_languages

Not sure what the downvote is for....

It's notable that projects like spark could have used Jython for its JVM/python interop, but chose py4j instead, consigning pyspark to some rather abysmal performance penalties under many conditions.

Re: Kotlin and linear programming

#43
post #16

Without wishing to disparage the article at all (I really love this kind of article, including this specific one) ... I feel like Kotlin is almost exactly the wrong language in this space. You either go all the way to a more powerfully typed language where Scala has grabbed mindshare, or you go fully towards dynamic languages like Python or (my favorite, even though it has almost no mindshare in this space), Groovy.…

In what way is Scala "more powerfully typed"?

Re: Kotlin and linear programming

#44
post #16

Without wishing to disparage the article at all (I really love this kind of article, including this specific one) ... I feel like Kotlin is almost exactly the wrong language in this space. You either go all the way to a more powerfully typed language where Scala has grabbed mindshare, or you go fully towards dynamic languages like Python or (my favorite, even though it has almost no mindshare in this space), Groovy.…

In what way is Scala "more powerfully typed"?

This kind of thing:

https://www.atlassian.com/blog/archives/scala-types-of-a-hig...

Re: Kotlin and linear programming

#45

Earlier quoted context omitted.

> In any case, a "not-java" language that can talk java is freakin amazing I don't understand why this is such a big draw for people when literally any jvm language[1] has this feature. Languages like jython, ABCL, clojure, jruby, groovy, and perl6. Kotlin is certainly not unique in this regard. 1: https://en.wikipedia.org/wiki/List_of_JVM_languages

Not sure what the downvote is for.... It's notable that projects like spark could have used Jython for its JVM/python interop, but chose py4j instead, consigning pyspark to some rather abysmal performance penalties under many conditions.

> Not sure what the downvote is for....

I'm not sure either. Your comment seems perfectly legitemate to me...

Re: Kotlin and linear programming

#46
post #30

Earlier quoted context omitted.

Scala is a lot simpler than Kotlin once you get into the details - it uses a few simple but very general features rather than a lot of ad-hoc language-level functionality. A lot of the time what looks like some complex construct in Scala is actually two or three separate features combining in a way that makes perfect sense once you look at the pieces, and you can click through to see how the thing is implemented in p…

Interesting perspective, thanks. I'm not proficient with scala, and most of my attempts to learn more of it were to be able to read some bit of code in a tool or library that was giving me trouble. So... grains of salt and a that. That being said, having gone through at least one book, and have read lots of code - I still find it very difficult to parse in my brain. It feels more complex to me, because there seems li…

Definitely read using an IDE rather than a text editor if you weren't already. Scala is the first language I've seen to really make intelligent use of the GUI - not in a dragging-boxes-and-arrows way, but with implicits that are visible subtly (green underline, expandable by mousing over) but not there by default. The way I see it, it's a novel middle ground for things that you don't want to be completely invisible, but don't want taking up a lot of space either, e.g. error handling (exceptions are completely invisible, go-style explicit error handling is too verbose) or access to mutable state, or async operations, or... (the for/yield sugar is similar, with a lightweight "Having different syntax for different kinds of effect as Kotlin does could be seen as more explicit I guess, but I find it actually makes it harder to work with - you have a lot more syntax to keep in your head, and you can't write generic code that works with multiple different effects. Other than that I don't think there's anything more explicit in Kotlin, and some things - error handling in particular - are definitely less explicit.
Post reply on HN