Kotlin or Swift? (isn't a flame war, its about opinion)

[dalewking]

@DonWills

Wow! Are you trying to single-handidly make me decide against Kotlin?

No, I want you to realize that your criticisms are unfounded and your team would get great benefits from Kotlin. I do however want to prevent you from influencing Kotlin design to regress back to antiquated, bad programming practices from the ancient days of programming.

@DonWills

Your arrogance is amazing.

You have a different definition of the word arrogance. Stating facts that disagree with your view of reality does not mean I am arrogant.

@DonWills

I don’t use IDEA

Heaven help you there. They do try to support Eclipse but Eclipse sucks so badly that it is probably very difficult. I used Eclipse for years and as I said would never go back to it.

@DonWills

Nope. My statement is true. I only declare ONE METHOD in Java - void abc(String… x) { } - and call sites in Java can use either multiple Strings or an array of Strings. It’s been that way in Java for many releases.

Your statement was that Kotlin is bad because it did “not allow these method two overloads for the same method: fun abc(vararg x: String) and fun abc(x: Array).”. You cannot declare both methods on the same object in Kotlin or Java.

But apparently you were trying to say that you couldn’t pass an array to a vararg function in Kotlin, which is also false. Kotlin jsut requires that you be explicit using the spread operator:

fun abc(vararg x: String) {}

fun foo()
{
    val array = arrayOf("1", "2", "3")
    
    abc("1", "2", "3")
    abc(*array)
    abc("0", *array, "4")
}

The reason you have to be explicit and use the spread operator is to support cases that do not work in Java without a lot of extra work. The last call demonstrates one of those cases that is not possible in Java without manually building another array. Another such case is abc(Object… x) in Java.

I have written more about those cases and the spread operator in another thread so don’t want to repeat all of that here: Pass-through varargs - #9 by dalewking

@DonWills

Your suggestion that because the designers of Swift threw away old ugly for loops (your words), that it was a good thing and justifies that Kotlin it did too

The reason for pointing it out was more to do with the notion that you are implying that the lack of C for loops might cause Kotlin to die is silly. Even Swift realized that they are a bad thing and unnecessary.

@DonWills

Swift also tossed out ++ and --. Why didn’t Kotlin toss them out too?

I would have no problem if they deprecated them.

@DonWills

Functional Programming is simply a fetish created by ivory tower philosophers and taught to innocent minds in college. It is almost completely divorced from the real world. FP might be slightly useful for certain algorithms in multi-threaded programs, but is much more of a hindrance than benefit for writing the type of business applications that are the bread and butter of Java and C#.

Wow! So you malign a programming practice that you obviously do not understand and you call me arrogant!?

This nonsensical statement is pretty much enough to cause your opinions to be totally discounted. Sure functional programming is not part of most Java programming since you couldn’t actually do it until Java 8. C# programmers are by and large ex-Java programmers or ex-C++ programmers so did not really pick up on FP even though C# supports it (but does not actively promote it like Kotlin does).

Contrary to your statement FP isn’t really taught in college. Some academics got it and only recently has the general public caught on to why it is better. Meanwhile we have decades of non-FP practitioners who think things like the C for loop is a good idea.

But the idea that any program will not benefit from FP concepts is ludicrous. The primary reason that Kotlin is getting so popular on Android is exactly because of its functional programming support since Java 8 wasn’t supported on Android. The fact that you don’t get FP doesn’t mean that it is a bad thing.

@DonWills

I grok programming languages. I’ve written compilers, interpreters, was a member of an ANSI standardization committee for a programming language, and I’ve programmed in and I understand more than a dozen programming languages.

Other than being on a standardization committe, the same applies here. I have used many programming languages (e.g. Fortran, Cobol, RPG, Basic, Assembly, C, Modula, C++, Lisp, Prolog, Java, Ruby, Objective-C, C#, Kotlin, Groovy, and enough Javascript to despise it). I have seen enough to know that some programming paradigms are better than others and it is good to have languages that favor the better ones.

@DonWills

That’s what I really fear the most in Kotlin - that Kotlin will fail for whatever reason

Not showing any signs of that. And the things you have mentioned are certainly not reasons it would fail and some like me believe that the things you criticize it for throwing out is part of why it is succeeding.

@DonWills

The customer is always right is not a throwaway concept - it is everything. And I am a potential customer.

So if the customer says they want raw pointer access and manual memory allocation and freeiing like we had in C/C++, is that customer right? What if a customer wants checked exceptions which you already acknowledged was a a bad thing and it is good for Kotlin to remove? Should they include every thing any customer would want?

No we have moved on from those antiquated practices and know that leaving them out of the language is a good thing. Similarly modern programming languages recognize that FP is a good thing. Kotlin is pragmatic in that it doesn’t force you to use FP like Erlang does, but it also is not going to go out of its way to help you avoid FP. A large number of programmers think that is a good thing, not something that will kill Kotlin.