The first thing I want to see when I hear about a new programming language is an example. The best examples of Omega that I've found so far are part of the test suite for the interpreter:<p><a href="http://code.google.com/p/omega/source/browse/#svn/trunk/tests" rel="nofollow">http://code.google.com/p/omega/source/browse/#svn/trunk/test...</a>
<i>It seems somewhat obvious that sooner than later all code will be written in this (or a similar) way.</i><p>LtU is just outright adorable sometimes.
On the problem of using "omega" a its name, I recall a discussion I had, a long time ago, about Zope.<p>Zope is an application server. In a given point in its history, Zope Corp, then Digital Creations, decided to "do it right" and fix each and every design wart from version 2 on version 3. The end result is that Zope 3 is more or less incompatible with Zope 2, specially with the kind of app we were developing with it in 2001 (IIRC).<p>A friend of mine joked Zope 3 should no longer be called "Zope", but, since "Z" is the last letter of the alphabet, the only reasonable choice would be "Yope" and that would suggest a step backwards instead of the jump forward it was.<p>With that in mind, I never built a product whose name started with Z.
It seems nice, but it's more of the same: programming by specification.<p>There's a place for that, but the future of programming languages, in my mind, lies in changing the metaphor of the process from specification to experimentation. After all, the problem with the specification metaphor is figuring out what the specification actually _is_. To me, the best route to get there is experimentation.<p>Make programming more about experimentation and I think we'll get somewhere.<p>(I'm still going to read more about Omega. It looks interesting enough.)
The post is a bit of fluff, but the paper is better. Haskell already has GADTs, as the paper points out. Those of you crying out for examples, just read the paper. The real gem are these extensible kinds, which I haven't seen mentioned in Haskell before.<p>I don't mean to keep throwing water on the fire but the research community already made trees that can't be unbalanced because they wouldn't typecheck, by encoding the depth of the tree into its type. Okasaki demonstrated the concept in Haskell, I believe. Getting it to work for RB-trees sounds new though.
There is a really nice prototype language by Gunther Blaschek also called Omega, and it predates this by at least 15 years.<p>It was Self with mathematical rigor and some MOP elements, IIRC.