.NET portability is not an afterthought (adding another layer of indirection - Portable Libraries part 3)

Before //build/ I was not aware of the Portable Class Libraries Project. The origin of the project is the notion that the number of platform that provide .NET support has increased from one to four and that this number will increase in the future. Making .NET available on more platforms is the future of .NET.

The Portable Class Libraries Project was the first attempt of solving the portability issue but it ran into some constraints. One of them was the increasing complexity: “Portability is an afterthought”.

After watching some of the presentation at //build/ and experimenting with Visual Studio Express for Windows Developer Preview I thought that the whole purpose of creating a portable library was to bridge the gap between .NET and the WinRT.

This is not the case. Yesterday I watched .NET 4.5: Portable Libraries by David Kean and Mircea Trofin at Channel 9. It all made more sense to me.

 

The show:

• The first 15 minutes explains portability and the first version of the Portable Class Libraries Project.
• 15:00 whiteboard time.
• Explaining the first way to solve portability problem:
• 
• 
• Explaining the problems with System.NET
• 
• 22:00 the new solution: one portable library by design.
• Portability is not an afterthought
• 28:00
  • You program against a contract
  • It is up to the platform to implement the contract
  • Type forwarding:
    
  • You program against the exposed api.
  • 
  • And the GAC will forward to dll that implements the actual code.
  • 33:00 Portability is a first class citizen
• 35:00 It is about granularity a method is too small a dll is too big.
• 36:00
  • Q: Are there two gacs in the Windows 8 world?
  • A: there is one gac. The metro mode is under “us”.
• 37:00 breaking changes:
  • Type
  • 
  • 
• 45:00 Close and Dispose. Close is disposed, no more closing just disposing.
• They reference: A .NET developer's view of Windows 8 app development by Krzysztof Cwalina
• 50:00 .NET has a great future with portability in mind.

So it makes sense to fix and recompile your legacy libraries. You can port them to all platforms that will have .NET available.

Reuse of legacy software by WinRT and Metro (Windows 8) (Portable Libraries part 2)

 

This is a follow up to my previous post Create a Metro App in F# (NOT).

Things become quit complex if you want to reuse your windows legacy software. In this case legacy has a positive connotation. Legacy software is an asset of you and/or your company.

Suppose one want to reuse it and make it available for a Metro app on Windows 8 what are your options? After watching some of the build presentations:

• Windows Runtime internals: understanding "Hello World" by Matt Merry
• Being pragmatic by leveraging existing code in Metro style apps by Jason Olson
• A .NET developer's view of Windows 8 app development by Krzysztof Cwalina
• Ten Tips When Writing a Hybrid Language Metro style Application by Brent Rector
• Using the Windows Runtime from C# and Visual Basic by Harry Pierson and Jesse Kaplan

 

I came up with the following flow chart:

 

So:

