Hacker News Reader

Comment by gavinking | Hacker News Reader

> Modules? Meh. The OSGi thing has always struck me as hideously overengineered

And that's _exactly_ why you need modularity built into the ecosystem. OSGi and Maven _are_ hideously overengineered, and they're overengineered because there's no common model built into the language, toolset, and platform.

> I've never understood what problem it's supposed to solve.

Management of versioned dependencies between libraries and components developed by different teams. This is absolutely central to what software engineering is all about.

> Nullable types? The trouble with doing this at the language level is that you can't then treat them as plain old objects.

I don't think you've understood what this is. In Ceylon, null is the singleton instance of the perfectly ordinary class Null. A nullable type is just a union type of form Null|X, for any type X.

> Can I write a method that's polymorphicly nullable?

Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise!

After that, check out signatures of operations like Set.union(), Set.intersection(), coalesce(), compose(), flatten(), curry(), etc, to see a bunch of other things you just can't write in Scala.

> functions and methods? Got them.

Does scala have toplevel functions? I thought they always had to be nested inside some object?

But my real big problem with Scala here is it just doesn't have proper function and tuple types that you can abstract over. Instead you have F, F1, F2, F3 ... F22 and Tuple2, Tuple3, ... Tuple22. That to me is just rubbish.

View on HN

> > Can I write a method that's polymorphicly nullable?

> Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise!

From the docs:

> A nonempty iterable is an iterable object which always produces at least one value. A nonempty iterabe type is written {String+}. Distingushing nonempty streams of values lets us correctly express the type of functions like max():

> {Float+} oneOrMore = .... ;

> {Float*} zeroOrMore = .... ;

> Float maxOfOneOrMore = max(oneOrMore); //never null

> Float? maxOfZeroOrMore = max(zeroOrMore); //might be null

While this is interesting, is it enforced by the compiler? i.e. is the following a runtime, or compile time error?:

    Float maxOfOneOrMore = max(zeroOrMore);

> While this is interesting, is it enforced by the compiler?

Of course. That's the whole point. I really think you've missed the nature of Ceylon. Don't imagine, that just because it has a syntax that looks friendly and harmless and familiar, that it doesn't have a really killer type system under the hood.

> i.e. is the following a runtime, or compile time error?

A compile-time error, of course.

I assume this is the implementation [1](took me a while to find the type to see how the compiler might interpret it).

I read the definition as (ignoring the implementation):

    return a Value or Absent when given an Iterable<Value,Absent> where Value is Comparable and Absent is Null

Correct me if I am wrong, but there doesn't appear to be anything linking the nullability of the return value based on the possible emptiness of the input value. How does the compiler check this constraint (which sounds a lot like a dependent type relation)?

Upon further reading of the Iterable type[2], I have more questions, does "Nothing" satisfy "Null"?

| If not, then it looks to me like passing in a non-empty iterable (Iterable<X,Nothing>) is a type error.

| If so then I would imagine that it becomes harder to enforce the constraint, likely because the return type can still be Null regardless of input restrictions. Does this use extra type inference on the expressions inside the function to do the enforcement, for instance using the "exists" operator to perform type set subtraction between {Value|Null} and {Null} on the true branch. This implies that if I re-write the max function to have a single exit point (`ret = Null; if (exists values.first) { ...; ret = ...; } return ret;`) then I don't get the same guarantees?

Also the fact that Null is referenced by the "exists" operator also implies that it is part of the language specification, and not actually definable in any meaningful way as a user type.

Digging a bit deeper, I was very disappointed to read this snippet [3]:

    Nothing is considered to belong to the module ceylon.language. However, it cannot be defined within the language.

If I read correctly, that means that I cannot implement the same behaviour/enforcement with completely user defined types.

[1]: http://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/...

[2]: http://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/...

[3]: http://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/...

> Correct me if I am wrong, but there doesn't appear to be anything linking the nullability of the return value based on the possible emptiness of the input value.

Sure there is. The second type parameter of Iterable encodes that, see the definition of Iterable.

