Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 05 20:47
    ericdriggs commented #7454
  • Feb 11 03:56
    dependabot[bot] labeled #7472
  • Feb 11 03:56
    dependabot[bot] opened #7472
  • Feb 11 03:56

    dependabot[bot] on maven

    Bump json-smart from 1.3.1 to 1… (compare)

  • Feb 11 03:55
    dependabot[bot] labeled #135
  • Feb 11 03:55
    dependabot[bot] opened #135
  • Feb 11 03:55

    dependabot[bot] on maven

    Bump json-smart from 1.1.1 to 1… (compare)

  • Dec 08 2021 10:05
    supersache opened #7471
  • Oct 01 2021 12:51
    l7rf1i82 commented #7464
  • Oct 01 2021 12:51
    l7rf1i82 commented #7464
  • Oct 01 2021 12:49
    l7rf1i82 commented #7464
  • Sep 30 2021 08:21
    l7rf1i82 closed #528
  • Sep 30 2021 08:21
    l7rf1i82 commented #528
  • Sep 29 2021 08:05
    l7rf1i82 opened #528
  • Sep 10 2021 06:34
    codeMonkey404 opened #671
  • Jun 19 2021 01:40
    kingjon3377 opened #527
  • Jun 19 2021 01:35
    kingjon3377 opened #526
  • Jun 04 2021 01:23

    dependabot[bot] on maven

    (compare)

  • Jun 04 2021 01:23
    dependabot[bot] closed #7456
  • Jun 04 2021 01:23
    dependabot[bot] commented #7456
Wojciech Potiopa
@Voiteh
I looked in all the commits of master branch and they seems all fine we need to decide what else would we want to have in 1.4.0
There are few other issues labeled with Breaking change
https://github.com/eclipse/ceylon/labels/breaking%20change I don't see in most of them the agreement that we wan't them to be included. Only #7409 this I see as includable.
momomo
@momomo
@Voiteh At this point I would not be too concerned with breaking changes. Is that more important than giving it a fresh start, even if that might break backwards compatibility for the few that have projects depending on it? The alternative is they might never have an update and would still continue to live with the version they are running now.
If mistakes were made in the language before, like Gavin has hinted, this might be an opputonity to fix them. I also don't know why so fuck focus was put into making ceylon code compile to javascript. i personally would not consider using it or any other language for that purpose.
Wojciech Potiopa
@Voiteh
@momomo We have minor version change so it would be good to include all the breaking changes into the release, that we agree on. Then in 1.4.x fixes we would just improve what would need to be, as bugs naturally occures. We are trying to give it a fresh start. As for JS, this wild beast need to be tamed somehow. I work in my daily job with Typescript and it's quirky . Kotlin - limited typing. Dart - didn't checked.
MikhailMalyutin
@MikhailMalyutin
@momomo Absolutely agree. It is almost impossible to force frontent javascript developer to use other language than javascript or at least Typescript. We use ceylon in production but in JVM backend only. Modern JS frontend is a very unstable thing, a lot of JS frameworks is created and died. Compiling to JS must be optional expererimental feature, most developers will never use it. But for JVM and backend development ceylon language was very good.
momomo
@momomo
Yes, it must have been an immense job and waste of time working on that. The best thing this project could do is to strip it bare, to a minimum to maintain and let community then build libraries for it. This is the best for maintainance later. Everything that is not essential I would recommend to just hit delete. If you don't, you will always have to maintain those parts for refactoring, always run those tests, always go into those code pieces that are irrelevant and just update minor things to make them continue to compile and test.
It is a time waster. I have lots of code, even for things i've rewritten in new better ways, and old projects. When my code base change, I still always have to go in and ensure those libraries and project doesn't get destroyed. So even when my code is improving, changing it now, i have to take into consideration all those old projects and libraries that I might or might not need in the future. But I keep thinking I might return to those projects but they do cost additional time.
momomo
@momomo
And i would do much better if I just was able to discard them.
Wojciech Potiopa
@Voiteh
Let's concentrate on this release first. Then we can think what we want to remove etc. Maybe we could find someone to maintain JS part.
Wojciech Potiopa
@Voiteh
Someone needs to review what is essential for release on IDE's part and on SDK. I can give more details if anyone interested
momomo
@momomo

I found this thread with Gavin commenting:

https://news.ycombinator.com/item?id=8437363

He traded off features in ceylon because they could not be ported to JS. What a mistake. Probably the biggest thing is to even having that as a priority or on the list at all.
Roland Tepp
@luolong
I think if we ever should target web front-end, it should be WebAssembly rather than compiling to JavaScript.
But Wojciech is right. Lets get this release out first and worry about future later.
Casey Dahlin
@sadmac7000
I was always more frustrated by features that were missing because of Java compatibility than ones that were missing for JavaScript compatibility.
David Festal
@davidfestal
I assume future direction would be basing Ceylon Backend in graalvm / truffle, which might give Java interop for free as well as interop with other languages such as JavaScript.
Roland Tepp
@luolong
Yes. Seconded!
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
Graal cannot be used in OpenJ9 and non-OpenJDK JVMs
Any way a common backend which can target Graal and ECJ would be a better choice
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
Maybe you can fork the Kotlin 1.4+ backend and adapt it for Ceylon where you only maintain the front end. Maybe they might accommodate some Ceylon specifics also
The alternative may be used, Scala TASTy
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
kiti_Nomad
@Kiti-Nomad
GraalVM
很多年前,出现过一个类似的虚拟机,parrot。他具有和GraalVM类似的功能
不过它运行的基本上都是动态的脚本语言
Tako Schotanus
@quintesse

Resurrecting a past discussion for a bit, but I actually agree, to some point at least, with what @momomo said back in April:

The best thing this project could do is to strip it bare, to a minimum to maintain

One of the last suggestions I made for the project was that perhaps we had tried to bite of more than we could chew with the CMR, the Ceylon Module Resolver. Yes it could have been really nice if it had all worked out, but IMO it's one of the things that a) sucked up a lot of our time b) was unnecessarily complex (and trying to simplify it would take precious resources away from other important issues) and c) it made interop with Java way more difficult than it needed to be.

My suggestion was to forget about backwards compatibility, create a version 2.0 and mercilessly rip out the CMR part of Ceylon (and I'm saying that as the one who has done the most work on it ;-) ) and just use the native solutions of each platform (Maven artifacts, NPMs, etc). We'd just keep the language, which after all is the nicest part of Ceylon by far.

Now, that didn't mean I wanted to get rid of Ceylon being able to obtain dependencies for compilation/execution automatically, but I was thinking of something much more simple, perhaps a frontend that would make sure all dependencies got downloaded and would be available locally. (In the way JBang https://jbang.dev/ is doing it right now for Java for example).

Anyway, sorry for being late to the party, just wanted to chime in a for a bit ;-)

David Festal
@davidfestal
Hi @quintesse ! Nice to see you here ! I was recently thinking it would be great to have a way to make modules be docker images. And have the ceylon module system be container-native ... But maybe it's just an unfeasible dream.
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.