• You can reuse html, css and JavaScript.
• I am not an expert on C++, COM, etc. so I do not know.
• If you have only a dll you cannot use it.
• If you have source code that references a language dll (like F#) or have no options today. This will change when the final product becomes available.
• If you want to create a Metro Style project in C++ or JavaScript you can reuse your components code by fixing issues and recompile it to a WinMD file (WinRT component). Some issues can be exposing:
  • non WinRT types
  • non sealed classes
  • non system provided generic types
• If you want to create a Metro Style project and this is one of the .NET languages you can reuse your components code by fixing issues and recompile it to a dll. Some issues can be:
  • Streams

 

Disclaimer: This is my current understanding, based on the presentations I viewed. If you have other information available please leave a note in the comments.

Create a Metro App in F# (NOT) (Portable Libraries part 1)

update January 24, 2013: you are now able to create “Metro apps”: Windows Store Apps with F# (part 1) : Make things as simple as possible, but not simpler.


Today you can follow the all-F# approach (Build MVVM Applications in F#). This is not the easiest way to build a solution, it is not the preferred way, but it is an option.
Don Syme presented last Friday in his build talk the following slide.

When he explained this it was not completely clear to me what this meant.
Does this tell us that we cannot create a F# Metro front-end today but we will when F# 3.0 is ready? Or does this mean that you cannot create a F# 3.0 project and reference it from a C# or a VB Metro front-end app in one solution?
Today I watched some other presentations of day 4 of build:
Windows Runtime internals: understanding "Hello World" by Matt Merry
Being pragmatic by leveraging existing code in Metro style apps by Jason Olson
A .NET developer's view of Windows 8 app development by Krzysztof Cwalina
Ten Tips When Writing a Hybrid Language Metro style Application by Brent Rector
Using the Windows Runtime from C# and Visual Basic by  Harry Pierson and Jesse Kaplan
and experimented with Visual Studio 11 (Developer Preview and Express for Windows Developer Preview).
It became clear to me that you cannot create a Metro style solution that references a project that references .NET dll's that are not part of the .NET Profile for Metro style apps.


The F# dll is one of them today. So creating a Metro app in C#/VB/C++/JavaScript that references a F# project is not possible.
This should be possible when F# 3.0 becomes available. Will it be possible to create an all-F# Metro app in the F# 3.0 time frame? For me, this is still an unanswered question.

Another consequence of this approach: when you intend to reuse your .NET dll's you have to recompile your code as WinMD files. So you need to own the source code.
This are the restrictions:

Update(September 21, 2011):

F# type providers: oData from NuGet

Yesterday F# 3.0 Developer Preview  became available at the MSDN Site. It will be general available on Friday.

One of the new features is the type provider.

This little snippet shows how easy it is to query a site that provides oData. NuGet is an example of a site that provides oData.

Code Snippet

1. #r "FSharp.Data.TypeProviders.dll"
2. #r "System.Data.Services.Client.dll"
3.  
4. open Microsoft.FSharp.Data.TypeProviders
5.  
6. [<Generate>]
7. type NuGet = ODataService<"http://packages.nuget.org/v1/FeedService.svc/">
8.  
9. let dbNuGet = NuGet.GetDataContext()
10. let packages = dbNuGet.Packages
11.  
12. let nuGetQuery =
13.     query { for package in packages do
14.             where (package.Tags.Contains("fsharp") && package.IsLatestVersion)
15.             select package }
16.  
17. let printPackage (package:NuGet.ServiceTypes.PublishedPackage) =
18.     printfn "- - - - - - - - - - - - - - - - - - - -"
19.     printfn "Title: %s" package.Title
20.     printfn "Authors: %s" package.Authors
21.     printfn "Description: %s" package.Description
22.  
23.     
24. nuGetQuery |> Seq.iter printPackage

This is the result:

One of the nice features of type providers is intellisense for the available types.

It is possible to create your own type provider.

More information will be available on Friday. Don Syme will present all the details at build: http://channel9.msdn.com/events/BUILD/BUILD2011/SAC-904T

update: Writing F# Type Providers with the F# 3.0 Developer Preview - An Introductory Guide and Samples

Monads for .NET developers

I have written an article for the Dutch developer magazine of SDN (Magazine 111). It is titled: “Monads voor de .NET-ontwikkelaar”.

In this post I will list some of the available resources on monads for .NET developers:

C# resources

Books:

• Tomas Petricek & Jon Skeet: Real World Functional Programming: With Examples in F# and C#, website
• Oliver Sturm: Functional Programming in C#: Classic Programming Techniques for Modern Projects, website

Web:

• Wes Dyer: The marvels of monads
• Mike Hadlow: Monads in C#–1. Introduction.
• Derick Bailey: Monads in C#: Which Part Is The Monad?
• Matthew Podwysocki: Functional .NET - LINQ or Language Integrated Monads?
• Tomas Petricek: Beyond the Monad fashion (I.): Writing idioms in LINQ
• Mauricio Scheffer: Refactoring to monadic C#
• Erik Meijer: The World According to LINQ

F# resources

Computation Expressions are addressed in most of the available F# books (Professional F# 2.0 does not): F# and functional programming

Web:

• Wiki: Computation Expressions
• Don Syme: Some Details on F# Computation Expressions
• Francois Vanderseypen : Categories, monads and F# for dummies
• Steffen Forkmann: Using monads in F# – Part I: The State Monad
• Brian McNamara : catamorphisms part seven
• Ivan Towlson : F# computation expressions for beginners, part 1: what’s the problem?
• Chance Coble: Why use Computation Workflows (aka Monads) in F#?
• Ryan Riley: A monad library for F# projects

Presentations

• Mike Hadlow: on Monads @ E-VAN 29 March 2011
• Robert C. Martin (Uncle Bob) at the Norwegian Developers Conference: “WTF is a Monad” (F# code)
• Erik Meijer: Fundamentalist Functional Programming & Chapter 8 - Functional Parsers
• Bart De Smet: LINQ, Take Two: Realizing the LINQ to Everything Dream
• Rick Minerich: Getting the MVVM Kicked Out of Your F#’n Monads

Some theory

• Wiki: monad
• Monad tutorials timeline
• Eugenio Moggi: Notions of Computation and Monads
• Real World Haskell: Chapter 14. Monads
• Learn You a Haskell for Great Good!: A Fistful of Monads
• Ertugrul Söylemez: Understanding Haskell Monads

Code:

The source code of the article: MonadsVoorDeDotNetOntwikkelaar and MonadsVoorDeDotNetOntwikkelaar_english

The newbie feeling

I read a blog post:http://blog.recursivity.com/post/9204470867/the-problem-with-the-scala-community that triggered me to write this post.

I do not know the Scala community so I can not agree or disagree with the conclusion:

“I love the Scala community and the eco-system around the language, but quite frankly, to foster the continued growth of the community, we need to call out the small minority of bullies on their bullshit whenever it occurs: being able to confuse and intellectually intimidate newbies to the language and community is not proving your supposed “intellectual superiority”, it is merely a reflection of an insecure ego and social incompetence.”

I do think that as a person we can not know everything of everything and even if we could one moment in time the world will change and we have to learn the new thing.

So we have two option: stick with what we know or accept the newbie feeling.

When you are a newbie you will make mistakes. My grant parents had the following text on a tile:”The only man who never makes mistakes is the man who never does anything.” I just found out it is a quote from Theodore Roosevelt (thanks Google).

So if we want to progress we have to accept the newbie feeling, accept the insecurity and make mistakes.

When we want to progress we have several options, one option is to learn it all by yourself, another is to accept the support of the community.

The community can support you in two ways:

• one is provide knowledge
• the other to provide mentorship

I think a programming language community is able to provide knowledge, that is nature of the community. To provide mentorship is something else and it is very hard to provide it on line.

So as a newbie look for knowledge on line and find mentorship somewhere else.

The difference between SelectMany and Select in LINQ

This is follow up on my previous blog post:Adding xml strings in C# using LINQ.

In the previous post I showed that LINQ can be used to to manipulate XElements and strings. LINQ managed the transformation between the classes.

XElement result =
  from x1 in el1
  from x2 in el2
  select x1.Substring(0, x1.LastIndexOf("<")) + x2.Substring(x2.IndexOf(">") + 1);

el1, el2 and the result are XElements and x1, x2 and the object before select are strings.

In the example there are two XElements and the compiler requires that we implement SelectMany. If delete SelectMany we get the following error:

In case we have one XElement we expect that the following will compile:

private static XElement ToUpper(XElement el)
{
  XElement result =
  from x in el
  select x.ToUpper();

  return result;
}

It does not: “'System.Xml.Linq.XElement' does not contain a definition for 'Select'”

So we implement Select:

public static XElement Select(this XElement el, Func<string, XElement> f)
{
  return SelectMany(el, f, (x, y) => y);
}

Again it does not compile: “Cannot implicitly convert type 'string' to 'System.Xml.Linq.XElement'”

So we add an extra conversion:

private static XElement ToUpper(XElement el)
{
  XElement result =
  from x in el
  select XElement.Parse(x.ToUpper());

  return result;
}

This time it works:

var el = XElement.Parse("<a><b>1</b><b>2</b></a>");
Console.WriteLine(string.Format("ToUpper: {0}", ToUpper(el)));

Results in:

as expected.

Another way to solve the issue is to add a dummy line and use SelectMany:

private static XElement ToUpper(XElement el)
{
  XElement result =
  from x in el
  from dummy in XElement.Parse("<dummy></dummy>")
  select x.ToUpper();

  return result;
}

with the same result.

Update: more information at: http://msdn.microsoft.com/en-us/library/bb546168.aspx