Did anybody checkout xtend-lang.org? It's for sure better in terms of Java-interoperability and IDE plugins (Eclipse and IntelliJ)
And it even has macros!!
Why you might want to choose Ceylon
131–140 of 148 posts
Re: Why you might want to choose Ceylon
#132Earlier quoted context omitted.
I'm not sure the evidence is any stronger. I mean, you can point to some bugs and say they were caused by a lack of memory safety, I can point to some bugs and say they were due to a poor type system. Certainly there were problems I faced in day-to-day Java programming that were visibly due to a crude type system - NPEs, the awkwardness of working with checked exceptions (I do think Ceylon has missed a trick by not u…
I really like your answer. I think it's very important to start with actual problems and then work your way towards a solution rather than vice-versa, because I've always been more troubled by all the bad things people do with rich types[1] rather than notice the importance of problems they do solve. On the other hand, any powerful general tool built into the language can be more trouble than it's worth. Macros are a…
Hmm, the reason I find types clearer than macros is that they do apply everywhere, so there's consistency across a codebase. running the checkers, but it can't and won't apply the right annotations when extracting a method, or show you the checker-inferred types of local variables.
I do think implicit conversions allow too much; IMO we need typeclasses and extension methods. So my ideal design for a language would include implicit parameters but not implicit conversions, and instead have dedicated support for extension methods. That said we do need to be able to use typeclasses without disrupting method application syntax (i.e. support the use case that means Spray prefers the implicit-conversion-based "magnet pattern" rather than a typeclass).
More generally I think there will be languages that allow too much and languages that ban too much, and we need languages on both sides of the line to allow us to converge on something better. Most places I've worked have had a strong code review/pull request culture which may have coloured my experience - I just haven't seen the Scala maintainability problems you talk about.
(If I thought the complexity of collections was necessary to avoid casts then I would defend it - casts can fail and so it's very nice to have a codebase where they're banned entirely (enforced with wartremover). But I don't think it is - FWIW Odersky's asked for proposals for scala collections in version 3, and I think there's a substantial push towards at least some simplification - perhaps replacing CanBuildFrom with a 1-parameter typeclass that would retain most of the power and simplify the code. The showing-off cases like BitSet#map would require one more method call, but no casts)
Re: Why you might want to choose Ceylon
#133Earlier quoted context omitted.
> 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…
He did the same uninformed rants about other languages for a long time already. It's unlikely that he will do his homework any time soon.
What's unlikely is that you'll ever try to understand what it is that I'm saying when I talk about language design goals.
Re: Why you might want to choose Ceylon
#134Earlier quoted context omitted.
Right, but by "interop" I didn't just mean the ability to call into Java code and vice-versa, although I admit that's the traditional definition. Scala can do that too. What I meant is, Kotlin raised the bar in the interop department to new heights: it uses the same collection types, so there's no conversion between Java and some other SDK, but still manages to enhance them via compiler magic and extensions. It has a…
> but still manages to enhance them via compiler magic and extensions The thing is that Scala tried to do that for years, and after years of battling subtle, leaky abstractions, they picked a different design. It feels like Kotlin designers are completely unaware of what other languages tried and keep repeating all the mistakes ...
Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently.
In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to.
It may be that in the end, Kotlin succeeds where Scala struggled, simply because the Kotlin designers do a better job.
Re: Why you might want to choose Ceylon
#135Earlier quoted context omitted.
> but still manages to enhance them via compiler magic and extensions The thing is that Scala tried to do that for years, and after years of battling subtle, leaky abstractions, they picked a different design. It feels like Kotlin designers are completely unaware of what other languages tried and keep repeating all the mistakes ...
Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently. In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to. It may be that in the end, Kotlin succeeds where Scala struggled, simply becaus…
Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.)
It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been rejected by the Scala developers for good reasons – years ago.
Kotlin's struggles are a good example that knowing how to build IDE support for existing languages doesn't give you the skills to design a programming language from scratch.
The Kotlin designers specifically call out Scala's
mistakes when discussing why they do things differently.
Re: Why you might want to choose Ceylon
#136Earlier quoted context omitted.
Right, but the JS and JVM runtimes have quite different behavior. And I'm willing to bet that implementing something as non-trivial as java.time again in Scala(.js) will end up causing quite a few bugs because they aren't identical. That's why I'd rather have a single implementation for anything non-trivial and just retarget that to each backend using more low-level primitives. After all you're using a different lang…
Yeah, inventing an API and implementation of a date/time/calendar library from scratch without an existing spec, implementation, tests or experience will surely be totally bug-free.
I'm not sure why you're being sarcastic.
I'm not saying it'll be bug-free. My point is that it'll have exactly the same bugs on either platform. This may be preferable to having different bugs on different platforms.
Re: Why you might want to choose Ceylon
#137Earlier quoted context omitted.
Yeah, inventing an API and implementation of a date/time/calendar library from scratch without an existing spec, implementation, tests or experience will surely be totally bug-free.
I'm not sure why you're being sarcastic. I'm not saying it'll be bug-free. My point is that it'll have exactly the same bugs on either platform. This may be preferable to having different bugs on different platforms.
Same bugs on different platforms are extremely hard to find.
Different bugs on different platforms are like an early Christmas present:
You don't even need to write tests which include your "expectations" of the result anymore.
Just call the code with randomized inputs for both platforms, and if there is a difference, you found a bug.
Re: Why you might want to choose Ceylon
#138Earlier quoted context omitted.
Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently. In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to. It may be that in the end, Kotlin succeeds where Scala struggled, simply becaus…
Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.) It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been reje…
Could you please give a few examples of "all the broken, half-designed stuff they are trying to ship"?
Re: Why you might want to choose Ceylon
#139Earlier quoted context omitted.
Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently. In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to. It may be that in the end, Kotlin succeeds where Scala struggled, simply becaus…
Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.) It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been reje…
Different languages have different design tradeoffs. I had many profitable exchanges with Andrey Breslav and other Kotlin designers. We can have a technical discussion about the design choices without getting into a fight about who is more competent.
Re: Why you might want to choose Ceylon
#140Earlier quoted context omitted.
Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.) It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been reje…
Could you please give a few examples of "all the broken, half-designed stuff they are trying to ship"?
- extension methods
- property syntax + magic identifier
- reified
- immutable wrappers around mutable collections
- const
- multiple redundant ways of defining generic upper bounds
- companion objects + syntax
- operator/infix rules
- constantly changing nullability rules