What with all the talk about language directions, I was thinking about a hobbyhorse of mine that spreadsheets are proven to be something that a lot of people "get" and that it behooves language designers to pay attention to them. Usually, I speculate about a spreadsheet-like development environment, but in the past couple days I realized that now that Excel has a fully defined XML format, you could do the opposite and write a compiler that produced fully-functioning Excel spreadsheets from a program something like, say:
s = new Spreadsheet();
s.[A1] = 2;
s.[A2] = 2;
s.[A3] = Plus([A1],[A2]);
And stuff like:
foreach(day in myYear){
s.ActiveCell.Row++;
s.ActiveCell = day;
}
It's interesting to think about how to simplify the Excel object model. For interest, what the cell addressing form should be. Something like s.Cells["A"]["1"] would be easiest to implement, but burdensome. Ditto specifying contents. You don't want to say "= Excel.Formulas.Plus, [ ref s.Cells["a"]["1"], etc...."
Further, such a programming language might appeal to newcomers in that it's domain-specific nature allows early production of significant results.