221–230 of 239 posts
I like this val z = (1..9).map {it * 3} .filter {it I'd like it more if it said it performed the functions in parallel. If it does this Automagically I'm sold. If it doesn't, is there an easy to use form that does do batch operations like map in parallel?
Earlier quoted context omitted.
Not OP, but why do you need the 'let' at all? Why not x = 7 mut y = 3 ?
Because it's a bit too error-prone: mut listOfLeftHandedOralHygienistsInKazakhstan = getThem() // several lines later listOfLeftHandedOralHygienistsInKazahkstan = getThemAgain() You thought you were reassigning the mutable variable, but you actually created a different immutable variable. This can be prevented by having different operators for assignment and re-assignment. Some languages do that: in OCaml / F#, re-as…
What do I have for kotlin?
Earlier quoted context omitted.
The Henry Ford quote about faster horses comes to mind.
You're trying to tell us that Scala is something better and we are just too stupid to understand it's power/beauty/importance?
It's also used by companies like Verizon, SAP, IBM, Walmart ... not exactly hipster research labs.
Earlier quoted context omitted.
It's not redundant; for example let (mut x, y) = (1, 2); x is mutable, y isn't. That is, let is the way that you introduce a new binding, always.
Not OP, but why do you need the 'let' at all? Why not x = 7 mut y = 3 ?
Earlier quoted context omitted.
Not even a bad thing. It's a pragmatic JVM language. It's 100% interoperable with Java without baggage like Groovy has. It's probably going to look like Java. Scala can look like Java if you write it very imperatively. What's nice about Kotlin is that the language supports idioms that allow you do diverge from "looking like Java" as you write it more.
Hope we never see "looks exactly like Java syntax but behaves differently when you run it" like we see in Apache Groovy, e.g. their == operator acts differently to Java's.
`a == b` compiles to `a.equals(b)`, if you want reference equality you need to type `a === b`.
Earlier quoted context omitted.
JetBrains is doing this, not Google. Google is only going to collaborate with JetBrains to help with the Android support. > Android update breaks your app which is written in Kotlin then it also breaks the same app written in java. Because the good thing about kotlin is that it is transparent, it generates bytecode as java does. So from the point of view of the platform there is no difference between kotlin and java.…
> JetBrains is doing this, not Google. Google is only going to collaborate with JetBrains to help with the Android support. Jetbrains isn't doing anything differently with Kotlin from what they've been doing for the past 7 years. The headline here is "Google officially supports Kotlin on Android," and that is what has HN so excited. Regardless of how the work involved in supporting Kotlin on Android is split, this re…
It is JetBrains who support it, Google is only going to collaborate with them to help them out and keep the support up to date.
You don't have any idea about kotlin, the API is exactly the same. It is the Java API for both Java and Kotlin. The support is more related with the tooling, no with the API.
Go, Haskell and C are completely different things. Java and Kotlin compile to bytecode and the JVM runs the bytecode. Both uses the same API in the same language (the bytecode). You only have to guarantee they target the same bytecode version, which is something Google cannot do anything about, it is JetBrains who decide. This is not like Java and C in Android. C has its own API which calls the Java API. Kotlin uses the Java API, and the JVM in the Android device doesn't know if the app was written in Kotlin or Java.
P.S. Actually Android doesn't use the compiled bytecode directly as it make some modifications, but the idea still applies.
Earlier quoted context omitted.
What exactly make it a great language? What are the advantages compared to Java? I search for it but couldn't find any simple answer to that question. The fact that things are shorter to declare doesn't make it better. It makes it less readable.
> The fact that things are shorter to declare doesn't make it better. It makes it less readable. That's not a hard and fast rule. There are obvious inflection points. A 200 character long identifier is less readable than a 20 character identifier in almost all cases. A 1 character identifier is less readable than a 8 character identifier in almost all cases. Somehwhere between those extremes is the sweet spot, and it…
Earlier quoted context omitted.
It's not redundant; for example let (mut x, y) = (1, 2); x is mutable, y isn't. That is, let is the way that you introduce a new binding, always.
Am I being a complete noob that only knows Python (I am) if I ask: Why do you need to declare that something is a mut or string or whatever? Python doesn't seem to need such extra lines with obvious declarations.
So with python I have virtual env. With elixir I have mix. For javascript I have npm. What do I have for kotlin?