Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS? I want to like Ceylon because it's the language Scala should be (assuming that higher-kinded types made it in - I could never work without them). It's Scala with all the ugly parts polished away, Scala with ten years' progress in language design. But it does nothing that Scala can't. Scala mi…
Fully agree. I dabble with whatever new languages come out as any other language geek, but at work it only matters the languages validated by the IT department or requested by the customer. So, like many, I only work with languages blessed as first class languages in vendor SDKs. With Scala and Clojure barely being adopted by most Java shops (in perpetual terms), I don't see where Ceylon might fit in without a story…
Why you might want to choose Ceylon
21–30 of 148 posts
Re: Why you might want to choose Ceylon
#22I guess for me I don't need nor want JVM + JavaScript VM interoperability. My gut says this limits what can be done. I would rather have just one or the other. Maybe others feel differently.
Re: Why you might want to choose Ceylon
#23I guess for me I don't need nor want JVM + JavaScript VM interoperability. My gut says this limits what can be done. I would rather have just one or the other. Maybe others feel differently.
I think you'll decide your gut was wrong, but there's only one way to be sure.
Re: Why you might want to choose Ceylon
#24Earlier quoted context omitted.
I think it's part of a general trend of language designers (and even language fans) not understanding what makes languages work in practice. For academic languages this may not matter, but if you actually want your language to be used, you need to pay attention. A recent study[1] has shown that "extrinsic" factors (performance, tooling, familiarity, libraries) matter a lot more than intrinsic factors (syntax, abstrac…
Yeah, the Kotlin inter-op is really well done. Having IntelliJ just work is always discounted more than I think people should. I do wish Kotlin had more pattern matching semantics but that's just me being picky, it's a really nice language.
To be fair, Kotlin has the advantage of being created by the company that makes IntelliJ, so it's got a big head start IDE-wise.
Re: Why you might want to choose Ceylon
#25Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS? I want to like Ceylon because it's the language Scala should be (assuming that higher-kinded types made it in - I could never work without them). It's Scala with all the ugly parts polished away, Scala with ten years' progress in language design. But it does nothing that Scala can't. Scala mi…
I think it's part of a general trend of language designers (and even language fans) not understanding what makes languages work in practice. For academic languages this may not matter, but if you actually want your language to be used, you need to pay attention. A recent study[1] has shown that "extrinsic" factors (performance, tooling, familiarity, libraries) matter a lot more than intrinsic factors (syntax, abstrac…
The biggest downsides I've encountered are around the deeper-magic Java interop, with stuff like Dropwizard's HK2 dependency injection system getting a little messy--especially around non-nullable parameters--but that stuff is, all things considered, a small part of the application.
Re: Why you might want to choose Ceylon
#26Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS? I want to like Ceylon because it's the language Scala should be (assuming that higher-kinded types made it in - I could never work without them). It's Scala with all the ugly parts polished away, Scala with ten years' progress in language design. But it does nothing that Scala can't. Scala mi…
Fully agree. I dabble with whatever new languages come out as any other language geek, but at work it only matters the languages validated by the IT department or requested by the customer. So, like many, I only work with languages blessed as first class languages in vendor SDKs. With Scala and Clojure barely being adopted by most Java shops (in perpetual terms), I don't see where Ceylon might fit in without a story…
Re: Why you might want to choose Ceylon
#27Earlier quoted context omitted.
Fully agree. I dabble with whatever new languages come out as any other language geek, but at work it only matters the languages validated by the IT department or requested by the customer. So, like many, I only work with languages blessed as first class languages in vendor SDKs. With Scala and Clojure barely being adopted by most Java shops (in perpetual terms), I don't see where Ceylon might fit in without a story…
Have you checked out Hello at www.amsdec.com?
Re: Why you might want to choose Ceylon
#28It doesn't have extension functions. Since moving to Kotlin for my projects, I really enjoy the power that these provide: https://kotlinlang.org/docs/reference/extensions.html What does Ceylon give me over Kotlin?
Well, if you read the linked article, a number of things are mentioned, including: - union and intersection types - an elegant and powerful representation of tuple and function types - reified generics - the cleanest solution to the problem of null - awesome modularity - a language module [that] completely abstracts the underlying runtime, and offers a set of elegant APIs that vastly improve on those available native…
- an elegant and powerful representation of tuple and function types -- Okay, Kotlin could do with this
- reified generics -- This is apparently expensive on the JVM: http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/
- the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is subjective. -- Does Ceylon have Safe Casts? https://kotlinlang.org/docs/reference/null-safety.html
- awesome modularity -- Something I'll need to look into
- a language module [that] completely abstracts the underlying runtime, and offers a set of elegant APIs that vastly improve on those available natively -- I guess the improvement in abstraction comes from the Reified Generics -- Have you got any examples of where the API is superior to that of the Kotlin one? For example, with Kotlin's extension functions Java File object has been extended with a readLines() function that returns all of the lines of a File as a List. I was impressed when I saw that. Underneath it is doing the usual BufferedReader and InputStream boiler plate work that you would normally write in Java.
- a language specification -- https://kotlinlang.org/docs/reference/
Re: Why you might want to choose Ceylon
#29Earlier quoted context omitted.
Yeah, the Kotlin inter-op is really well done. Having IntelliJ just work is always discounted more than I think people should. I do wish Kotlin had more pattern matching semantics but that's just me being picky, it's a really nice language.
>Having IntelliJ just work is always discounted more than I think people should. To be fair, Kotlin has the advantage of being created by the company that makes IntelliJ, so it's got a big head start IDE-wise.
The other advantage of Kotlin is that it builds on top of the existing Java code base. Java has had decades to build up an ecosystem of frameworks and libraries. Kotlin builds on these with excellent interop.
Re: Why you might want to choose Ceylon
#30Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS? I want to like Ceylon because it's the language Scala should be (assuming that higher-kinded types made it in - I could never work without them). It's Scala with all the ugly parts polished away, Scala with ten years' progress in language design. But it does nothing that Scala can't. Scala mi…
> I want to like Ceylon because it's the language Scala should be > but I just can't see people choosing the more polished language over the one with ten years worth of library and tool support when there's no USP beyond that polish It seems all a matter of time. What would Ceylon look like to you after some years of library and tool support?