Lambda the Ultimate

The link doesn't work for me.

Just starting on the notes, but I thought I'd break them into pieces as it may take a bit to get them all together.

• AOP: Skeptical about AOP, taking a wait and see approach. Considers it interesting for the prototypical examples of logging, debugging, monitoring, and instrumentation. But is worried about it as a general programming discipline because it makes the code hard to reason about. You can't understand the code without an Aspect IDE. Likes to use any editor for code. Not actively working on AOP for C#. Also says that you can do a lot of the stuff with hosting environments to get transaction guarantees and sessions. Places emphasis on web service environments.
• Dynamic Languages: The differences is in whether variables are typed or not. Thinking about type inferencing in next version. Explains that there are two reasons people like dynamic languages. First, they don't have to declare the type of the variables up front, giving a sort of brevity to the code. Second, the code has a lot of repetitiveness in type information. For example, the declare and assign statement of:
  

     Point p = new Point();
  

  repeats the information of class type Point. Looking at the following type of construct in next version:

     var p = new Point();
  

  where the type of variable p can be inferred from the assignment. Along different lines, also thinking about combining object construction and initialization through and Object Initializers. So instead of writing:

     Point p = new Point();
     p.x = 5;
     p.y = 10;
  

  you could combine the initializers with the object instantiation:

     Point p = new Point{ x=5, y=10 };
  

• Multiple Inheritance: The cop out answer is that if they were going to have multiple inheritance that they needed to have it in version 1.0 of the CLR. It's too hard to add on later. Multiple inheritance would need to be supported in the APIs, which means that it would have to be usable from VB (not gonna happen). Though they are not looking at MI, they are looking at default method implementations on interfaces. The interfaces would still not be allowed to have state. Different from MixIns because the MixIns allow state. Expresses some interest in mixins giving the following example that can't be done today:
  

     class Printable<T>: T {
     }
     class MyForm: Printable<Form> {
     }
  

• isNumeric on String: Question was asked why the string method doesn't have an isNumeric() function. String class is not appropriate place for such function as it would open up to all sorts of other is functions (isDate, isBool). Says that they added a static method to all int32 classes that serves the same purpose:
  

     public static bool TryParse(string s, out int x);
  

• in parameter: Question was why C# didn't have const parameters for methods like C++. Says only reason it works in c++ is you can cast it away when it's inconvenient. Problem is that it would require an attribute on every object about whether it is read/write or a constant, introducing an extra layer of complexity. Also says that every language written for the CLR would have to respect the const declaration or it would be useless. Finally, ends up explaining the difference between in, out, and ref (in/out) parameters and how they are implemented by the compiler.
• intellisense: Question is whether intellisense is bad for programmers (making them lazy). Anders jokes whether the questioner wants to make C# as hard as Java? Gives the analogy of calculators being used for college exams (are we teaching them to add, or are we trying to get them to think at higher levels). Doesn't think memorization is a good thing - better to think about the algorithm itself.
• default parameters in C#: Question is why C# doesn't have default parameters. Hedges by saying that what they thought was important at the time may be less so. Considers it somewhat duplicative with constructor overloading. Original concern was that the default values ended up getting burned into the call site (i.e. the compiler would stick the default values at the point of call). The question turned to whether it was possible to share xml documentation for overloaded methods (says it's not a bad idea).
• edit & continue in C#: Says don't be surprised - that it could happen in the future as the building blocks are there.

Google cache = friend.

Chris, if it only takes a sec to fingerprint the .exe file, would you be kind enough to do so? (Please don't waste time otherwise.)

Some quick notes.

1. Mixins - the solution, based on generics+inheritance, is quite similar to the Ada approach. You can do what he describes on the board with Ada95, today...

2. in/out/ref is quite similar to the Ada approach. However, in Ada you have in/out/in out/access [similar to ref]. The compiler decides how to implement out/in out, whether by passing references or by copy-restore.

3. "We can add value by codifying patterns" - this is a recurrin theme here (recall "mining patterns for langage feaures"), and a nice summing up of their design philosophy.

4. The discussion on database integartion is revealing. This obviously something we are going to hear more about. I am sure Erik can tell us more, but since he hasn't I suggest checking his papers to see were they are heading... It would have been nice to ask him about DSL integration, and plug SchemeQL. Shame no one did..

I agree that codifying patterns is a nice design philosophy, but it can come at the cost of language complexity if the method of codifying patterns is just a bunch of added special forms. What is nicer is if the method of codifying patterns arises from normal language features (thinking of lisp macros here) instead of introducing new keywords and constructs. It's also nice if you can codify patterns without have to rely on the whims of the language designers.

P.S.: I'll try to finish the notes in the next few days. The notes above cover only the first third of the video.