5 ms·

Best available is a pretty bold claim, how does it compare to the likes of Haskell in regards to static typing, type safety, and readability?

RivieraKid 13y ago
I have very little experience with Haskell, I didn't really like it, it didn't seem to have strong focus on peoductivity, my view is that: * Imperative programming is more straightforward in Ceylon. * The same holds for functions with side-effects. * Type safety is similar, Ceylon currently doesn't have type classes and generalized algebraic data types but will be probably added according to the FAQ. * Ceylon is less type-inferred, which makes it more readable IMHO (1. regular syntax 2. type annotations are not just for the compiler, but for documentation too). Also - less confusing compiler errors. * In general, Ceylon feels pragmatic, Haskell academic.
- pjmlp 13y ago
  > In general, Ceylon feels pragmatic, Haskell academic. Except Haskell is being used in the industry already, while Ceylon is a Java wannabe replacement.
  - RivieraKid 13y ago
    Haskell is way older than Ceylon.
- codygman 13y ago
  > * The same holds for functions with side-effects. Just about every haskell program I write has functions with side-effects. > * Ceylon is less type-inferred, which makes it more readable IMHO ... 2. type annotations are not just for the compiler, but for documentation too). So having to write type annotations all the time is an advantage for you? You can just as easily add type annotations to Haskell, are you saying that since it is compiler enforced with Ceylon, that Ceylon code as a whole is easier to read? Furthermore, doesn't less type-inferred just mean "type inference isn't as good", or was that a design decision? > Also - less confusing compiler errors. Any examples of confusing Haskell compiler errors? I personally haven't seen any memorably confusing compiler errors from Haskell. Have you seen any with Haskell or is that just something you've heard about? Any examples of compiler errors where Ceylon beats Haskell? Any examples of compiler errors where Ceylon beats Java? > 1. regular syntax By "regular syntax" do you mean "algol derived or inspired"? > * In general, Ceylon feels pragmatic, Haskell academic. This is interesting, because it's something I've heard from just about everyone I've asked about Haskell. Recently I have delved into Haskell myself and haven't found it true. For instance, arrows are something many consider "academic", but they enable the very pragmatic and real world advantage of handling HTML like: -- haskell -- added bonus of type safety through type inference! images tree = tree >>> css "img" >>> getAttrValue "src" -- python def images(tree): imgs = [elem for elem in tree if elem.tag == "img"] sources = [img.get('src') for img in imgs] return sources -- alternate python def images(tree): return [ img.get('src' for img in filter(lambda i: i.tag == "img", tree)] If my understanding is correct the Haskell above is (at least could) take advantage of stream fusion which has the real world advantage of being really efficient and really fast. > * In general, Ceylon feels pragmatic, Haskell academic. This is something that is entirely subjective. I will have to look into Ceylon more in the future. I will say that from the outside Haskell looked very academic for me, but after writing some code, Haskell feels/seems to be/has proven to be a very pragmatic language that doesn't deserve a reputation of being "academic". As a whole I wish that many other languages weren't just dismissed as "academic" so that we could innovate more quickly and improve technology as a whole. There are valid arguments to be had about much of the experimental stuff, but calling something "academic" is usually a cop out in my experience.
  - RivieraKid 13y ago
    > Just about every haskell program I write has functions with side-effects. That's because just about every program needs side-effects. My point was that side-effects are more straightforward in Ceylon, you don't need monads. > So having to write type annotations all the time is an advantage for you? You can just as easily add type annotations to Haskell, are you saying that since it is compiler enforced with Ceylon, that Ceylon code as a whole is easier to read? Yes. I think that it makes the language more regular and less messy. When you look at foreign code, you can always immediately see the types. But I have little experience with Haskell or Scala, so I may be wrong. > Furthermore, doesn't less type-inferred just mean "type inference isn't as good", or was that a design decision? My guess is that it was a design decision. I think they wanted to have a interface model that's understandable and predictable (you can easily say whether type annottions are necessary or not). > Any examples of confusing Haskell compiler errors? I personally haven't seen any memorably confusing compiler errors from Haskell. Have you seen any with Haskell or is that just something you've heard about? No, I admit that this was something I read on Ceylon's site (I think) and it's quite possible I'm wrong here. > By "regular syntax" do you mean "algol derived or inspired"? Not sure how to put my intuitive understanding of "regular" into words... I would say that it means that the code has relatively few visual patterns, there's lower visual variance. It's like with tidy (= regular) vs messy (= irregular) rooms. It's easier to "understand" tidy room. > This is interesting, because it's something I've heard from just about everyone I've asked about Haskell. Recently I have delved into Haskell myself and haven't found it true. For me it's evident that Ceylon has very pragmatic focus on real-world productivity. I was excited about the design decesions and trade-offs they've made, I've often thought "yes, exactly my thoughts!" when reading the language design FAQ. On the other hand, I simply don't see the focus on productivity in Haskell. Do monads really increase productivity? Would a team of Haskell programmers implement a stackoverflow.com copy faster than, let's say, a team of similarly intelligent and experienced C# programmers? > For instance, arrows are something many consider "academic", but they enable the very pragmatic and real world advantage of handling HTML like: The Python code could be: def images(tree): return [img.get('src') for elem in tree if elem.tag == "img"] It's almost as succint but seems more regular to me, it's just the old good comprehension, nothing fancy.