> does "Nothing" satisfy "Null"?

Of course. Nothing is the bottom type, it satisfies every type.

> If so then I would imagine that it becomes harder to enforce the constraint, likely because the return type can still be Null regardless of input restrictions.

I don't know what you mean by this. An Iterable<X,Nothing> cannot return Null from its first attribute. Check the declaration of Iterable.first.

> Does this use extra type inference on the expressions inside the function to do the enforcement, for instance using the "exists" operator to perform type set subtraction between {Value|Null} and {Null} on the true branch.

Approximately correct. But "exists" is not type subtraction, it's intersection with the class Object. Cool, huh?

> This implies that if I re-write the max function to have a single exit point (`ret = Null; if (exists values.first) { ...; ret = ...; } return ret;`) then I don't get the same guarantees?

I don't follow. You can't rewrite the function to do anything unsound because the compiler won't let you. Our type system is sound.

> Also the fact that Null is referenced by the "exists" operator also implies that it is part of the language specification, and not actually definable in any meaningful way as a user type.

That's not correct. Go and check the definition of Null. It's just a regular class, as advertised. There is no special behavior defined in the language spec. Sure, the exists operator is defined by the language spec to mean "is Object", but that's just trivial syntax sugar.

I guess the problem here is that you're used to languages full of weird special cases and ad hoc behavior. Ceylon is not like that. Ceylon's type system is very simple and these fancy constructs are layered over it as pure syntax sugar. It's a very different approach to other languages. But in the end it's much more satisfying. You'll just need a little mental adjustment to get used to it.

> If I read correctly, that means that I cannot implement the same behaviour/enforcement with completely user defined types.

Wha?! Nothing is the bottom type! The empty set. You want to define your own bottom types? That's not possible (nor desirable) in any language I know of. There's just no reason why you would want to write a class with no instances.

> I don't know what you mean by this. An Iterable<X,Nothing> cannot return Null from its first attribute. Check the declaration of Iterable.first.

This made me sad again[1], but then this made me happier[2] (internalFirst implied it is defined in the compiler, finding all of the pieces that make up the definition was a bit of a pain since it is dispersed across so many files), but I think I didn't fully understand union types (and that Nothing was bottom) when I wrote the grand parents logical conclusions.

    :t Iterable<X,Nothing>.first ==>
       X|Nothing ==>
       X (because union with empty is an identity)

therefore inside max, the variable first will have type X when given an Iterable<X,Nothing>.first. I also see how it cannot be re-written as I proposed because there is no guarantee that Absent will be of type Null.

> That's not correct. Go and check the definition of Null. It's just a regular class, as advertised. There is no special behavior defined in the language spec. Sure, the exists operator is defined by the language spec to mean "is Object", but that's just trivial syntax sugar.

I did check the definition of Null, I was merely pointing out that although it is a user definable type, the language specification does mention its existence here[3] and here[4] which is where I looked to try to find out what the "exists" keyword meant. Specifically:

    in the case of an exists condition, a type whose intersection with Null is not exactly Nothing and whose intersection with Object is not exactly Nothing, or

Later on it says "exists x is equivalent to is Object x, and..." but then why reference Null earlier?

> I guess the problem here is that you're used to languages full of weird special cases and ad hoc behavior.

While I thank you for your time answering my mis-understandings of union types, please do not shoe horn me. My main programming activities are using OCaml and Haskell, both of which have very few ad-hoc language features, if any.

[1]: http://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/...

[2]: https://github.com/ceylon/ceylon.language/blob/master/src/ce...

[3]: http://ceylon-lang.org/documentation/1.0/spec/html_single/#c...

[4]: http://ceylon-lang.org/documentation/1.0/spec/html_single/#a...

> I was merely pointing out that although it is a user definable type, the language specification does mention its existence

Sure, the language spec _mentions_ Null, in order to define the syntax sugar X? and exists x. But that doesn't mean that Null has any special place _in the type system_.

> My main programming activities are using OCaml and Haskell, both of which have very few ad-hoc language features, if any.

