Eclipse Ceylon(projects.eclipse.org)
projects.eclipse.org
Eclipse Ceylon
https://projects.eclipse.org/proposals/eclipse-ceylon
38 comments
I just posted a link comparing Kotlin and Ceylon in more detail. Don't know the state of Celyon as of now, 1 1/2 years later..
> The language felt very intuitive to me.
Which languages do you typically use now? Are you a Java dev? Do you already use Eclipse daily?
Which languages do you typically use now? Are you a Java dev? Do you already use Eclipse daily?
So linking to this page doesn't really give you a feel for the language. http://try.ceylon-lang.org/# gives you examples and a sandbox to play with the language.
The originally linked page does have a very good explanation of the language though.
It just needs far more code examples.
It just needs far more code examples.
I don't want to be mean, but wasn't this initially developed by Red Hat and wasn't it basically abandoned by Red Hat recently? I remember reading something about it.
The language seems interesting but a niche language without a backer or major hype doesn't seem like a solid long term bet.
The language seems interesting but a niche language without a backer or major hype doesn't seem like a solid long term bet.
Yes, the title originally was Eclipse foundation accepts RH's donation of Ceylon, and folks have expressed elsewhere the opinion that donating code to Eclipse could be seen as a ritual software burial.
I think the original software burial foundation is Apache, not Eclipse. But certainly very few Eclipse projects are "thought leaders"..
Oh, that's interesting to know - I've been following Ceylon for a while, trying to figure out whether it was getting any adoption. My theory is that people don't seem that interested because it's another JVM language, and there are already a number of them, filling different niches - Scala for "more powerful type system", Clojure is the lisp, etc...
I agree there are different motivations for alt-jvm languages, and I guess Kotlin should be mentioned as well. Many developers are in for the (supposedly) greater language expressiveness or productivity; personally I'd be more interested in a language specifically targeting the case to slowly migrate away from the JVM and JIT compilation into machine code and AOT (ARM and x86).
I won't speak for others, but I discarded the idea of ever using Ceylon when I learned that Gavin King was involved with it. I won't go into why--a simple Google search will easily allow people to make up their own minds--but suffice it to say that I don't find him professional enough to rely on a project that he leads. For something like a language, where you have to invest a significant amount of your own time and energy into using it, the people behind the language and the community around it are hugely important considerations.
This kind of throwaway comment never works.
Whatever is so bad about him, I don't see it on a google search. Not being snarky, I just literally don't see it. Every link for a few pages looks neutral.
Guessing here: do you just really really really (really really really...) hate hibernate?
Whatever is so bad about him, I don't see it on a google search. Not being snarky, I just literally don't see it. Every link for a few pages looks neutral.
Guessing here: do you just really really really (really really really...) hate hibernate?
I actually mostly like Hibernate, except for the very few times where I hate it with the burning fire of a thousand suns. But that's to be expected when a tool tries to go too far towards the magic end of the spectrum. But why I don't think he's professional is all the discussion/listserv threads that I've read where he's abrasive and disrespectful to any perspective that's different from his.
His actions speak against your words.
Whatever you think of him, the bottom line is that he created a whole language + library + IDE plug-ins from scratch over a few years with a small team.
Ceylon will probably not go anywhere now that Kotlin has taken over, but that doesn't take away anything from the talent and dedication that King has brought to his language.
Whatever you think of him, the bottom line is that he created a whole language + library + IDE plug-ins from scratch over a few years with a small team.
Ceylon will probably not go anywhere now that Kotlin has taken over, but that doesn't take away anything from the talent and dedication that King has brought to his language.
> I won't speak for others, but I discarded the idea of ever using Ceylon when I learned that Gavin King was involved with it. I won't go into why--a simple Google search will easily allow people to make up their own minds--but suffice it to say that I don't find him professional enough to rely on a project that he leads.
Hibernate and EJB3 were both lead by Gavin and are widely used. Hibernate, in particular, was massively successful too.
Hibernate and EJB3 were both lead by Gavin and are widely used. Hibernate, in particular, was massively successful too.
Code examples are missing on the linked page. Having a website about a new car without any pictures would be strange, same applies to less known programming languages.
The linked page is a proposal for the Eclipse "foundation" or whatever it's called to "take over" Ceylon. It's not a page about Ceylon itself.
The web site of Ceylon is at https://ceylon-lang.org/
The web site of Ceylon is at https://ceylon-lang.org/
Here, https://ceylon-lang.org/documentation/1.3/introduction/ seems to be a good place to start with the language.
As a huge fan of Scala, Ceylon is one of the other languages I'm keeping an eye on and hope succeeds. It is much more ambitious and forward thinking than Kotlin, and subsequently see it having a much longer future than Kotlin.
I would love for this to be the case, but it seems to have a tiny fraction of the mindshare of Kotlin.
It's a weird time of year, when you don't know if the title is talking about a new project from Eclipse or something about the event tomorrow!
Yeah, I thought the eclipse was happening over the continental US. What's up with Sri Lanka?
I had to lookup what Ceylon actually is. On github I found the link https://ceylon-lang.org/. You will find some screenshots showing IDE support as well.
I read about it when it came out, alongside with Kotlin.
I bet on Ceylon, but somehow people preferred Kotlin.
I bet on Ceylon, but somehow people preferred Kotlin.
I can tell you my main reason for going with Kotlin after looking into Ceylon[1]:
(Ironic, I guess, that the language developed by an IDE vendor is the better one to use without an IDE.)
Edit: To elaborate, the Ceylon docs say[2] that "one of the goals of the language is for most code to be immediately readable to people who aren't Ceylon programmers, and who haven't studied the syntax of the language."
I think this is a very misguided goal. No programmer is going to be confused about what "var" means, so making everyone type "variable" gains you nothing. And at the same time, that very same introduction page has plenty of syntax that you won't understand without studying it first, so it still wouldn't achieve their aim, even if those concessions to verbosity had somehow helped.
[1] http://in.relation.to/2011/04/13/ceylon/
[2] https://www.ceylon-lang.org/documentation/current/introducti...
14. Apr 2011, 01:44 CET Gavin King | gavin.king(AT)gmail.com
> 1. 'variable' keyword is to long use var instead
We've so far avoided abbreviations. In practice the IDE will
type this annotation name for me.
(Ironic, I guess, that the language developed by an IDE vendor is the better one to use without an IDE.)
Edit: To elaborate, the Ceylon docs say[2] that "one of the goals of the language is for most code to be immediately readable to people who aren't Ceylon programmers, and who haven't studied the syntax of the language."
I think this is a very misguided goal. No programmer is going to be confused about what "var" means, so making everyone type "variable" gains you nothing. And at the same time, that very same introduction page has plenty of syntax that you won't understand without studying it first, so it still wouldn't achieve their aim, even if those concessions to verbosity had somehow helped.
[1] http://in.relation.to/2011/04/13/ceylon/
[2] https://www.ceylon-lang.org/documentation/current/introducti...
> No programmer is going to be confused about what "var" means, so making everyone type "variable" gains you nothing
"variable" is easily distinguished from "value" in Ceylon, whereas "var" and "val" are easily confused in Kotlin, being only different by a single letter "r" and "l" -- which even sound the same in some East Asian languages.
"variable" is easily distinguished from "value" in Ceylon, whereas "var" and "val" are easily confused in Kotlin, being only different by a single letter "r" and "l" -- which even sound the same in some East Asian languages.
True, and "let" would have been better. Scala uses var and val though, so I suppose they chose it for familiarity.
When it comes to Ceylon, they weren't going for easily distinguished, they were going for unabbreviated (see earlier link) - the rest of the language follows the same pattern.
Anyway, I'd rather take this minor risk of confusion than a language I can barely write without auto-completion. It hasn't been a big problem for me in practice. And if you do use an IDE, it will use syntax highlighting to distinguish var and val.
When it comes to Ceylon, they weren't going for easily distinguished, they were going for unabbreviated (see earlier link) - the rest of the language follows the same pattern.
Anyway, I'd rather take this minor risk of confusion than a language I can barely write without auto-completion. It hasn't been a big problem for me in practice. And if you do use an IDE, it will use syntax highlighting to distinguish var and val.
Ceylon was designed with functional programming in mind. The idea is that variable is something you will rarely type because mutability is something to avoid; with this mindset, the pain of typing it could be considered a feature.
value is used for type inference and isn't much different from typing val. It's also optional; you might just declare an actual type instead, ala Java. I personally think this tends to read better, but that's probably because I spend most of my time in Java.
value is used for type inference and isn't much different from typing val. It's also optional; you might just declare an actual type instead, ala Java. I personally think this tends to read better, but that's probably because I spend most of my time in Java.
> The idea is that variable is something you will rarely type
This, precisely. I feel Ceylon uses more sensible defaults all around, like also having non-public methods/properties by default unless explicitly declared public. I use Kotlin in some projects, but don't really like its default of public properties and methods unless explicitly declared private, nor their decision on final classes by default.
It's also so many other little things in Ceylon that really add up to make it a pleasure to use, like its simplification of numeric types to just the minimal meaningful set of Integer and Float[1] (no Double, Long, etc), its integer literals which use the metric suffix system, like 5k for 5000, 5M for 5 million, and even hex integer literals like #ffffff, etc.[2][3], its comparison operations which return one of the enumerated Comparison type of smaller, equal, or larger (and not -1, 0, 1) ...etc
[1] https://ceylon-lang.org/documentation/current/tour/language-...
[2] https://ceylon-lang.org/documentation/current/reference/lite...
[3] https://ceylon-lang.org/documentation/current/tour/language-...
This, precisely. I feel Ceylon uses more sensible defaults all around, like also having non-public methods/properties by default unless explicitly declared public. I use Kotlin in some projects, but don't really like its default of public properties and methods unless explicitly declared private, nor their decision on final classes by default.
It's also so many other little things in Ceylon that really add up to make it a pleasure to use, like its simplification of numeric types to just the minimal meaningful set of Integer and Float[1] (no Double, Long, etc), its integer literals which use the metric suffix system, like 5k for 5000, 5M for 5 million, and even hex integer literals like #ffffff, etc.[2][3], its comparison operations which return one of the enumerated Comparison type of smaller, equal, or larger (and not -1, 0, 1) ...etc
[1] https://ceylon-lang.org/documentation/current/tour/language-...
[2] https://ceylon-lang.org/documentation/current/reference/lite...
[3] https://ceylon-lang.org/documentation/current/tour/language-...
I preferred kotlin when it came out because it had android support as an explicit goal, and android is the main reason I'd want a jvm language. seems to have worked out that way in practice too.
[deleted]
Good news. Moreover, it would be great if Eclipse would take over Eclipse IDEs for Haskell and Rust...
I don't know how, in 2017, you write something this long about a new programming language and fail to have a single example or even hello world. Sheesh.
The language itself is a spiritual successor to java kind of like kotlin but they decided not to depend on java specific classes like ArrayList which means you have to convert between those with a function to get a proper ceylon list datatype which has filter, map, fold, etc. Instead they developed their own ceylon sdk. This has some advantages if you have a non Java implementation but requires you to ship around more code which is undesirable for web and mobile app development. Kotlin has a big advantage in Java only environments like android.
Strangely enough I never got "stuck" in this language. I never felt the need to go to stackoverflow or any other external site because there was a problem that I couldn't solve because of my unfamilarity with the language. All I did was read the guide a few times and occasionally look at the reference. The language felt very intuitive to me.
The compiler is a bit too slow in my opinion because I'm not trading my time off to get better performance like C++ compilers do.
I think the language is stuck in a limbo between good language design and suboptimal implementation.