Swift is like Kotlin
191–200 of 364 posts
Re: Swift is like Kotlin
#192Some considerations on the syntax (Swift first, Kotlin last in each pair) bad: \(apples + oranges) # using \ is looking for troubles good: ${apples + oranges} good: label + String(width) # even Ruby requires a .to_s here bad: label + width # surprises will follow good: ["Anna", "Alex", "Brian", "Jack"] super bad: arrayOf("Anna", "Alex", "Brian", "Jack") # make the long form optional good: for index in 1...5 { bad: fo…
Are you referring to escaping and other special sequences (e.g. unicode codes)? Though it is odd-looking I actually find it rather smart that they decided to reuse an existing mechanism for that: aside from delimiters the only magical character in a string is \ rather than have e.g. both \ and $.
> # the useless ()
My beef is more with 1..5 being inclusive and there apparently being no exclusive range.
> # why do we need to be so explicit?
Why would you want syntax which is harder to parse, more magical, and has to be repeated for every addition, instead of an easily marked `extension` block which neatly parallels `struct` or `class` ones?
Re: Swift is like Kotlin
#193Earlier quoted context omitted.
Sure thing... When will Jetbrain have a decent interface builder? Decent instrumentation? Decent documentation viewer? Can you get an object graph with JetBrains? Xcode isn't perfect, but it's way better than JetBrains. Just because one has one feature that one doesn't have, doesn't mean that Xcode beats JetBrain's IDE all day.
> Xcode isn't perfect, but it's way better than JetBrains. O_o Are you kidding me? People whinge all the time about jetbrains subscriptions, but I've literally never spoken to someone who's actually used their products and think that the alternative editors available (visual studio, xcode, etc) are actually better. There are some features like UI designers that you can't do without, but it's been a long time since I…
Re: Swift is like Kotlin
#194Earlier quoted context omitted.
Kotlin Native ships with an ARC. But depending on the application ARC can be a disadvantage since it can't automatically handle reference cycles like Kotlin on the JVM can.
> [Kotlin Native] features automatic reference counting with a cycle collector on top, but what the final memory management solution(s) will look like is unknown at this point. https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-...
Re: Swift is like Kotlin
#195Does anyone else think the Kotlin syntax for array literals is super ugly: val shoppingList = arrayOf("catfish", "water", "tulips", "blue paint") What is wrong with square bracket syntax? (rant over). EDIT: I suppose it's consistent with other syntax e.g. listOf() etc.
Well yeah, except it's really that Kotlin does not have array literals at all, arrayOf is just a variable-arity function.
Re: Swift is like Kotlin
#196Earlier quoted context omitted.
Ah, but is there a line? Where does it get drawn? Without explicitly naming them, once you get into the realm of Stalinism or the holocaust, surely it wouldn't take too much imagination to come up with a few names too unsavoury even for you?
There is no line. Expression is turing complete. That you might not like something I say does not have any effect on my right to say it as a human being. Obviously the names are tongue in cheek jabs. There's no language called Auschwitz, afaik, and even if there was, it would have as much right to exist as Java or Python or whatever. You don't get to tell people what to name things just because you're offended. You g…
Re: Swift is like Kotlin
#197Earlier quoted context omitted.
Swift has both external and internal parameter names for functions. This is to make API design more readable, easier to parse through. For example, you can have a function like so: func greet(with greeting: String, to personName: String) { print("\(greeting), \(personName)!") } In the above code, "with" and "to" are external names, and are only available when calling the function but are not available inside the func…
Having never used Swift, it feels like the syntax is being optimized for the less-common case; are named parameters considered the "default" choice in Swift, and is using different external names so common that it's worth cluttering the syntax for functions without external parameters in order to make the their own syntax easier?
Most definitely yes. In fact it used to be that the first parameter was implicitly positional (in Swift 2 IIRC), this was removed to make all parameters named by default.
And do note that you can provide a single label for a parameter, it will be used as both "internal" and "external" names:
func foo(bar: String) {
print(bar);
}
foo(bar: "3")
func baz(qux quux: String) {
print(quux);
}
baz(qux: "4")
> and is using different external names so commonAlso yes, it's absolutely ubiquitous, if only because that's the one way to provide "positional" parameter.
Re: Swift is like Kotlin
#198Past the syntax similarities, both of these languages are intended replacements for an 'old' language (Objective-C => Swift, Java => Kotlin) on a dominant mobile platform, with interoperability as a major selling point (requirement?). As a mobile dev (mainly iOS) this is awesome to see and although I love me some Objective-C, working with swift has been a pleasure. Now Java on the other hand... ( shudders ). With Goo…
[1]: https://flutter.io/
Re: Swift is like Kotlin
#199Earlier quoted context omitted.
Sure thing... When will Jetbrain have a decent interface builder? Decent instrumentation? Decent documentation viewer? Can you get an object graph with JetBrains? Xcode isn't perfect, but it's way better than JetBrains. Just because one has one feature that one doesn't have, doesn't mean that Xcode beats JetBrain's IDE all day.
Refactoring is a dream with JetBrains. But it is very language dependent, with Java having most support. Haven't used Kotlin in Intellij so I don't know how well Kotlin is supported, though I imagine rather well given that it their own language.
Re: Swift is like Kotlin
#200I feel like you could about as well write an article about how Go or Scala or TypeScript is like Kotlin. They all have some cases where they look similar or have some similar constructs borrowed from other sightly-less-recent languages. It doesn't seem like a very interesting or deep similarity. If you want to compare them, going over the differences would be a lot more illuminating.