RivieraKid 13y ago

I have very little experience with Haskell, I didn't really like it, it didn't seem to have strong focus on peoductivity, my view is that: * Imperative programming is more straightforward in Ceylon. * The same holds for functions with side-effects. * Type safety is similar, Ceylon currently doesn't have type classes and generalized algebraic data types but will be probably added according to the FAQ. * Ceylon is less type-inferred, which makes it more readable IMHO (1. regular syntax 2. type annotations are not just for the compiler, but for documentation too). Also - less confusing compiler errors. * In general, Ceylon feels pragmatic, Haskell academic.

pjmlp 13y ago
> In general, Ceylon feels pragmatic, Haskell academic. Except Haskell is being used in the industry already, while Ceylon is a Java wannabe replacement.
- RivieraKid 13y ago
  Haskell is way older than Ceylon.
codygman 13y ago
> * The same holds for functions with side-effects. Just about every haskell program I write has functions with side-effects. > * Ceylon is less type-inferred, which makes it more readable IMHO ... 2. type annotations are not just for the compiler, but for documentation too). So having to write type annotations all the time is an advantage for you? You can just as easily add type annotations to Haskell, are you saying that since it is compiler enforced with Ceylon, that Ceylon code as a whole is easier to read? Furthermore, doesn't less type-inferred just mean "type inference isn't as good", or was that a design decision? > Also - less confusing compiler errors. Any examples of confusing Haskell compiler errors? I personally haven't seen any memorably confusing compiler errors from Haskell. Have you seen any with Haskell or is that just something you've heard about? Any examples of compiler errors where Ceylon beats Haskell? Any examples of compiler errors where Ceylon beats Java? > 1. regular syntax By "regular syntax" do you mean "algol derived or inspired"? > * In general, Ceylon feels pragmatic, Haskell academic. This is interesting, because it's something I've heard from just about everyone I've asked about Haskell. Recently I have delved into Haskell myself and haven't found it true. For instance, arrows are something many consider "academic", but they enable the very pragmatic and real world advantage of handling HTML like: -- haskell -- added bonus of type safety through type inference! images tree = tree >>> css "img" >>> getAttrValue "src" -- python def images(tree): imgs = [elem for elem in tree if elem.tag == "img"] sources = [img.get('src') for img in imgs] return sources -- alternate python def images(tree): return [ img.get('src' for img in filter(lambda i: i.tag == "img", tree)] If my understanding is correct the Haskell above is (at least could) take advantage of stream fusion which has the real world advantage of being really efficient and really fast. > * In general, Ceylon feels pragmatic, Haskell academic. This is something that is entirely subjective. I will have to look into Ceylon more in the future. I will say that from the outside Haskell looked very academic for me, but after writing some code, Haskell feels/seems to be/has proven to be a very pragmatic language that doesn't deserve a reputation of being "academic". As a whole I wish that many other languages weren't just dismissed as "academic" so that we could innovate more quickly and improve technology as a whole. There are valid arguments to be had about much of the experimental stuff, but calling something "academic" is usually a cop out in my experience.
- RivieraKid 13y ago
  > Just about every haskell program I write has functions with side-effects. That's because just about every program needs side-effects. My point was that side-effects are more straightforward in Ceylon, you don't need monads. > So having to write type annotations all the time is an advantage for you? You can just as easily add type annotations to Haskell, are you saying that since it is compiler enforced with Ceylon, that Ceylon code as a whole is easier to read? Yes. I think that it makes the language more regular and less messy. When you look at foreign code, you can always immediately see the types. But I have little experience with Haskell or Scala, so I may be wrong. > Furthermore, doesn't less type-inferred just mean "type inference isn't as good", or was that a design decision? My guess is that it was a design decision. I think they wanted to have a interface model that's understandable and predictable (you can easily say whether type annottions are necessary or not). > Any examples of confusing Haskell compiler errors? I personally haven't seen any memorably confusing compiler errors from Haskell. Have you seen any with Haskell or is that just something you've heard about? No, I admit that this was something I read on Ceylon's site (I think) and it's quite possible I'm wrong here. > By "regular syntax" do you mean "algol derived or inspired"? Not sure how to put my intuitive understanding of "regular" into words... I would say that it means that the code has relatively few visual patterns, there's lower visual variance. It's like with tidy (= regular) vs messy (= irregular) rooms. It's easier to "understand" tidy room. > This is interesting, because it's something I've heard from just about everyone I've asked about Haskell. Recently I have delved into Haskell myself and haven't found it true. For me it's evident that Ceylon has very pragmatic focus on real-world productivity. I was excited about the design decesions and trade-offs they've made, I've often thought "yes, exactly my thoughts!" when reading the language design FAQ. On the other hand, I simply don't see the focus on productivity in Haskell. Do monads really increase productivity? Would a team of Haskell programmers implement a stackoverflow.com copy faster than, let's say, a team of similarly intelligent and experienced C# programmers? > For instance, arrows are something many consider "academic", but they enable the very pragmatic and real world advantage of handling HTML like: The Python code could be: def images(tree): return [img.get('src') for elem in tree if elem.tag == "img"] It's almost as succint but seems more regular to me, it's just the old good comprehension, nothing fancy.