HTML 5 is not SMART - 5/30/2010

As we all learned the hard way with the Netscape vs IE wars of past, web standards are a good thing.  Standards produce better results for end users and save money for those paying for development. 

Unfortunately, the lessons learned recently have been forgotten with the creation of the HTML 5 specification.  This goal completely fails the SMART test.  Smart goals should be

Specific
Measurable
Attainable
Realistic
Timely

S- Is it Specific?
Their aim is to "reduce" the need for plug-ins for Rich Internet Applications such as Flash and Silverlight.  In my opinion, the term "reduce" is very not-specific and additionally the mere fact that the standard won't be done for 12 years(year 2022) means there is a lot that is up in the air for a very long time.  Additionally, even in the areas that are finished the vendors have differing definitions of how to build standards compliant browsers.

M - Is it Measurable?
Reducing the need for something is not a specific goal.  Reduce it by how much?  Additionally, how do you measure compliance against a standard that is not yet finished?  You are aiming at a moving target. 

Attainable
The fact that the standard will take over a decade is pretty good evidence that they have bitten off more than they can chew.

Realistic
The 10 year time frame suggests this was not a realistic goal. 

Timely
10+ years from now is a very long term goal.  Given how fast technology advances the standard may well be obsolete before it is ever finished.  By 2022 when the standard is finished the definition of what a web browser is and how we use the internet is likely to be very different.

Since we won't have a "finished" standard for 10+ years this means we are going to once again have the Wild Wild West where each browser will have different support for the standard.  Maybe Safari will support something but nobody else does, or they do so differently.  This is exactly the reason why standards exist is to prevent this type of thing not to encourage it.

The W3C would have been much SMARTer to pick a shorter term, more attainable, more realistic, more timely goal.  Break the "ultimate vision" into bitesize pieces that can be delivered in a realistic time frame. 

VB9 vs VB10, Lambdas Evaluation - 5/7/2010

Our team recently encountered a rather interesting issue with lambda syntax when upgrading from VB9 to VB10.  This question was researched and an answer was found(use sub instead of function).  However, as a programmer I wanted to know and understand the difference of when to use sub vs function in lambda statements.  I submitted the question to the VB Team and was stunned that none other than Lucian Wischik, the VB Spec Lead fielded my question. Below are his notes with additional explanation weaved in for context.   

VB 9 vs VB10

Microsoft and the VB.Net team have done a very nice job with improving the Visual Basic.Net language in .Net 4.0.  Without question VB9 had countless flaws that annoyed developers that have been resolved in VB10.  Among the many improvements are nice features such as autoproperties, no longer needing line continuation characters, and additional options for how you may implement lambda syntax.

How Lambda statements really work

The .net framework itself is unaware of lambdas, a lambda is nothing more than a shorthand syntax that the compiler sees and then uses to emit a method that is called by a delegate.  When using a lambda the compiler is actually using one of the below types of delegates

Types of Delegates

Action encapsulates a method that has no return value and acccepts 0-4 parameters
Predicate encapsulates a method that returns bool and accepts 1 parameter
Function encapsulates a method that returns any type and can have 0-4 parameters

The Problem:  When using a lambda statement, which delegate is the compiler creating?

When using some libraries(ex RhinoMocks) it actually is important WHICH type of delegate your lambda creates and because you now care about this.  For example, the AssertWasCalled method of RhinoMocks has identical overloads except one accepts a Func and one accepts an Action.  In VB9 the compiler was able to figure it out but in VB10 the compiler, using different logic, was not able to determine the difference between the two overloads and to know whether to use the one with Func or the one for Action. 

New Lambda Syntax options in VB10

In vb9 the only lambda syntax available was Function(x) x.SomeMethod.  This had an obvious drawback that the method in the lambda could not be a void method(aka Sub in VB).  In VB10 this was resolved by allowing a Lambda to also be stated using the Sub keyword, ex Sub(x) x.SomeMethod.

Reasons for Change in Lambda Behaviors between VB9 and VB10

  1. If the argument was not an exact match in VB9 the compiler will settle for some second-best.  In VB10 thanks to new language features there are additional "second best" overloads that are deemed equal.
  2. Generic co and contra variance means that Func(of TDerrived) now has a widening conversion to Func(of Tbase)
  3. Fixed bugs in VB10 with "delegate relaxation" to better conform to VB spec.  This was due to some framework classes such as the Task Parallel Library having lots of overloads that accept delegates.

When to use Sub vs Function for Lambdas in VB10

All of this techno-geek speak can be boiled down to one very simple, elegant and easy to understand answer.  When using lambdas, use Sub for anything that expects a System.Action and use Function for anything that expects a System.Func

Other Notes from Lucian

  1. If you use a function-lambda in a context that is expecting an action, the return value is dropped so there is no difference.  This means you can use them, it will compile and work provided there is not a collision in overloads
  2. In cases where the lambda has already been constructed by an earlier statement, dropping the return value costs some extra work.
  3. In cases where the return value is dropped immediately there is no inefficiency

Is there a future for Linq2SQL - 3/25/2010

Back in 2008 the ADO.Net team announced that moving forward new feature development would be focused towards the Entity Framework solution and not towards Linq2SQL. Given this kind of announcement you would expect developers to be abandoning the use of Linq2SQL.  However, 2 years later in Scott Hanselman's poll of what tools developers are currently using Linq2Sql was twice as popular with developers.

From personal experience the popularity of Linq2SQL and the lack of adoption for EF is consistent.  I know many who are using Linq2SQL happily, in production applications and have yet to meet anyone who is using the Entity Framework in production. 

Fact is that Linq2Sql works and works well for many users.  Linq2SQL, is still fully supported in .Net 4 so worst case scenario it may be depreciated in some later version of .Net but that is at least a few years out, it would still have to be supported due to the size of the userbase and by the time it is no longer supported there will likely be different choices in the ORM field to make a fresh decision with. 

Kind of makes me wonder if the Entity Framework may become yet another vista or if over time the adoption rate will improve.