OK, great, sorry for making assumptions. In my defense, I just didn't quite understand why you were having such a hard time believing that Ceylon could do things like this without adhoc special cases.

> Management of versioned dependencies between libraries and components developed by different teams. This is absolutely central to what software engineering is all about.

Let me put it this way: I develop in Java (and Scala) using maven, without ever touching OSGi. What is the problem I'm supposed to be having that OSGi would be solving? Because I've never seen it.

> I don't think you've understood what this is. In Ceylon, null is the singleton instance of the perfectly ordinary class Null. A nullable type is just a union type of form Null|X, for any type X.

You're right, the short syntax put me off (it's something I worry about in scala too).

> Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise! > After that, check out signatures of operations like Set.union(), Set.intersection(), coalesce(), compose(), flatten(), curry(), etc, to see a bunch of other things you just can't write in Scala.

I tried to do that, but it looks like you don't have an equivalent to javadoc/scaladoc with the standard library docs publicly available? Either that or google can't find them.

(And I'd still like to hear whether you can do something as general as scalaz's sequence. It's a function that takes F[G[A]] to G[F[A]] for any F and G with suitable typeclasses (Traverse and Applicative, IIRC), so the same function works for Set[Future] or List[Validation] or Vector[MyMonad]) - I don't think you can do that without higher kinded types. And it appears as an extension method on the F[G[A]]).

> Does scala have toplevel functions? I thought they always had to be nested inside some object?

Point, but I find it hard to care. You can stick them in a package object if you really need to emulate one at toplevel.

> But my real big problem with Scala here is it just doesn't have proper function and tuple types that you can abstract over. Instead you have F, F1, F2, F3 ... F22 and Tuple2, Tuple3, ... Tuple22. That to me is just rubbish.

It's a bit rubbish yeah, I agree. Shapeless 2 makes it painless to treat tuples as HLists (using implicit macros - a concept which admittedly would have utterly horrified me six months ago) which means you can work around it in practice.

> using maven

Brrrrr.

> What is the problem I'm supposed to be having that OSGi would be solving? Because I've never seen it.

The problem OSGi solves is having two versions of the same module as part of the same assembly. This is quite possible if you're using third-party libraries that in turn depend on another third-party library.

But I think you're missing something here. Ceylon's module system supplants both OSGi _and_ Maven. It's not just an alternative to OSGi, it's a whole architecture for modularity.

> I tried to do that, but it looks like you don't have an equivalent to javadoc/scaladoc with the standard library docs publicly available?

https://modules.ceylon-lang.org/modules/ceylon.language/1.0....

> I don't think you can do that without higher kinded types.

Correct, we don't have type constructor polymorphism in the official language, and even if we did, we wouldn't use it for this particular problem. Our equivalent APIs are based on (lazy, non-copying) stream-processing.

Now, I do have a working implementation of type constructor polymorphism in a branch of the Ceylon typechecker, but I probably won't merge it because:

1. we don't have a really convincing use for it, and

2. I see it as essentially useless without type constructor argument inference, and Ross and I doubt that a robust and decidable inference algorithm exists for a language with subtyping.

> Point, but I find it hard to care.

Speaking for myself, I don't like unnecessary distracting complexity, even trivial unnecessary distracting complexity.

> Shapeless 2 makes it painless to treat tuples as HLists (using implicit macros - a concept which admittedly would have utterly horrified me six months ago) which means you can work around it in practice

Brrrrr. And then you Scala folks tell the rest of us that Scala is not complex and that we're full of FUD or worse ;-)

FTR, the way Ceylon models this is the way this is the same way it is modeled in mathematics. That is to say, in mathematics, a function is a set of ordered pairs, where the first element of each ordered pair is a tuple. The notion of a tuple is itself defined by recursion. Therefore, in Ceylon, a function type is Callable<AType, ATupleType>, and Tuple is is a class with a recursive definition. Clean, intuitive, abstractable.

Your link is broke. Here it is fixed: https://modules.ceylon-lang.org/modules/ceylon.language/1.0....

