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

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