191–200 of 239 posts
> val notPositive = not {it > 0}
This idiom took me by surprise. It's really quite lovely, and now I'm disappointed C# doesn't include it.
Earlier quoted context omitted.
Come on. This is not about actual production stuff. It's new! It's cool! That's pretty much it.
No so. Many people use it in production. The language has been around for 7 years and a stable 1.0+ release for over a year. It's very much more mature than swift and rust and certainly sibling to go in that regard.
Is anybody here using Kotlin for back-end work? It seems like I generally hear Kotlin come up in connection with Android, and less for writing server code, though that's where I'd potentially like to use it.
When you have the option to use Java 8 without caveats (unlike in Android), the benefits of Kotlin aren't really _that_ visible.
I'm never going back to Java on Android though.
Earlier quoted context omitted.
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.
Dynamic languages can convert types in runtime (so 1 + "f" = "1f") and not so many languages (not only dynamic) cares about mutability.
Earlier quoted context omitted.
My guess is it came from Scala? In practice it's not very tough to get it right.
Val might have originally been OCaml or Haskell.
> If a lambda has only one parameter then its declaration can be omitted (along with the ->). The name of the single parameter will be "it". > val notPositive = not {it > 0} This idiom took me by surprise. It's really quite lovely, and now I'm disappointed C# doesn't include it.
> "Function arguments are specified in brackets after the function name."
No they're not! They're specified in PARENTHESES after the function name.
Language quibble: > "Function arguments are specified in brackets after the function name." No they're not! They're specified in PARENTHESES after the function name.
Earlier quoted context omitted.
> * If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable.* That's nonsense. 1. You cannot implement immutable collections without `let` / `final` 2. The Java Memory Model has special visibility guarantees for `final` (which does propagate), making it really, really useful 3. Having the guarantee that a certain reference won't change is still useful even if the object referenc…
1. Sure you can, if you have encapsulation. 2. Java does a lot with the keyword 'final'. I guess here you're talking about the concurrency behaviors of it? Does it bother you that you can remove 'final' via reflection? 3. It's still useful (e.g. not needing to use yoda-style ifs in languages where you can assign inside an if expression Just In Case you forget an =), but not very. That's my whole point.
What `final` guarantees is that the variable will be initialized and visible (along with all its referenced objects) before the class constructor is finished. Without this guarantee you'd need `volatile` semantics or locks, which are more problematic.
2. yes, I'm talking about multi-threading; if the user removes "final" via reflection, or modifies final references via reflection, then it gets what he's asking for; but no, it does not bother me because I never do that and I stay away from libraries using reflection anyway.