Very cool type annotations. As a mostly Java developer, I wish API's had this level of documentation, to have it built into the language and type system is wonderful. As a curiosity, is there any tooling to infer or generate the type annotations for methods? I imagine that would make it easier to learn for those who have never worked with a powerful type system before (as you say, even Java's can be confusing).

Oops, thanks. Appreciated. How I wish hn supported markdown :-/

> FTR, the way Ceylon models this is the way this is the same way it is modeled in mathematics. That is to say, in mathematics, a function is a set of ordered pairs, where the first element of each ordered pair is a tuple. The notion of a tuple is itself defined by recursion. Therefore, in Ceylon, a function type is Callable<AType, ATupleType>, and Tuple is is a class with a recursive definition. Clean, intuitive, abstractable.

Sounds like HList. AIUI performance concerns were why early versions of Scala used the current style of tuple (and alas compatibility requires us to keep using it). Do you avoid instantiating a JVM object for each entry? Are you sacrificing Java compatibility, or is the tradeoff somewhere else?

Having now paid attention to who you are, how do you handle ORM in what I presume is a more immutability-oriented language? Right now I've got a nice reactive spray webapp backing on to a pool of database-access threads (because JDBC still does blocking I/O) which are deliberately as dumb as possible, and it feels like I'm fighting hibernate all the way; hibernate seems to expect sessions to belong to a single thread, objects to belong to a single session, and updates to be performed by mutating an object rather than copying it. It works for now, but it feels like every time I try to do something new (like having an entity with a collection in) something breaks; I'm not saying it's impossible to use hibernate in this kind of environment (I mean, the reason I'm using it at all is that it's still better than the alternatives) but it feels like I'm cutting against the grain and everything is harder than it should be. Perhaps I should be using monads to accumulate operations to be performed in a session, and handing those off to my database threads? (but even that won't work if I want to update an object based on the result of an async call).

Anyway, to get back to the point, does Ceylon have a good story for this problem? Is it going to include a next-gen hibernate replacement? Is there some nice way to do session-in-view and carry a session for a particular web request around even as processing that request happens on several threads? Are you still expecting people to represent database rows as mutable objects? Am I thinking about this all wrong?

> Sounds like HList.

Maybe. I have never heard of HList until today.

> Do you avoid instantiating a JVM object for each entry?

Yes, a tuple, at the VM level is just a wrapped array. Our compiler backend does magic with certain language module types.

> Are you sacrificing Java compatibility, or is the tradeoff somewhere else?

Well, I dunno, a tuple looks like a regular Ceylon list to a Java client, but I don't think that really breaks _compatibility_ as such. Depends how you define "compatible".

> Having now paid attention to who you are, how do you handle ORM in what I presume is a more immutability-oriented language?

No clue. That's something we'll have to think about in 2014.

> hibernate seems to expect sessions to belong to a single thread, objects to belong to a single session, and updates to be performed by mutating an object rather than copying it.

Yes. That's definitely what Hibernate expects. It was never designed for copy-on-write. Because at the end of the day the database contains a bunch of mutable state and Hibernate reflects that in memory. I can't imagine that the solution to this problem is going to be straightforward.

> Anyway, to get back to the point, does Ceylon have a good story for this problem?

Not yet.

> Is it going to include a next-gen hibernate replacement?

I hope so, but I can't promise because I have not spent time thinking about it.

> Well, I dunno, a tuple looks like a regular Ceylon list to a Java client, but I don't think that really breaks _compatibility_ as such. Depends how you define "compatible".

Fair enough. The idea that the object graph I see in scala corresponds 1:1 to the object graph I see in java for the same object is comforting, but I haven't actually tried working without it. (OTOH I have concrete cases where I need existential types for compatibility, much as I wish I didn't)

> The idea that the object graph I see in scala corresponds 1:1 to the object graph I see in java for the same object is comforting

Surely. Not merely comforting, but useful.

But it entails deep compromises in the design of the type system that we're just not willing to make, especially since Ceylon is primarily a cross-platform language, not just a JVM language.

