Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 13 14:32
    dependabot[bot] commented #7467
  • Oct 13 14:32
    dependabot[bot] commented #7468
  • Oct 13 14:32

    dependabot[bot] on maven

    (compare)

  • Oct 13 14:31
    jvasileff closed #7467
  • Oct 13 14:31
    jvasileff labeled #7467
  • Oct 13 14:31
    jvasileff closed #7468
  • Oct 13 14:31
    jvasileff labeled #7468
  • Oct 13 14:26

    dependabot[bot] on maven

    (compare)

  • Oct 13 10:14
    dependabot[bot] labeled #85
  • Oct 13 10:14
    dependabot[bot] opened #85
  • Oct 13 10:14

    dependabot[bot] on maven

    Bump junit from 4.10 to 4.13.1 … (compare)

  • Oct 13 09:04
    dependabot[bot] labeled #7468
  • Oct 13 09:04
    dependabot[bot] opened #7468
  • Oct 13 09:04

    dependabot[bot] on maven

    Bump junit from 4.10 to 4.13.1 … (compare)

  • Oct 13 07:47
    dependabot[bot] labeled #7467
  • Oct 13 07:47
    dependabot[bot] opened #7467
  • Oct 13 07:47

    dependabot[bot] on maven

    Bump junit from 4.10 to 4.13.1 … (compare)

  • Oct 12 21:13
    dependabot[bot] labeled #134
  • Oct 12 21:13
    dependabot[bot] opened #134
  • Oct 12 21:13

    dependabot[bot] on maven

    Bump junit from 4.10 to 4.13.1 … (compare)

