Heh, we'll have to post more commercials about how great we are, instead of always being so intensely self-critical ;-)
159 karma · joined December 20, 2011
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.
Now, this pattern has recently been imported into object-oriented land by languages like Scala and now Java 8, because these languages also don't have first-class union types.
But in my opinion, that's the wrong path to have taken. In OO-land, we _do_ have subtyping, so things like unions and intersections are well-representable within the type system, and we don't need these workaround wrapper types.
_Please_ try Ceylon IDE, and let us know where it's nonasskicking. We've worked very, very hard on it, and we think we have something really useful and usable, but of course we very much welcome feedback.
FTR, I personally pushed almost 240 klocs to this project over the past two years.
Also, Ceylon doesn't need Either, since that is just a workaround for not having union types.
Seriously, union and intersection types are _really_ fundamental notions in set/type theory, and having them as basic constructs of the language makes the language _much_ more expressive.
I seriously urge you to try it out. You'll love them, I guarantee it.
> 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.
Sorry, but Option is just not better. One advantage of using a union type is that if I have a List<String?>, I just have a List<String|Null> (which maps to a plain List<String> at the JVM level) not a whole list of wrapper objects in a List<Option<String>>.
And of course Ceylon has sufficient syntax sugar so that you can write things like:
print(nameOrNull else "Gavin);
> Also, the tooling around Scala is starting to mature. The Kotlins and Ceylons of the world are way behind Scala in this regard as well.
WDYM?! I strongly beg to differ. Have you seriously tried out Ceylon's IDE? Or are you just speculating?
And that's _exactly_ why you need modularity built into the ecosystem. OSGi and Maven _are_ hideously overengineered, and they're overengineered because there's no common model built into the language, toolset, and platform.
> I've never understood what problem it's supposed to solve.
Management of versioned dependencies between libraries and components developed by different teams. This is absolutely central to what software engineering is all about.
> Nullable types? The trouble with doing this at the language level is that you can't then treat them as plain old objects.
I don't think you've understood what this is. In Ceylon, null is the singleton instance of the perfectly ordinary class Null. A nullable type is just a union type of form Null|X, for any type X.
> Can I write a method that's polymorphicly nullable?
Sure. You should see the crazily cool stuff we can do with stuff like the signature of max(). You'll be impressed, I promise!
After that, check out signatures of operations like Set.union(), Set.intersection(), coalesce(), compose(), flatten(), curry(), etc, to see a bunch of other things you just can't write in Scala.
> functions and methods? Got them.
Does scala have toplevel functions? I thought they always had to be nested inside some object?
But my real big problem with Scala here is it just doesn't have proper function and tuple types that you can abstract over. Instead you have F, F1, F2, F3 ... F22 and Tuple2, Tuple3, ... Tuple22. That to me is just rubbish.
There's at least two live attempts to build a web framework for Ceylon, so if you're interested in contributing, I know for sure that Julien Viet or Daniel Rochetti would appreciate the help. Join us on IRC or ceylon-dev. :-)
- the central place that modularity plays in the whole architecture, and
- the fact that the JavaScript VM is a first-class citizen.
While I don't doubt that you'll find things you miss from Scala (implicits, if you insist - though IMO they're generally harmful, pattern matching, maybe, or higher-order generics, perhaps), I'm sure you'll find things in Ceylon that you'll love. For example, I _know_ you're going to love the things you can do with union/intersection types. I think you'll really like how we treat null, and our approach to flow-dependent typing in general. You might also dig how the language treats tuple and function types, and how you can just naturally abstract over the arity of a function/tuple type. And you might find runtime metaprogramming with reified generics and the typesafe metamodel a whole lot of fun.
I hope that's at least half an answer...
Also, FTR, Sri Lanka has been an independent nation for _65 years_. If it's unclear, the Ceylon project does not endorse, nor were any of us alive during, the former colonial rule of the island. Indeed, we're much more interested in elephants than in british guys with funny hats.
> Can any company just trademark the former colonial name of a now sovereign nation?
Yes.
A trademark is a claim of exclusive use of a name for a certain type of product or service, in this case, our trademark prevents other people from naming their programming languages "Ceylon". You can find lots more information about trademark law using Google, if you're curious.