Otaku, Cedric's weblog

A Fortress overview

I was quite excited to learn about the announcement of Fortress, a new language from a team that includes Guy Steele, Common Lisp guru and famous author of the Growing a Language paper.  It's not very often that a new language comes out with a PDF documentation of more than a hundred pages describing both the intent, philosophy and gritty details of the various features.

I was also curious to see how many of the ideas that Steele put forth in his seminal paper he was able to apply to this new language. 

Quite a few, it turns out.

If you are a Java / C# / C / C++ developer, here is what you might want to know about Fortress.

• Fortress is an attempt to replace Fortran.  I know, it doesn't sound very good, but it's not too bad, really.  While Fortress has an undeniable bias toward a few mathematical constructs (such matrices and the fact that * is optional) and its documentation contains some scary looking words such as "Abelian group", the end result is actually quite pleasing to the eye and features a few pioneering language constructs that are worth a closer look.
   
• Fortress uses the full extended Unicode character sets, which means you can use all kind of strange characters such as Θ, ←  or ∈.  It's quite surprising at first but you get used to it really quick and I have no doubt that's what all languages of the future will look like.
   
• Fortress is strongly typed but uses type inference a lot, like Haskell and a few other functional languages.  In other words, you never need to specify a type when the compiler can guess it for you.
   
• Fortress doesn't have classes, it has object and trait, which is an interesting mix of of the traditional and prototype approaches.  Traits are like Java interfaces except that you can also specify concrete methods in them (a similar concept as the one found in Objective C).  Fortress also has an hybrid keyword called api which is like a trait except that it can only contain abstract methods.  I have to say this throws me off a bit.
   
• You can use named parameters to invoke methods.
   
• It supports design by contract with ensures, requires and invariant (I'm not a big fan of DBC myself).
   
• There is a mysterious dispatch keyword that allows you to select on object types.  Not quite sure what this does exactly, I'll have to get back to it.
   
• You can mark methods with test.  Again, I'm not quite convinced this kind of thing should be part of a language, but well, I am promoting the use of annotations to do that myself, so I guess it's a small leap of faith.
   
• Fortress has support for automatic forwarding.  This is very interesting because the way this is implemented is almost identical to the way I suggested doing it a long time ago (in 1998!) in Java.
   
• Fortress has extensive support for futures and asynchronism.  It goes much further than Java and its thread support, even with the java.util.concurrent package.  Fortress is clearly geared toward making heavy computations, so this makes perfect sense, but the documentation gets a little bit abstract in this area, using sentences such as "asymptotic behavior of parallel code space".  Don't let yourself impressed, there are some truly interesting ideas.
   
• Finally, Fortress delivers on the promise of making the language "growable", a page from Guy Steele's own book.  The way this is accomplished is by allowing developers to specify entire abstract and concrete syntaxes in Fortress itself, which is quite a tour de force (and as a matter of fact, the documentations shows the Fortress grammar in both EBNF and concrete syntax Fortress notation).
  
  Even though I have a lot of sympathy for the concerns expressed in Guy Steele's paper about letting the door open to evolve the syntax of a language, I am still skeptical that this is what will make your language stand the test of time.  Historically, languages have come and gone not because of their syntax but because they were no longer semantically adequate to address modern problems.  The only way you could actually make a language that flexible would be by fitting it with a meta-object protocol, but that's a path the Fortress team decided not to take, although their concrete syntax extension might possibly be used to that effect.

Obviously, I don't think Fortress is perfect, and there are a few things I dislike about it.

While I respect immensely the freedom of language authors to experiment and pioneer new concepts or introduce marginal ones, I still think there are a few compromises that should be made.  Some languages sometimes exhibit keywords or constructs that are clearly meant to do exactly the same thing as their predecessors, except with a different name.  Eiffel was notoriously famous for this (e.g. using /= instead of the more familiar != or even <>), and unfortunately, Fortress suffers from some of these vanity problems as well.  It's not as bad as Haskell, though.

For example, Fortress uses the mysterious bounds instead of the more familiar enum, and it differentiates assignment from equality (like Pascal's = and :=).  It also uses do and end to surround blocks (I happen to think that these words clutter the code and that symbols should be used instead, or space-significant indentation, but that's just a personal preference).  Fortress also decided to declare the type after the variable (x : Int), which takes some time to get used to after all these years in C, C++, Java and C#.

Overall, Fortress is a very interesting language that has great potential to succeed to Fortran.  I have a couple of concerns regarding its acceptance as a general purpose language such as Java or C#, though:

• It only has weak object-oriented support and lacks a few important features (no property support, for example, although this would be trivial to add with the concrete syntax extension).
   
• Its native support for numeric calculation might turn off the more general developer crowd and make it look marginal.

At any rate, Fortress is an impressive achievement, both in terms of breadth and documentation (Groovy people, please learn from this!).

I'll be keeping an eye on Fortress and I am wishing the team the best luck, they deserve it.