So is Fortress the next big programming tool?
Ok I am going to attempt to distill what I have learnt of Fortress primarily from these slides
Warning : My experience of Fortress so far could be compared to Reading the Haynes manual of a vehicle before driving it. This is not usually a good idea, as all one really needs to get from a to b is to know how to drive. Usually when I do this it I end up disliking a language, as I did by reading BJarne Stroustrup's C++ Programming language (ISBN-10: 0201327554), BJarne may be a programming genius but his book writing sucks. I am however excited by Fortress so here goes.
Why Fortress ? well as you know I am already getting my head down into learning Erlang, the reason being I need another tool in my programming toolbox to handle emerging parallel programming brick wall faced by my current language choices. That is I need an efficient way to write programs that handle multi-cores or multiple processing nodes. Even though I had seen Fortress before I had not taken a deeper look into it. What took me there was a small story of connections :
1 - Jame's Tweeting : mentions Tim Bray
2 - This takes me to Tim's blog, and further this post
3 - Which leads me to Jonathan's post about the Rock
In trying to answer the question Tim Posed : "Rock's secret contest" , I figured the answer was to do with Jonathan's "effortless parallel programming". This reminded me of Fortress and I wondered if Tim and Jonathan were alluding to the research from Fortress resulting to hardware features in the new Rock chip.
So now we have got here I should give you an idea of what I think, First of all I don't understand quite a bit of what I read (thats my get out clause), but from the pieces I did understand I would likely only program in Fortress directly if I was creating a Domain Specific Language (DSL). By that I mean that I see Fortress as a language for creating other languages, rather than something like Java. I see Fortress as an abstract language or even a meta-programming language. That does not mean you cannot use it to program, rather it indicates that the language is designed to be extended or evolved over time. Thus I feel in the future (if it is successful) one would not be directly using Fortress itself but rather using a derivative language that is built on top of Fortress optimised for the sort of problems you are solving.
So for example rather than using a tool like Mathematica, a mathematics domain language could be developed using Fortress called lets say MyMathLang. MyMathLang would inherit some of the key benefits of Fortress like "effortless parallel programming" support (see below) but could be programmed in a language already understood by say the mathematician or scientist using it. This example is a biased choice since many of the language specifics for this domain are already supported by Fortress itself (regular math notations), but hopefully you get my point. One could equally generate a business intelligence DSL for statistically processing massive data stores (a data mining language perhaps).
Underneath it does have some radical stuff, here are some of the cool features :
1) Can be programmed using extended character sets and notations (for example using mathematical algebra) rather than just plain ASCII text.
2) Fortress “loops” are parallel by default (That means all iterations of a loop will be run in parallel across cores or nodes unless sequencing is specified)
3) Multithreaded control model - Basic primitives are tuples and spawn (although spawn should be seldom used)
4 ) Declared distribution of data and threads - Managing aggregates integrated into type system, policies programmed as libraries, not wired in
5) Transactional access to shared variables - Atomic blocks and Deadlock-free, minimised blocking
6) Replaceable components with version control, avoiding a monolithic “Standard Library”
7) Encouraged experimentation - Framework for alternate language designs
8) Unlike java, operator overloading is back with vengeance, Fortress takes it to a whole new level because of the added mathematical notation support.
9) This isn't just a Typed language, it's also a language for types!! It also includes things like dimensions, subtyping, variant subtyping and where clauses
10 ) Distributions - Describe how to map a data structure onto a region (physical store mapping)
11) Reducers and generators negotiate through overloaded method dispatch keyed by traits
to achieve mix-and-match code selection
12) Function contracts : requires,ensures and invariant go way beyond things like Guards in FP
13) Multiple Inheritance of properties via traits or algebraic constraints described by traits
Also check out some key ideas behind Fortress :
• Don't build the language—grow it
• Make programming notation closer to math
• Make parallelism easy to use
Some choice quotes from the slides :
'The language of mathematics is centuries old, concise, convenient, and widely taught'
'Traits: like interfaces, but may contain code'
'Parallel programming is not a goal, but a pragmatic compromise'
'"Loop” can be a misleading term'
So in conclusion is it any good?
Well I haven't actually programmed in it yet so I can't claim practicalities, but I do think it is a very cunning language. I like the way it builds on previous languages and tries to correct limitations that have gone before it, this illustrates real learning from Sun research. But the proof is in the pudding, it relies on a couple of critical events :
1) Building a thriving development community around it
2) Emergence of at least one killer DSL on top of it.
Thus right now it's a bit chicken and egg, you need (1) to deliver (2), but there is a need and that is "effortless parallel programming" with the proliferation of multi-cores and massive compute nodes as well as the new emerging platforms. There has also been a rise in DSLs which work in Fortress's favour, because it's a great new tool for that job. The other side of the coin is can message based and functional programming languages (Erlang/Haskell etc..) beat Fortress to the punch with there own unique styles. To give you an idea of time frame, this is quoted on the slides "This may take years, but we’re talking 2010". For me I think the only anchor point I can boil this down to is DSL versus message based (FP style), It is those primitive competing programming philosophies that are battling here for our future.
Technorati Tags: developers, Fortress, geek