> OTOH I have concrete cases where I need existential types for compatibility, much as I wish I didn't

Right. Whether we'll eventually have to throw in the towel on this one and add use-site variance to Ceylon, purely to get better interop with Java, is a very interesting and bothersome topic.

> Modules? Meh. The OSGi thing has always struck me as hideously overengineered

One of the next versions of Java will ship with a module system. This will likely be good enough and not worth the hassle of having to deal with two competing module systems.

> Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise!

I have looked it, and maybe I'm not seeing it, but it looks like Ceylon is repeating all the things which have been wrong with Comparable in the first place. Given that Ceylon had a clean sheet to start with, I'm surprised that no better solution has been found.

The signature is intimidating and basically combines the non-extensibility of Comparable with the declaration-site boilerplate of Comparable—with none of its benefits.

- If your type was written by someone who didn't care to implement Comparable, bad luck! - If the type has a Comparable implementation which differs from what you need, bad luck, too! - You need the type to be comparable in multiple ways? Again, bad luck!

If any of this use cases came up, it would mean adding a new method which takes an Comparator to all APIs working with Comparable. Leading to more boilerplate and all the pain usually associated with defining Comparators.

Scala has things to complain about, but I think it's hard to claim that they haven't nailed this case down perfectly.

Consider:

  case class Person(firstName: String,
                    lastName: String,
                    age: Int) extends Ordered[Person] {
    def compare(that: Person): Int =
      this.lastName compare that.lastName
  }

  val persons =
    Person("Ann", "Miller", 32) :: Person("Bob", "Smith", 17) ::
    Person("Charlie", "Miller", 71) :: Nil

  val personsSortedByFirstName = persons.sorted 

  // Person doesn't implement Ordered (Comparable)
  // or we want to use a different Ordering?
  val orderByAge = Ordering.by[Person, Int](_.age)
  val personsSortedByAge = persons.sorted(orderByAge)

None of the drawbacks, all of the benefits! Additionally, the signature of the sorted method would be much simpler and more readable in Scala, too:

  def sorted[T : Ordering] = ...

Compare that to:

  shared Element[] sort<Element>({Element*} elements)
      given Element satisfies Comparable<Element> => ...

But I guess messing with Comparable as an upper bound is the best thing one can do without typeclasses. :-/

> Instead you have F, F1, F2, F3 ... F22 and Tuple2, Tuple3, ... Tuple22. That to me is just rubbish.

Looking at what you did with Tuples (basically a linked list), I'm not sure that there is a large difference. Scala's approach seems to be more in line of YAGNI (if you need that 523-Tuple, you should think a bit about your data model) and performance (no pointer chasing, all values are just a method call away).

Anyway, if one wanted tuples-as-linked-lists, one could just use Shapeless' HList library, which has a few benefits over Ceylon's tuples, too, as far as I see:

  val hlist = 1 :: "str" :: 42.31 :: 'sym :: HNil
  val str: String = hlist(1) // Not possible in Ceylon, afaik

> One of the next versions of Java will ship with a module system.

I certainly hope so, since we always planned to replace JBoss Modules with Jigsaw when that becomes possible. But we still don't know if the Jigsaw module system will be made available for all consumers or just for the JDK itself.

> If your type was written by someone who didn't care to implement Comparable, bad luck! - If the type has a Comparable implementation which differs from what you need, bad luck, too! - You need the type to be comparable in multiple ways? Again, bad luck!

Um, you've totally missed the point. Go and have another look.

And sure, since you bring it up, we can certainly add a version of max() that accepts a comparator function. It would be a method of Iterable, probably.

And sorry, but I can't imagine why I would want or need typeclasses to solve that problem. Sure, I could use typeclasses, if I were a solution in search of a problem ;)

> I'm not sure that there is a large difference.

You can't abstract over tuple and function -arity in Scala. So yes, there's a big difference. Look at the definition of compose() in Ceylon.

> and performance (no pointer chasing, all values are just a method call away).

At the VM level, tuples are represented as arrays. So there is no real performance penalty.