Luke deGruchy
@lukedegruchy
I’ve been lurking/watching but not participating. What does this mean for the semantics of shared, exposing functions/etc within a package, Herd, etc? Does this mean the language machinery remains but there’s no such thing as Ceylon native modules anymore? I’m interested in knowing more
Oh, and, what does it mean for IDE support?
Oh, and FWIW I have zero issues with breaking backward compatibility
And, FWIW, I have zero issues with breaking backward comcompatibility
Sorry for the double-post
Tako Schotanus
@quintesse
Hehe, guys, this were just ideas of mine. I don't represent any official plans. Just me and my opinions :-)
I didn't even really think things through, just believing that when you go for KISS, keep things as simple as possible and create components that do one thing and do it well you get something that's very "composable".
Tako Schotanus
@quintesse
To me having our own packaging system, and by extension our own online repository (Herd), just pushed us further away from the Java and JS/NPM/Node ecosystems we'd have to depend on for people to be able to actually use us in real situations where you'll be running legacy code and using legacy frameworks. Or not so legacy but you're just forced to cooperate with others that just don't want to drink the Ceylon-Aid.
Another problem is that, if wanting to use just a single Ceylon source file in your existing Java/JS project means you have to "ceylonify" the entire project, you'll already have lost 99% of the devs out there.
So yes, I think that our module system, regardless of how innovative and great/cool it was, was actually more a ball and chain that we had to drag along with us and which made us less competitive.
Tako Schotanus
@quintesse
It might be (not thought it through though) that modules as a language feature are still a great idea. I just think that the way they are done now conflate code design with build practises. The fact that we had version numbers in there, combined with supporting Maven and NPM, which have completely different version systems would always have caused major trouble IMO. Can you work/design around that? Sure, but then you're leaving the people in the cold that just simple and step by step want to introduce Ceylon into their existing projects. If you only pander to the people that create new projects, you'll again have lost a large part of potential devs.
Tako Schotanus
@quintesse
This might all sound extreme. But I honestly think that the only way Ceylon (as a language, not the entire ecosystem) can be saved is when a person can take an existing project, change one .java or .js file to .ceylon and make a simple update to their pom.xml/build.gradle/package.json file and have it work. The Ceylon file would get compiled as part of their normal, existing, build process and it would just run.
(And this doesn't mean that you can't have cross-platform code anymore. If enough people want to maintain and extend the cross platform modules they can still do so. But the code would be served by maven central/jcenter and npm etc, not by the Herd.)
Tako Schotanus
@quintesse
Hi @davidfestal ! Long time no see :-) Who knows, you're idea might work. But I would see it as a separate step in a build pipeline or something. To me a language should define the code, not how it finally gets packaged and run. Class files, jars, artifacts, containers, they are all just ways of packaging and archiving the code. Let the compiler do it's most basic job source->code and let other tools do the rest. IMO that way you are open to the largest range of possibilities.
David Festal
@davidfestal
+1 !
John Vasileff
@jvasileff
@quintesse you speak the truth. And I totally agree - having the module system be a separate and optional component that competes with maven instead of replacing it was one of my first suggestions after learning about Ceylon.
The irony is that Ceylon is a language that touts the virtues of software modularity, yet the language itself is presented as an inseparable behemoth. To use it you must buy into its entire (yet incomplete) ecosystem and infrastructure.
The only hope for a language like Ceylon (i.e. a language not backed by Apple, Google, or Microsoft), is to have a small core that plugs nicely into existing tools and ecosystems.
Tako Schotanus
@quintesse
YEah definitely
It did take me a long while to get to this point, but I do think it would be best. A small agile core that doesn't impose its own way of doing things but adapts to the platform it's used on.
Still, even removing stuff is no small task
Enrique Zamudio
@chochos
I totally agree with Tako. We discussed this when we were working on the project. I also still believe it would be the best way to foster adoption, by lowering the entry barrier: just add a Ceylon file to your project, and a plugin to your build system, and you're good to go. It would allow people to give it a try, and very gradually start increasing the usage in an existing project.
Roland Tepp
@luolong
I think the strongest (and I believe only) real opponent of relaxing the module system's grip on Ceylon language was Gavin. I myself am very much in agreement that the way things were, that module system tried too hard to replace existing modularity practices and ended up getting in the way of developers.
In any case, when we are talking about making Ceylon modules an optional part of Ceylon the languyage, what would it look like? what would be the role of module.ceylon files? would they go away entirely?
Tako Schotanus
@quintesse
That's something I haven't thought through completely to be honest. They could possibly still exist as a language visibility feature, one that would not necessarily be enforced by the underlying classloader / module system. But I haven't analyzed yet if that's something that can be done / worth doing.
I just know that right now there already exists a "flat" classloader that would just ignore any modularity restrictions imposed by the language. So technically it is definitely possible to run Ceylon without a modular classloader.
Tako Schotanus
@quintesse
(Btw, just out of curiosity I created a branch where I ripped out everything related to CMR to see how much code would be affected and it's quite a lot. I need to find more time to take a closer look)
Enrique Zamudio
@chochos
maybe instead of ripping it out completely, a replacement CMR can be made that simply delegates to Java's new module system... module.ceylon could still be used to define the module, but package it like a regular java module, adding the required ceylon dependencies...
Tako Schotanus
@quintesse
It's indeed something that could be considered. But I wonder if that would get us closer to the desired simplicity (that some of us seem to want).
I'm assuming for example that Java modules won't work on Android, so we'd have to have two systems again. Given that the one for Android would also work on the JVM (but without any module visibility/access guarantees) it would probably just be easier to focus on that one.
For me the interesting part, like @luolong also mentioned, would be to figure out if we'd also want to get rid of the whole idea of modules completely, even at the language level, or if that's still a valuable feature. (In the latter case the Java modules would still be a viable option in the future)
Enrique Zamudio
@chochos
I'd get rid of them completely and use the standard java module system. It also facilitates integration with build systems like maven or gradle
Tako Schotanus
@quintesse
Ok, let me try to understand that better, what would the Java modules be used for then? Without modules in the language wouldn't plain class files be sufficient?
Enrique Zamudio
@chochos
yes
fill0llif
@fill0llif
I really like ceylon module as a user, and I understand it has brought unnecessary complexity into the whole language, I think it's ok ripping it off its module system, but I guess java module system is going to be important in the near future, how would you address this development?
Roland Tepp
@luolong
to be honest, I too liked the language module system, but perhaps the whole machinery of the module resolution was a bit overboard.
I would not mind treating module.ceylon as a build time module metadata container and ignore the module resolution bits.
For java, it could compile to Java modules. For OSGi it could compile to OSGI metadata, for node/js, the relevant bits would be compiled into package.json or something similar.
Leave the module resolution (if any) be handled by the runtime platform&container if wants to.
Would that bring enough simplification while keeping the “good parts”?
Tako Schotanus
@quintesse
No idea, I guess that's something that would have to be figured out :-)
David Festal
@davidfestal
I also prefer the idea of keeping the basics of module declarations in the language, but with the requirement to provide the module resolution by external tools, or have an option to completely disable it.
modules as they are declared today could also be useful to have an integration with containers: having modules be produced as container images.
So having a way, in the language, to declare module dependencies, and module boundaries, seems still very useful to me as long as it is seen as modularity guidelines, and is not required to match a too-limited number of module implementations.
John Vasileff
@jvasileff
I believe that to have first class classpath support, the first step would be to totally remove everything having to do with modules and module resolution. This would involve spec changes to deal with the lack of structure. Anything short of complete removal of the existing module system would compromise classpath support. I agree with Tako that this would be a lot of work. Then, as step two, introduce support for jpms including compile time checking for visibility restrictions, and for convenience, a grapes style maven module resolver for scripts and lightweight projects in which you don't want to use gradle/ant/mvn.
Step two would be fairly straight forward, and, as with Java, wouldn't fundamentally alter the programming language
As for complex osgi style runtime classloading, I think that could be left for existing third party tools for the few people who find it useful. And, frankly, osgi not the direction the Java ecosystem is heading - the trend is a 180 from that, where linking is done at compile time with graal native-image
Roland Tepp
@luolong

I agree with ditching runtime aspects of module system. I would keep the compile time (visibility restrictions) of the module system – I believe they offer a very useful design constrint that makes you think hard about your dependencies.

As to how we get to that state … maybe we do need to rip out everything before adding the compile time stuff back in. I don’t really know how, but the intuition says that rip out everything and then re+add only relevant bits sounds like a better and more straight forward plan.

Joost Morsink
@joost-morsink
Good to see Ceylon reviving again, if only the intention. Is there any actual funding for the work to be done, or is this going to be a non-paying community effort?
Tako Schotanus
@quintesse
@joost-morsink I'm afraid none of us are funded. I guess the only way that would ever happen again is when Ceylon gets a much larger community and is recognized outside its small circle of devs and users.