Comment by gavinking | Hacker News Reader

Comment by gavinking | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com