Swift
print("Hello, world!")
Kotlin fun main(args: Array) {
println("Hello, world!")
}61–70 of 364 posts
Swift
print("Hello, world!")
Kotlin fun main(args: Array) {
println("Hello, world!")
}One has structures, ARC, proper extensions, good protocols/interfaces, flexible enums, and runs natively. The other one doesn't. I think I'll choose the former.
One has structures, ARC, proper extensions, good protocols/interfaces, flexible enums, and runs natively. The other one doesn't. I think I'll choose the former.
As for the post, it's ridiculously fanboyish.
The same comparison could be made with other older languages towards Kotlin. Microsoft F# comes to mind, for example.
Pretty good list. I don't think the tuple comparison is accurate though, I thought a data class is basically a value type (like Swift's struct) except with some stuff like equals, hashcode, and toString calculated for you. Minor nit: the sort example needlessly uses two lines for the Swift version.
Earlier quoted context omitted.
Ugh, I know it's something that literally every programmer on earth can and often does bikeshed, but Swift just got string interpolation syntax wrong . Parentheses are something that are often part of the interpolated expression... they shouldn't be part of the interpolation syntax itself.
Yes, agreed. IMO, curly braces would have made much more sense. It's not even bikesheding, really. It's just a fact that curly braces are less used in most written languages. I would also argue that curly braces are a better signal to the programmer that "something programmatic is happening here", due to their prevalence as scope delimiters in most popular languages. Swift's string interpolation doesn't catch my eye…
Earlier 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?
The internal/external name divide often works out beautifully. For example, let's equip Double with a multiply-add. An idiomatic Swift signature:
extension Double {
func multiply(by multiplier:Double, adding summand:Double) -> Double {
return self * multiplier + summand
}
}
print(3.multiply(by:4, adding:5))
Erase punctuation and you have: func multiply by multiplier adding summand
print 3 multiply by 4 adding 5
The caller sees an action (multiply by, adding), the callee sees nouns (multiplier, summand). It's fantastically readable.Earlier quoted context omitted.
Yes, but the corresponding design decision would be "0..=n". Swift's "0...n" is a bit less obvious. Also, exclusivity is almost always what you want, so "0..n" should just default to exclusivity and "0...n" could be inclusive.
This is the exact opposite to ruby, which uses `0..n` as inclusive, and `0...n` as exclusive http://stackoverflow.com/questions/9690801/difference-betwee... I always remembered it as "the third dot makes it bigger so it pushes the range and the last item falls off". I can't remember where that came from, perhaps related to the poignant guide: http://poignant.guide/book/chapter-3.html#section2 I actually find in pract…
Nitpick, the Hello World comparison is more like: Swift print("Hello, world!") Kotlin fun main(args: Array ) { println("Hello, world!") }