- Published on 2008-09-30
- 1 comments.
- Tagged: General technology, .NET
50 in 50
This was todays keynote by Richard P. Gabriel and Guy L. Steele Jr. Before the talk, there had been some speculations about the title; was it 50 programming languages in 50 minutes ? Or what did it mean exactly ? It turned out to be 50 comments about programming and programming languages, in 50 minutes. These focused on the history of programming and did so in an entertaining and enlightening manner. This was a certainly a great talk - and for a "young" programmer like my self what was not even born when Ada and Algol 60 appeared; it provided also some historical insight. Only downside to this talk, is that the schedule was affected by the fact that it was more like 50 in 75 - the talk took about 75 minutes; but with this quality of technical and on the same time entertaining talk, that does not really matter for me.
This was also a dual talk with two presenters - Frank Bushmann and Kevlin Henney. They talked about architecure and specifically five considerations that drives design quality. Those were:
- Economy - the idea that software must be built for a reason and should not have an complicated or elaborate design just because it *might* be needed in the future.
- Visibility - in the sense that the design must be easily discoverable.
- Spacing - basically the idea to separate concerns and make sure not to bake the design into deep inheritance hierarchies that xould better be expressed with composition.
- Symmetry - in that API's should be symmetric with the example that if you can create something with a Factory, said Factory should also be able to destroy it
This talks title is actually wrong, since Erik Meijer primarily talked about LINQ, and very little about "New Microsoft Things". To be fair, he did not have much time to cover it all since the talk got started late because of the schedule slip at the keynote earlier on the day. LINQ was covered well, however, and from a slightly different angle than Anders Hejlsberg talked about earlier in the week. Erik talked about Expression trees and how they represent code as data. This makes it possible to hand an expression tree to an interpreter for a given query language, that can then execute it in the given domain. This is why we (in theory) could forget all other query languages such as XQuery or SQL, and only use Linq-to-Xxx - given that someone writes a Xxx extension to LINQ, of course.
This talk about Refactoring by Neal Ford addressed the challenges that goes into actually performing refactorings in code. It was very hands-on and offered some good advice on how to structure refactorings. One of the best pieces of advice, I think, was to time-restrain major (multi-day) refactoring efforts to an estimated period of time before-hand. If you cannot complete the planned refactoring in the planned time, take the time to rethink the problem, and find out if you are doing it right. If not, you can throw the refactored code away and try again, instead of keeping on a track, that might resolve to more complicated code than before; because new knowledge has beeng gained during the process or because the refactorings was not well enough planned and thought out in advance.
In this talk, Joe Duffy, gave an introduction to the parallel extensions to .NET, a new API for writing concurrent applications with .NET. These extension is in CTP right now (so it's preview technology, not recommandable for production use). Joe promised though, that these APIs will be part of the .NET Framework version 4 release. These new APIs promise to make it easier to write concurrent applications with .NET with little overhad, both mentally for the programmer, but also performance-wise for the machine. The presentation featured running demos and code, and I believe that the new APIs are quite well-designed and that there is definitely a need for this kind of API in todays world of multi-core hardware. However, as Joe pointed out, there is no such thing as a free lunch; and even when using this API, of course you need to think hard over concurrency issues and side-effects before you can put it to use. The system makes it easier for you to program concurrently; but you can still fail badly if you do not understand what it does under the covers.