> Anyway, if one wanted tuples-as-linked-lists, one could just use Shapeless' HList library, which has a few benefits over Ceylon's tuples, too, as far as I see:

In Ceylon, without any macro library, you can write:

    value tuple = [1, "str", 42.31];
    String str = tuple[1]; //totally possible in Ceylon

Seriously dude, _just try it out_, you're desperately searching for reasons to not like this thing! But it really has cool stuff to offer you. Give it a fair chance!

Sure, _of course_ you're going to find stuff in Scala that you can't do in Ceylon. Scala is one of the most huge and complex and feature-rich languages _ever_! But you'll also find plenty of stuff you can do in Ceylon that you can't do in Scala, if you care to look.

> And sorry, but I can't imagine why I would want or need typeclasses to solve that problem. Sure, I could use typeclasses, if I were a solution in search of a problem ;)

Oh, now I'm a bit confused ... are you really saying that you think that the version with the unreadable and cryptic signature, which is non-extensible in any way and repeats all of Java's mistakes is a good solution (or the best solution available in Ceylon)?

> You can't abstract over tuple and function -arity in Scala. So yes, there's a big difference. Look at the definition of compose() in Ceylon.

I just looked at the documentation of it: compose(g,f)(args)==g(f(args))

Wouldn't this just be ...

  val list = List(1,2,3)
  val f: (List[Int] => Int) = list => list(0)
  val g: (Int => Int) = i => -i
  (g compose f)(list)

... in Scala? What am I missing?

> At the VM level, tuples are represented as arrays. So there is no real performance penalty.

Nice, so this would be more like Shapeless' HArray then!

> In Ceylon, without any macro library, you can write: > value tuple = [1, "str", 42.31]; > String str = tuple[1]; //totally possible in Ceylon

Great, that's nice. I just checked it and you are completely correct of course! Is there also stuff for filtering elements by type, mapping, grouping? I couldn't find much in the code.

> Oh, now I'm a bit confused ... are you really saying that you think that the version with the unreadable and cryptic signature, which is non-extensible in any way and repeats all of Java's mistakes is a good solution (or the best solution available in Ceylon)?

I'm saying that it's cool as hell that the following is all well-typed:

    {Float*} zeroOrMore = ... ;
    {Float+} oneOrMore = ... ;
    Float? maybeNull = max(zeroOrMore);
    Float definitelyNotNull = max(oneOrMore);
    Null definitelyNull = max({});

And that this behavior makes the slightly cryptic signature of max() worthwhile.

Sure, sure, this is not the most general possible signature for max(), since it is only for types with a natural order. We could and should add some form of max() for comparator functions, which we already have for sorting.

P.S. By the way, there are examples of functions where type classes are nice, for example sum(), where the type class lets you correctly express the sum of zero elements. (But max() is not one of these functions.) So in fact, we would definitely like to experiment with type classes in a future version of Ceylon, especially since the idea probably meshes very nicely with our reified generics.

> What am I missing?

You're missing that the definition of compose() is abstracted over the arity of the second argument function in Ceylon. It's _one_ function, not a different method defined for each Fi type. Which means that I can write similarly-abstracted functions that use compose().

> Is there also stuff for filtering elements by type, mapping, grouping?

Sure. Tuple is a subtype of List, which is a subtype of Iterable, which defines all stream-processing functions. FTR, an [Integer,String,Float] is a List<Integer|String|Float>.

> 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!

> But aren't you pretty much focusing on implementation details here?

No, not at all, I'm talking about the ability to abstract over things. Can I write a single higher-order function that operates over functions with any -arity? In most languages, no. In Ceylon, yes.

> 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!

In general, the quality of discussion here is better than in other places.

> 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

Sure, but when you have nasty and idiotic twitter stuff poisoning the air, it's hard to expect people to adopt a fair-minded and technical approach to the topic. People should just get off twitter. It's a community-wrecker. There's almost nothing you can say on twitter that rises above the level of insulting.

Reply on news.ycombinator.com