4 ms·

> "Slightly cleaned-up Java with a bit of syntax sugar" And C is a "slightly cleaned-up assemble with a bit of syntax sugar". I think kotlin has a lot of featu

• lmm 10y ago
  > And C is a "slightly cleaned-up assemble with a bit of syntax sugar". Going from machine-specific assembly to crossplatform C was a huge killer feature at the time. > I am curious why do you say Scala and Ceylon have killer features, what are those features that Kotlin doesn't have? Higher-kinded types and/or union types. Those are the real game-changers, even if they don't look like it in simple examples. More concretely, the real value proposition for moving from Java to Scala or Ceylon is "replace all your magic annotation/XML-based proxying/bytecode manipulation with ordinary library functions that follow the ordinary rules of the language".
  • mike_hearn 10y ago
    The term "killer app" refers to an app so amazing, people buy your platform just to use that one app. A killer language feature would be a feature so amazing, people use your language just to get that one feature irregardless of the rest. One property of a killer app is that people tend to know it when they see it. You don't normally need to educate people as to why they want your app, they already know they do. Kotlin does have a whole bunch of features and particularly DSL features (with more added in 1.1) to allow usage of "ordinary functions" in places where previously you might have used annotations or bytecode generation. But in practice the market doesn't seem to value these things all that highly, perhaps because most of the time, people are writing ordinary code that doesn't benefit much from them. It's tough to claim something is a killer feature when people aren't saying "We use Ceylon because it has HKTs" (by 'people' here I mean, more than one or two bloggers). If you look at any discussion of Kotlin then people do tend to identify killer features for them, but they're not normally type system features, they're more like interop or tooling related features. Ceylon and Scala teams recognise the importance of these things too, but the relative prioritisations have been different, so it isn't surprising that the results appeal to different market segments.
    • lmm 10y ago
      > The term "killer app" refers to an app so amazing, people buy your platform just to use that one app. A killer language feature would be a feature so amazing, people use your language just to get that one feature irregardless of the rest. Yep. That's how I feel about HKT. I'm never going to program in a language without HKT again if I can possibly help it, and I'll put up with a lot of nonsense from Scala (like the IDE situation being a choice between the one that locks up for seconds at a time and the one that puts spurious error highlights on all your code) if the alternative is not having HKT. > One property of a killer app is that people tend to know it when they see it. You don't normally need to educate people as to why they want your app, they already know they do. Eh maybe. The quote about "faster horses" comes to mind. What everyone wants is a language that makes it easy to say what you mean and have it come out correct. But it's hard to know what kind of language facilities would help you do that until you've worked with them - and not just done some small examples but written a real line-of-business app while making a real effort to work with the grain of what those features give you.
      • mike_hearn 10y ago
        But is raw HKT enough or is what you really want libraries like scalaz? I think people can imagine new type system features more easily than you think. But this stuff has been studied: http://sns.cs.princeton.edu/docs/asr-oopsla13.pdf http://sns.cs.princeton.edu/docs/asr-oopsla13.pdf Programmers don't tend to value new type system features that highly. I don't think it's to do with ignorance. I'm well aware of Haskell's newtype and would like it on the JVM/with Kotlin, as I think it's easier to write correct software when you have that feature. but I'm not going to pick a language based only on that. The incremental benefit just isn't all that large. Access to a giant number of quality libraries, though, that is in fact a killer feature. I'll use a language just to get access to libraries. Like how people use Scala just because of Spark or Java because of Hadoop or because they want to write a Minecraft mod.
        • lmm 10y ago
          ScalaZ is trivial once you have the concepts, I can and have reimplemented all the parts of it I need (repeatedly in fact). The same goes for Shapeless - it's good to have a standard definition of these things, but there's really not that much to them, they're actually very small libraries. I need HKT because now that I have HKT in my mental toolkit I'll think of solutions to my requirements in terms of them, and it's really painful to have to manually expand out if the language doesn't let me write down the description I have.
  • jorgemf 10y ago
    > Higher-kinded I made small research and I see higher-kinded types very similar to generics, what is the main difference? > union types You have Multiple Inheritance in kotlin, which does more or less the same. > the real value proposition for moving from Java to Scala or Ceylon is "replace all your magic annotation/XML-based proxying/bytecode manipulation with ordinary library functions that follow the ordinary rules of the language" I don't get this. Xml in java code? Ceylon and Scala I think they compile to bytecode too. Sorry, it doesn't make any sense to me the sentence. Can you explain it?
    • lmm 10y ago
      > I made small research and I see higher-kinded types very similar to generics, what is the main difference? Higher-kinded types mean you can have type parameters that are themselves parameterized. E.g. in Java (or Kotlin) you can do interface MyType<T> { T something(); } and you can have a MyType<List<String>> where something() returns List<String>. But you can't do interface MyType<T<_>> { T<String> something(); T<Integer> somethingElse(); } and have a MyType<List> where something() returns List<String> and somethingElse() returns List<Integer>. > You have Multiple Inheritance in kotlin, which does more or less the same. Only if you control the classes involved, and most of the time you don't - I can't see any way to create a union where one of the types is from an external library, not even by making them both subtypes of a common interface. (Particularly frustrating since Kotlin supports extension methods, which have all the same complexity for the reader, but as far as I can see you can add a method to a library type but you can't add an interface onto it). (Also Ceylon's native union types are nicer than subtypes). > I don't get this. Xml in java code? Ceylon and Scala I think they compile to bytecode too. What I mean is, real-world Java codebases end up full of proxying/bytecode-manipulation/reflection controlled by annotations and/or (in older codebases) XML. E.g. Spring/Guice, Hibernate/JPA, Jersey, Jackson, Quasar... . It's worth saying that this happens for a good reason: Java isn't expressive enough to practically express functionality that people need, and thus they resort to using these techniques instead (the realistic alternatives are callback hell, dropped transactions, copy-pasted code...). But HKT (and related/similar functionality) give you enough expressiveness to replace these things with plain old code.