inline fun <T> Iterable<T>.lazy() = asSequence()

works for you? simple smile

Also, you can try

import kotlin.collections.asSequence as lazy

, although code completion doesn't work quite well for this aliased import currently.

sorry @mplatvoet , I just didn't want to discuss it on the "code is read more than being written" level. My apologies .

@orangy: yep, that's exactly what I meant, the idea was to unify the form of that, so that different projects would not end up using

lazy

,

seq

,

asq

, etc

I don't think you can unify all the code. Inevitably there will be functions like that, just for the sake of style or taste

At this point I personally think unambiguous code is better.

I'm new to Kotlin. I have been using Scala since 2005, and Java since 1995.

In a recent discussion on #C0922A726 I asked if I should approach Kotlin from the Scala direction or the Java direction. I was told "Probably Scala for everything apart from collections."

Okay, interesting comment. For the most part, I enjoy the Scala collections, but they are not without their problems. In the mean time, Java's collections have been improving, with apparent influence from Scala and elsewhere. Much of the improvement I have experienced with collections is a direct result of the influence of Functional Programming (FP). In particular, advances in FP and collections have really changed how I think about programming now.

I'm sure you miss

CanBuildFrom

dearly

Some of the things I like about Kotlin are idioms such as

for ((k, v) in map) {
    println("$k -> $v")
}

I have wanted to do things this easily in Scala for a long time, but I tire of the explanations from some people as to why I am a stupid idiot for expecting that. I really appreciate that in Kotlin, it just works, it's readable, and easy to remember. Granted it's still incomplete, but things are improving in a direction I like.

Anyway, I am wondering what the current thinking is on Kotlin collections in the future. What will it look like? Will it look more like Java or Scala, or will Kotlin contribute its own unique perspective on collections?

@cedric: While I like much of http://docs.scala-lang.org/overviews/core/architecture-of-scala-collections.html I cannot say I understand all of it 😉

The Kotlin team is busy snowboarding... I mean, shipping 1.0 right now so we'll have to wait for their reaction to this, but my general impression is that Kotlin's philosophy in that area is to avoid at all costs rewriting collection code

Fair enough. Leveraging off of Java is fine.

I am not expert enough with Kotlin to have a good sense of things yet, just curious about what to expect in the future.

I would say that after 20 years of Java, and 10 years of Scala, there are lots of lessons for the Kotlin team to learn from.

Years ago I saw and found it rather interesting food for thought.

@eric.kolotyluk: I don't know if you got a chance to see Kotlin's original documentation but basically, each page closed on a list of justifications for why such feature was included or excluded. Such justifications used other languages (Java,Scala, Hakell, Javascript and others) to explain the reasoning but also other items such as chapters from Effective Java or Design Patterns. I think it's pretty clear the Kotlin team spent a very, very long time doing homework on PL history.

Where would I find it?

I'm not sure, hopefully it's been archived (or maybe the wayback machine?)

I thought this gave a very candid and honest presentation of the motivations. And to be clear, I don't think someone creating a new language even needs to justify themselves (basically, I think creating a new language just because you want to is good enough in my book) but it showed clear motivation from the Kotlin team that they are being extremely serious about this endeavor.

@eric.kolotyluk: I was at Paul’s talk at PNWScala as a (mostly) scala outsider, and it made me run away from scala as fast as I possibly could.

There are some really great ideas in Scala, a lot of stuff I really like, but my sense it that it has been hijacked by the scientists who just want to play, and engineers who need to build real stuff that is robust and maintainable have been ignored, or worse.

Scala is an experiment that escaped the lab

@eric.kolotyluk: Regarding collections, I also came to Kotlin from Scala (and Java) and thought I'd desperately miss Scala's immutable collections - so much so I ported them to Java and Kotlin (https://github.com/andrewoma/dexx/tree/master/kollection). However, I've actually found that I don't use them in Kotlin. My usage is almost always involves building up a collection inside a method and passing it out as a read only view

It hasn't been hijacked, it's always been an academic experiment whose only goal was to produce research papers

See Dotty for more evidence of that

Right, I tried to take a look at Dotty, on Martin's advice, but there is not enough there for me to get a handle on.

Dotty is interesting but purely as an intellectual pursuit. And also as an excuse to justify scalac's bugginess ("Oh it's fixed in dotty, we don't have to fix it in scalac")