3 ms·

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

> 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

gavinking 13y ago
> 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.
- frowaway001 13y ago
  > 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.

gavinking 13y ago

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

frowaway001 13y ago
> 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.