> I'm saying that it's cool as hell that the following is all well-typed: Ah ok, that's certainly nice. There is a library in Scala though which let's you swit

> I'm saying that it's cool as hell that the following is all well-typed: Ah ok, that's certainly nice. There is a library in Scala though which let's you switch APIs from T to Option[T] to Try[T] to Future[T] to ... with a single import. But I think in a language were nulls are the primary means to encode a missing value, this possibility is nice and makes a lot of sense! (Although I really think it should be investigated how the signatures can be simplified. If you think it's so great (given the constraints Ceylon has, imho yes, it is) it probably makes sense to support this by default and not by making the library author do extra work.) > You're missing that the definition of compose() is abstracted over the arity of the second argument function in Ceylon. But aren't you pretty much focusing on implementation details here? If I said “Tuples in Ceylon ... what a mess! Look at this type signature: Tuple<Integer|String, Integer, Tuple<Integer|String, String, Tuple<Integer, Integer, Empty>>> ” I think you should rightfully call me out on that this is nothing which matters to a user and a developer will pretty much ever see [Integer, String, Integer] I think it's kind of the same way for the current Tuple encoding in Scala. One could switch to a better representation and most users probably wouldn't even notice. And just for the record: I think you have made very convincing points here that Tuples can be handled and I think moving Scala into the direction of HLists/HArrays makes a lot of sense! Anyway, I have to say that this discussion has been downright pleasant and some of my reservations towards Ceylon, which were fueled by seeing you in some conversations/talks (both in the Hibernate era and in early Ceylon) which left the impression of “wow, what a jerk” (sorry :-/) to me have been resolved with this discussion. Again, this discussion was very nice, resulted in learning a few new and interesting things and I'm taking nothing but good impressions with me! I think if both communities took more care to explain the different reasoning, design decisions and philosophies behind the languages when giving talks or on conferences in the future (I saw a few early Ceylon presentations in which I felt Scala's design decisions were unnecessarily misrepresented, but of course the same applies to any Scala presentation if the subject would touch Ceylon, too), this could be a huge win-win situation for both communities. I think the real competitor of Ceylon/Scala is not Scala/Ceylon, but the sad status quo of our industry. If the communities combined their voices to get the message out that there are modern languages and better development approaches existing today, I think this would benefit everyone. While I'm probably too spoilt by Scala to enjoy programming in Ceylon, I think that especially compared to its current direct competitor in mindshare, Ceylon has a lot of good ideas and tries very hard to give its users the best experience possible, given the constraints you have given yourself when designing the language. With Ceylon, tons of people will learn about the usefulness of union/intersection types in a real-world setting. This benefits our profession as a whole and would certainly not be the case if the language was just some prettified Java (ok, ok, let's not get me started on Ceylon's syntax :-D). Have a nice day!