Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you might want to choose Ceylon

ceylon-lang.org

Post reply on HN
Print view View original

101–110 of 148 posts

Re: Why you might want to choose Ceylon

#101

Post by lmm »

udalov wrote: post #54
gavinking wrote: post #35

Earlier quoted context omitted.

For the record: - Kotlin does not have tuples, and doesn't allow abstraction over function -arity. So no, it can't to that. - Reified generics are simply not expensive, at least not the way Ceylon implements them. But sure, Ceylon's reified generics were implemented by Stef Epardaud who is the best programmer I've ever worked with, so I can understand if some other people find them difficult to implement efficiently.…

Could you please explain how the internal representation of null in the language's type system has any effect on the semantics of code written in that language?

Null in Ceylon is just another type, and nullable-X is just another union type, so you can use them sensibly with generics. With Kotlin if you want to write a generic method like "add two values" and have it handle nullness polymorphically then you have to think about it.

Re: Why you might want to choose Ceylon

#102

Post by wtetzner »

pron wrote: post #9
lmm wrote: post #2

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…

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…

> I think it's part of a general trend of language designers (and even language fans) not understanding what makes languages work in practice.

Maybe, or maybe not all language designers have the goal of making their language as popular as possible. A language can be popular enough, such that it has a good community and good set of libraries, without trying to get everyone to switch.

In fact, depending on what you're looking for, a language can become too popular. In this case, you start getting people in the community that detract from it, rather than contribute to it.

Re: Why you might want to choose Ceylon

#104

Post by justthistime_ »

lomnakkus wrote: post #67
adrusi wrote: post #32

Earlier quoted context omitted.

Scalajs is reasonably good, but it is retrofitted; it's a javascript backend for a language that wasn't specifically designed for a javascript backent. Ceylon was designed to compile to javascript. I haven't used either so I can't comment as to whether it actually makes a difference.

One place where it makes quite a big difference is in the standard library. In scala the standard library is very often just a thin shim on top of the JVM equivalent... which means that scala.js needs to shim the JVM library. It's not a huge deal in that most everyday things pretty much work out of the box, but if you're using a lot of time/date manipulation (via Joda-Time or the JDK8 java.time package) you'll have t…

Why is reinventing the wheel considered a good thing?

javax.time is considered by some to be one of the best, most well-designed general and versatile libraries for date and time related matters out there, regardless in any language.

How would things be improved by throwing that away, and inventing something different? I think keeping the API and providing an implementation for Scala.js is a much more reasonable approach.

Designing a date/time requires very rare skills and knowledge that most people lack. A re-implementation of javax.time means all the documentation, tests and existing code can be re-used and allow correctness checks against the existing implementation.

Re: Why you might want to choose Ceylon

#105

Post by lomnakkus »

justthistime_ wrote: post #104
lomnakkus wrote: post #67

Earlier quoted context omitted.

One place where it makes quite a big difference is in the standard library. In scala the standard library is very often just a thin shim on top of the JVM equivalent... which means that scala.js needs to shim the JVM library. It's not a huge deal in that most everyday things pretty much work out of the box, but if you're using a lot of time/date manipulation (via Joda-Time or the JDK8 java.time package) you'll have t…

Why is reinventing the wheel considered a good thing? javax.time is considered by some to be one of the best, most well-designed general and versatile libraries for date and time related matters out there, regardless in any language. How would things be improved by throwing that away, and inventing something different? I think keeping the API and providing an implementation for Scala.js is a much more reasonable appr…

> Why is reinventing the wheel considered a good thing?

It's not. There just is no shim for java.time currently! Even worse, there could be licensing issues[1].

EDIT: That, and some of us are unfortunately still on JDK7 until the next Ubuntu LTS. Not that that's scala.js's fault, but it's a practical issue.

EDIT: ... and of course having a duplicate implementation of java.time (JDK + the shim-which-is-basically-a-reimplementation-in-JS) could be considered "reinventing the wheel"! :) If you have to reinvent the wheel, then doing it such that it at least behaves completely consistently across all backend platforms is preferable, IMO.

[1] https://github.com/scala-js/scala-js/issues/1618

Re: Why you might want to choose Ceylon

#106

Post by lomnakkus »

randomThoughts9 wrote: post #42
gavinking wrote: post #20

Earlier quoted context omitted.

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…

