7 ms·

I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the ch

I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." No offense intended ... that's just my quick take.

deleted 10y ago
[deleted]
jkot 10y ago
> If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." I think that is wrong approach. Kotlin has nothing special or innovative, everything was already here. But it is well balanced and industrial strength (something like java). It is simply good workhorse for most tasks. It is excellent replacement for java, that is all.
- reality_czech 10y ago
  Now that JDK8 has made Java more expressive, and Oracle's trolling has come to nothing, I expect Kotlin and Ceylon to fade away. If you want Java, just use it, already.
  - Nullabillity 10y ago
    Java 8 improved things, but it's still far behind the rest. Also, both Kotlin and Ceylon (and Scala and Clojure) would be affected by the Oracle trolling, since they all run on the JVM.
KaneMorgan 10y ago
I actually like that it's informational rather than ideological.
lmm 10y ago
I think that might be what's needed for a really good programming language. If you want a general-purpose language, you probably don't want something unique and envelope-pushing - you just want a language that avoids all the mistakes that are so common, that learns from what's gone before. Like buying a table - you usually don't want a radical table that can do something other tables can't, you just want a good solid table. (I don't think Kotlin is such a language - I think Ceylon might be. I work in Scala at the moment)
- on_and_off 10y ago
  Could you explain why Ceylon fits the bill while Kotlin does not please ?
  - lmm 10y ago
    * Null-handling in Ceylon falls out naturally from union types. Null handling in Kotlin is a hacky special case with a bunch of specific operators. In particular this means it's impossible to write a method in Kotlin that works with both traditional nullable values and Optionals, which will make interop a lot worse as the Java ecosystem adopts Optionals. * Ceylon has actually listened to the lessons of Scala tuples and built theirs the way ours should have been all along (HLists), making them much easier to abstract over. (NB not actually an issue in Scala in practice - you import Shapeless and then everything works the way it should - but it's nicer to have the right thing by default, as will hopefully be the case in Scala 3.x) * Ceylon has higher-kinded type support done right - multiple parameter lists to avoid Scala's unification issues that lead to the use of "type lambdas" (hopefully fixed in Scala 2.12). Kotlin simply doesn't support higher-kinded types; combined with the lack of union types this means magical annotations with bytecode manipulation where suddenly the code you wrote isn't the code that runs, because just like Java that's the only way to do a lot of things in Kotlin. Async is a special case with language-level dedicated support code. Error handling is done solely through unchecked exceptions which is fine for system failures but not a good way to handle "expected" failures like input validation.
- a-saleh 10y ago
  It is interesting that when I considered next language to write a side-project in, I was choosing between Ceylon and Kotlin. In the end I did choose Kotlin. My reasons included: * support in IDEA * focus on java interoperability * nice interop with android but the main thing probably was, that I trust JetBrains that they will support Kotlin in the long term, while I don't think RedHat has any projects depending on the language. So, why would you choose Ceylon?
HannibalLecter 10y ago
>Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." I'd blame the author for this. He's obviously not a salesperson. To me it seems more like he's a coder who found a new-ish language and he's happy that it solves some of his problems that he's encountered. >If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." For me this was pretty open/shut. Kotlin usage appears to rely upon a lot of side projects. I rarely find that beneficial. Too many cooks.
PDoyle 10y ago
There are other articles like that, of course.
- bjterry 10y ago
  I had never heard of Kotlin before, despite reading Hacker News daily and otherwise being generally plugged-in to programming discussion on the Internet. So for many people this will be their first introduction to the language.

deleted 10y ago

[deleted]

jkot 10y ago

> If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." I think that is wrong approach. Kotlin has nothing special or innovative, everything was already here. But it is well balanced and industrial strength (something like java). It is simply good workhorse for most tasks. It is excellent replacement for java, that is all.

reality_czech 10y ago
Now that JDK8 has made Java more expressive, and Oracle's trolling has come to nothing, I expect Kotlin and Ceylon to fade away. If you want Java, just use it, already.
- Nullabillity 10y ago
  Java 8 improved things, but it's still far behind the rest. Also, both Kotlin and Ceylon (and Scala and Clojure) would be affected by the Oracle trolling, since they all run on the JVM.

KaneMorgan 10y ago

I actually like that it's informational rather than ideological.

lmm 10y ago

I think that might be what's needed for a really good programming language. If you want a general-purpose language, you probably don't want something unique and envelope-pushing - you just want a language that avoids all the mistakes that are so common, that learns from what's gone before. Like buying a table - you usually don't want a radical table that can do something other tables can't, you just want a good solid table. (I don't think Kotlin is such a language - I think Ceylon might be. I work in Scala at the moment)

on_and_off 10y ago
Could you explain why Ceylon fits the bill while Kotlin does not please ?
- lmm 10y ago
  * Null-handling in Ceylon falls out naturally from union types. Null handling in Kotlin is a hacky special case with a bunch of specific operators. In particular this means it's impossible to write a method in Kotlin that works with both traditional nullable values and Optionals, which will make interop a lot worse as the Java ecosystem adopts Optionals. * Ceylon has actually listened to the lessons of Scala tuples and built theirs the way ours should have been all along (HLists), making them much easier to abstract over. (NB not actually an issue in Scala in practice - you import Shapeless and then everything works the way it should - but it's nicer to have the right thing by default, as will hopefully be the case in Scala 3.x) * Ceylon has higher-kinded type support done right - multiple parameter lists to avoid Scala's unification issues that lead to the use of "type lambdas" (hopefully fixed in Scala 2.12). Kotlin simply doesn't support higher-kinded types; combined with the lack of union types this means magical annotations with bytecode manipulation where suddenly the code you wrote isn't the code that runs, because just like Java that's the only way to do a lot of things in Kotlin. Async is a special case with language-level dedicated support code. Error handling is done solely through unchecked exceptions which is fine for system failures but not a good way to handle "expected" failures like input validation.
a-saleh 10y ago
It is interesting that when I considered next language to write a side-project in, I was choosing between Ceylon and Kotlin. In the end I did choose Kotlin. My reasons included: * support in IDEA * focus on java interoperability * nice interop with android but the main thing probably was, that I trust JetBrains that they will support Kotlin in the long term, while I don't think RedHat has any projects depending on the language. So, why would you choose Ceylon?

HannibalLecter 10y ago

>Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." I'd blame the author for this. He's obviously not a salesperson. To me it seems more like he's a coder who found a new-ish language and he's happy that it solves some of his problems that he's encountered. >If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." For me this was pretty open/shut. Kotlin usage appears to rely upon a lot of side projects. I rarely find that beneficial. Too many cooks.

PDoyle 10y ago

There are other articles like that, of course.

bjterry 10y ago
I had never heard of Kotlin before, despite reading Hacker News daily and otherwise being generally plugged-in to programming discussion on the Internet. So for many people this will be their first introduction to the language.