Hacker News Reader

Comment by RivieraKid | Hacker News Reader

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.

View on HN

> In general, Ceylon feels pragmatic, Haskell academic.

Except Haskell is being used in the industry already, while Ceylon is a Java wannabe replacement.

Haskell is way older than Ceylon.

> * 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.

> 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.

>> 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.

FTR, I think you might have got mixed up here. Definitely good error reporting is a very major priority for the language, and I think we generally do better than Java at least when generics are involved, but we've never made any comparisons positive or negative to Haskell.

Ahh, ok. BTW - what do you think about Julia? It's the most impressive dynamic language IMO.

Don't know anything about it. But it's good that there's a revival of interest in languages for scientific computing. When I was in uni all we had was Fortran :-/

I consider it a general-purpose language, it's mostly the libs and community that give it scientific bias. I've used it as a Python replacement for scientific computing recently and if the libs were more mature, I would choose it over Python for, say, web dev. Can highly recommend, especially for language designers :)

Don't get me wrong, I don't mean to belittle scientific computing, which is after all, a big part of my background (I'm a mathematician by training).

> So having to write type annotations all the time is an advantage for you?

Well, there are very interesting tradeoffs here. If you want to go the "whole hog", i.e. HM type inference, where you don't need to annotate the types of parameters, you can't have subtyping (at least not in the usual sense yes yes I know about OCaml which requires an explicit upcast).

Now, I personally think subtyping is great, and it's even greater when you introduce first-class union+intersection types into the mix. So there's definitely a place for languages without full HM type inference.

Next, you could still have a system with more type inference than what Ceylon supports, but you would need an arbitrary number of passes over the code to infer types, and you would introduce the possibility of typing errors which can't be pinned down to a single erroneous expression.

So Ceylon supports a more limited sort of type inference: local type inference. The Ceylon compiler can infer and check all expressions in a single pass over the code, and every typing error is localized to a single expression.

And y'know what: that turns out to be a pretty reasonable thing practically speaking, since documenting the types of exported APIs is frankly a good thing to do anyway, and helps the people who come along later and look at your code.

Reply on news.ycombinator.com