Not the best place to mention this, but I never understood why, at least when talking with the functional oriented people, the union types are not explained as providing first level support for the Option, Either and the Try monads.

Well, I guess it depends on what you mean by "first level" support.

For example, the T|Null thing doesn't give you code composability of the type monad transformers do -- at least as far as I understand it[1]. (I'm sure there are other things, but that's the first thing that popped into my head.)

FTR, I am a typed-FP weenie, but I still find Ceylon quite interesting, though I haven't done anything non-trivial in it yet.

[1] I still haven't fully understood the (experimental) HKT support, so maybe that can accomodate this?

Re: Why you might want to choose Ceylon

#107

Post by lomnakkus »

gavinking wrote: post #70
lomnakkus wrote: post #69

Earlier quoted context omitted.

The date/time cross-platformness is a big deal for business-type applications, at the very least. You tend to transfer/use a lot of dates/timestamps/what-have-you in that type of application. (This is a constant source of pain for me in scala.js.)

ceylon.locale is also shaping up to be really useful. Localization in JS is just terrible.

Yes, that's another of my pet peeves with scala.js since it basically splits your world into two around formatting of dates/time/currency/etc. (Things may have changed recently, but it was sorely lacking up until a few months ago.)

Re: Why you might want to choose Ceylon

#108

Post by lomnakkus »

twic wrote: post #83
gavinking wrote: post #58

Earlier quoted context omitted.

Now you're just lying. You said: "The problem with reified generics isn't their efficiency, but that they don't play nice with other generic types on the platform (which is the vast majority)." And the context of the comment was quite clearly Ceylon interoperating with Java as anyone can verify. I have a friendly request for you: please don't comment about Ceylon on any more hackernews or reddit threads. It's great t…

> I have a friendly request for you: please don't comment about Ceylon on any more hackernews or reddit threads. This is really unproductive. Reddit and HN are discussion forums; what we want on them is more discussion, not less. We want high-quality, accurate, discussion, but if we're not getting that, the solution is to raise the quality, not reduce the volume. In particular, the last thing i, as a reader of discus…

> please continue to comment about Ceylon wherever you like - but make sure you've done your homework before doing so!

The issue with this type of comment is that we (humans) have a set of cognitive biases which often lead us to think that we've "done [our] homework" when, in fact, we haven't. Such a person would probably actually only absorb the first portion of the quoted sentence from your post.

(Sorry for the slightly OT.)

Re: Why you might want to choose Ceylon

#109

Post by randomThoughts9 »

lomnakkus wrote: post #106
randomThoughts9 wrote: post #42

Earlier quoted context omitted.

Not the best place to mention this, but I never understood why, at least when talking with the functional oriented people, the union types are not explained as providing first level support for the Option, Either and the Try monads.

Well, I guess it depends on what you mean by "first level" support. For example, the T|Null thing doesn't give you code composability of the type monad transformers do -- at least as far as I understand it[1]. (I'm sure there are other things, but that's the first thing that popped into my head.) FTR, I am a typed-FP weenie, but I still find Ceylon quite interesting, though I haven't done anything non-trivial in it y…

There are some places where monad composability would improve your code but in general, at least the way I see it, you can replace a scala for comprehension with a set of IF statements, each IF eliminating a wrong value (null, exception, etc). Not to mention that you can have as many options as you like (A|B|C|D|E), whereas the mentioned monads must be composed in order to capture the same thing.

But it's true I never built a big ceylon project, so I can't say I know how that works out in practice.

Re: Why you might want to choose Ceylon

#110

Post by ngrilly »

gavinking wrote: post #45
pron wrote: post #38

Earlier quoted context omitted.

The problem with reified generics isn't their efficiency, but that they don't play nice with other generic types on the platform (which is the vast majority). Every choice in Kotlin's design has been intentional with one idea in mind -- compromise on purity in favor of interoperability (to lower the cost of adoption). So, of course you can do more at the language level with Ceylon, but Kotlin set out to do less in th…

"The problem with reified generics isn't their efficiency, but that they don't play nice with other generic types on the platform (which is the vast majority)." This is simply nonsense. You made it up. There have been zero complaints about problems Ceylon has in interoperating with Java's generic types, since they simply don't exist. I can't believe you just wrote such a longwinded comment about a nonexistent problem…

Could you grossly explain how reified generics are implemented and how they interoperate with Java's generic types? It would be a good way to defuse pron's claim.
Post reply on HN