DeskToppie und Webbie .NET Programmierer

Get the latest wave of Windows Live application (in Beta)

2008-10-03T12:59:00Z

Funny, now the Windows Live applications and services seem to be in one version sync: version 14.

Get the full standalone of 110MB here:

http://download.microsoft.com/download/7/6/E/76EE3260-D212-4D9B-B8D6-79C014B0593B/EN/wlsetup-all.exe

So, what really is this hefty one package? It contains:

Windows Live Writer Beta
Windows Live Messenger
Windows Live Mail Beta
Windows Live Toolbar Beta
Windows Live Photo Gallery Beta
.. and this strange for me, Windows Live Call Beta. I think it's Microsoft's answer to Skype.

… And they all have the same version: version 14.

Here’s the snapshots:

Windows Live Messenger 14:

Windows Live Writer 14:

Windows Live Mail 14

If some of you may ask, why do I show Windows XP? I need to inform you that you can still install these damn useful applications on Windows XP SP2, and on Vista of course. I suggest, on Vista though. You already have .NET 2.0 on Vista with added twists of security and reliability. :)

Funny or maybe not finished? The Windows Live Writer editor doesn’t recognize the CSS of my blog. Hope they will fix this.

Ah, by the way, Windows Live Writer needs .NET 2.0 runtime. And if you don’t have it, it’s already included in the standalone installer. Enjoy!

Share this post: | | | |

RESOURCE: Free .NET Zero ebook by Charles Petzold

2008-07-17T04:04:52Z

I know, it's quite old but it's still relevant, even today in the world of .NET 2.0, 3.0, and 3.5.

What the C or C++ Programmer Needs to Know About C# and the .NET Framework

Enjoy reading! :)

Share this post: | | | |

Silent scream revisited, and there are many who really cares about our education! (silent scream part two)

2008-05-21T10:49:07Z

Yes. Why do I say many cares? Just a day after I wrote my latest blog entry about the first silent scream, some of my colleagues gave me supports, including many of my colleagues from Indonesian OMG BMI members. Wow! They even offer me many samples of syllables from many Australian universities, for comparison resources.

Some of them were willing to pour some real cash to accelerate this. But not so fast, though. We need to form a specific "organization", since then it's not an initiative from RX Communica anymore. Basically, they agreed. It's also being considered as a non-profit organization, and there should be no hidden agenda at all, no dependency or dominance from a single company.

Ahh, it may sound easy to say than to really form it. At the same time, while my friends and I are still considering many options, those guys that interested in funding approach me. But, they have to agree on stricter term, especially on these fine prints: "non profit, no dependency and dominance". Few of them backed off.

Funny thing is, some of them thought that we were building a promising startup, just like the story behind the fever of startup on the dusk of web 2.0 bubbles.

Simple answer is: No. We are not building a startup. We're not tied as a promising newcomer for many VCs. Yes, we're concerning about software development in general, and our main target is preparing young talents to be aware of the latest software development theory and best practices, also giving them experiences on real projects.

A first, the base camp is on RX Communica. Later when the need (and also funding) are sufficient, we'll have our own base, since we've agreed about no dominance, even for RX Communica and also my friend's company. We don't know yet the name. :)

Many thanks for you guys, especially from Indonesian OMG guys and my silent scream fellows on Kalimantan. Next, since this topic is no longer about .NET, I'll migrate it to a new host, or maybe I'll use any other free blog services for this time being. Or, do any of you, this blog's loyal visitors, want me to report it here? I will, if you want to. But I'm afraid it'll be less .NET content. :)

As Aerosmith sung:

"It's amazing! With a blink of an eye, we finally see the light..."

Again, many thanks.

Share this post: | | | |

LINQ, Lambda expressions, functional programming, F#, C# 3.0, VB 9.0 and what the heck of these guys are related? (part two)

2008-05-13T09:02:00Z

Update:

May 147h, 2008: revisiting local type inference and more clarification on VB and C# feature comparison

Close view of Lambda Expressions and the journey to LINQ

Now, what's really a lambda?

According to MSDN Library that comes with VS 2008, a lambda expression is "an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types." That's a mouthful description.

First, an anonymous function. Function, in a sense of C# and VB.NET, is simply a method that returns any value. In VB, it's more verbose, it uses keyword Function. It can be seen as a further development of anonymous method, only it's more like syntactic sugar, since it's more expressive.

Before enjoying this journey, C#3.0 and VB 9.0 new features are not LINQ alone. Many new features of C#3.0 and VB 9.0 forms (or compose) LINQ.

These are:

Query expression (or query comprehension)
Local variable type inference
Lambda expression
Anonymous types
Object initializers
Expression tree

Now grab your popcorn, relax and stay sit. :)

Before Lambda expressions, and others, there has been impedance mismatch of data and object

Now, let's see... The roadmap to the query expression of LINQ. Yes, the journey behind it. You can also see the movie about it on LANGNET 2008 website in Talks section. But for those prefer to seek another way to crunch this concept, let me enlighten you. :)

It all starter when these things happened: "impedance mismatch of objects and relational data".

Or, easily put by Anders Hejlsberg and others:

relationaldata != object

Remember XBase family software such as dBASE, FoxBase (then FoxPro and then Visual FoxPro and then "gone")? Yes, they were neat, if you need to access data, it's so simple. You got the feeling that the data was there, integrated with your language you're coding. It's also giving you compile time errors on query (although there were no such thing like Intellisense). They were also fun to use, since you're concerning only on "what" data you want to display, instead of concerning "how". And the database world has grown not just simple query, but it's grown into a standard based SQL, at least ANSI SQL-92.

The separation grew larger, since the difference was more obvious:

Database is relational, object is hierarchical,
Database has nullable types, object didn't have it.
Database has indexes, primary keys, object didn't have it. But this was solved by major ORM, including #1 above, but not #2.

The long road to marry data and object

Luckily, in CLR 2.0 (also C# 2.0 and VB 8.0) we have Nullable value type, which can be simply written int? in C# or Integer? in VB. Now, we know then, at least in .NET 2.0, we have matched types from database domain.

What about query in our programming language? It's simply can't match the power of the domain specific language such as SQL. Yet, we still need to work at the heart of our general programming language discipline first, the object itself.

The journey of those thinkers in Microsoft is illustrated below.

Suppose I want to query an arbitrary collection in .NET, and later I want to make it "fluent" and looks like query I used to know. Why? Because basically a table is a collection of rows, and this collection can be a CLR IEnumerable<T>.

Now, let's do a simple query of available processes on my machine, and then print it on console.

In C# 2.0:

IEnumerable<Process> processess = Process.GetProcesses(); foreach (Process proc in processess){    Console.WriteLine(proc.ProcessName);}Console.ReadLine();

In VB 8.0:

Dim processes As IEnumerable(Of Process) = Process.GetProcesses() For Each proc As Process In processes    Console.WriteLine(proc.ProcessName)NextConsole.ReadLine()

Oh, what about if I want to know which processes on my machine have size > 50MB? Sure I could add if statement that filter the proc in Processes before I display, like these:

in C# 2.0:

IEnumerable<Process> processess = Process.GetProcesses(); foreach (Process proc in processess){    if (proc.WorkingSet64 > (50 * 1024 * 1024))        Console.WriteLine(proc.ProcessName);}Console.ReadLine();

in VB 8.0:

Dim processes As IEnumerable(Of Process) = Process.GetProcesses() For Each proc As Process In processes    If proc.WorkingSet64 > (50 * 1024 * 1024) Then        Console.WriteLine(proc.ProcessName)    End IfNextConsole.ReadLine()

But, this is the query that I want. A query is not like these. I decide to implement Where as a method. But how do I pass expression to be later evaluated and spawned as iterators? Fortunately, C# 2.0 has a new keyword of C# "yield" to have the compiler generates iterators. But sadly enough, VB 8.0 doesn't have it. But you can code it in C# and use it in VB anyway.

Note: This is where the language features of C# and VB seems having unfair advantages: the yield keyword is only available on C#. Why doesn't MS include this in VB? I can't find the reason anywhere, even on MSDN.

After I think for a while, I decide I have to put these into a method with accept generic. Ah, this is a suitable implementation for .NET 2.0 anonymous generic delegate. I think I want a class that contains method that can be called anywhere, and this is definitely a static class.

So, I modified my code to add this class, let's just call it Query. And the method to filter, let's just call it Where. It's perfectly suited for our intent: to filter out elements/items and make new collection with filtered items.

But first, I have to make declaration/definition of the delegate:

public delegate TResult Func<T,TResult>(T arg);

And now, here's the resulting Query class with Where method in C# 2.0:

namespace TrialLINQinNET20{    public delegate TResult Func<T,TResult>(T arg);     public static class Query    {        public static IEnumerable<T> Where<T>(IEnumerable<T> items,Func<T,bool> predicate)        {            foreach (T item in items)            {                if (predicate(item))                    yield return item;            }        }      } }

Now, my query somehow looks nicer:

In C# 2.0:

IEnumerable<Process> processess = Process.GetProcesses(); IEnumerable<Process> listproc = Query.Where(processess,     delegate(Process p) { return p.WorkingSet64 > (50 * 1024 * 1024); });foreach (Process proc in processess){    Console.WriteLine(proc.ProcessName);}Console.ReadLine();

In VB 8.0, I can't. It simply doesn't support anonymous functions, and this including anonymous delegate.

Note: This is another aspect of VB 8.0 having unfair advantages: the anonymous delegate/function is only available on C# 2.0. Another "why doesn't MS include this in VB". But in VB 9.0 it's being done as a lambda expression in a more verbose way.

Now, I have created filter or "map" in functional programming terms. I passed the predicate as expressed in delegate.

To tell you the truth, I copy the declaration of Func<T,TResult> delegate from MSDN Library.

What about Select? If you look at the base theory of SQL, it's called a projection. As a matter of fact, projection, filter, and others are essentially part of relational algebra. And it's fun to know that it's part of set theory, which we had in elementary school. :)

Now, let's create a select method. Basically, it projects a collection of type into other collection of type. It can be the same, but it can be different. It looks almost like Where, but I have to change and modify the signature of select method to be able to map IEnumerable<T> to another type.

This is the select method:

public static IEnumerable<U> Select<T, U>(IEnumerable<T> source, Func<T, U> selector)

    foreach (T var in source)

        yield return selector(var);

Yes. Now, if I want to display (and select) only the ProcessName of the running process that has taken more than 50MB of my precious RAM, the code will be:

IEnumerable<Process> processess = Process.GetProcesses(); IEnumerable<Process> listproc = Query.Where(processess,     delegate(Process p) { return p.WorkingSet64 > (50 * 1024 * 1024); }); IEnumerable<String> procnames = Query.Select<Process, String>(listproc,    delegate(Process p) { return p.ProcessName; });foreach (String procname in procnames){    Console.WriteLine(procname);}Console.ReadLine();

Now... I see the class and the code is simpler to be read. I can map a collection of Process into a collection of String, since I only need to dump the ProcessName.

Please note the sequence here: I need to filter it first, then map it. If I map first and then filter it, I'll loose some information about the data (type metadata) in the collection. So where comes before select! This is different from SQL, since SQL permits select first and then filter it, and then take from a pool of data. In OOP, we have to know from what data we want to use, filter it, and then map it.

SQL seems to cook up structural type before "from" was taken place.

Local type inference revisited...

Hmm... This is somehow satisfactory, but it's full of syntactical noises, where I have to type full type declaration, especially if I have to type long type declaration of generics.

The variable's type on the left side of declaration is already known after I initialized or have been assigned with a value.

Now this is where I begin to use C# 3.0, .NET 3.5, and Visual Studio 2008, since it can infer the type of local variable. Only, it means available only on local variable of method scope. This is why it's simply named "local type inference".

Instead of writing this:

in C# 2.0:

Dictionary<String, List<Int32>> integerdict = new Dictionary<string, List<int>>();

in VB 8.0 it's somehow shorter:

Dim integerdict As New Dictionary(Of String, List(Of Integer))()

And C# 3.0 brings you:

var integerdict = new Dictionary<string, List<int>>();

Again, it means give integerdict the type of the right hand assignment or expression has. It's neat, and it's simpler.

It's still statically typed, since by then the type of integerdict is always Dictionary<string, List<int>>. Yes, it looks like dynamic language, but it's not dynamically typed, and it's not the same as Variant in VB or object in Javascript.

Now, in C# 3.0, my little query class and its implementation is:

var processess = Process.GetProcesses();

var listproc = Query.Where(processess,

    delegate(Process p) { return p.WorkingSet64 > (50 * 1024 * 1024); });

var procnames = Query.Select<Process, String>(listproc,

    delegate(Process p) { return p.ProcessName; });

foreach (String procname in procnames)

    Console.WriteLine(procname);

Console.ReadLine();

Pretty neat, isn't it? But this is not query. In real query, I just can combine Where and Select. So, the procnames is a select of filtered data of process.WorkingSet64 > 50MB. How do I do this?

Then I decide to just passing the where to my projection:

var processess = Process.GetProcesses();

var procnames = Query.

    Select<Process, String>(Query.Where(processess,

    delegate(Process p) { return p.WorkingSet64 > (50 * 1024 * 1024); }),

    delegate(Process p) { return p.ProcessName; });

foreach (String procname in procnames)

    Console.WriteLine(procname);

Console.ReadLine();

But now it looks confusing. In reality, I should filter it first and then map it. Do where first, and then select it. The execution order is correct, but I can't just make it into a sequences.

I was thinking about extending IEnumerable to be able to do query, something like IQuery but it has to be concrete class, not an interface. But then again, it's not so practical.

But I think it would be nice to have this notion: procname.Where(...).Select(...) instead of having to combine Select and Where just like above. In programming buzzword, this way of thinking is called "fluent", since the data/value passed flows like fluid, although it's still to be arranged in a sequence.

Simple sample of fluent thinking:

String name="Eriawan  ";String upperstring = name.ToUpper().Trim();

See? The string is passed. Now, it's more fluid.

Ahhh, it's "fluent" now

Luckily, there's this feature: method extension in C# 3.0 and VB 9.0. I can just "extend" existing class especially "locked" class or classes which has modifier of sealed in C# or NotInheritable in VB.

How to do this?

In C# 3.0:

Create static class with static methods, with the first parameter is the type you want to add method.
Put "this" keyword in the first parameter of the static method

In VB 9.0:

Create new module
Create method (either Sub or Function) with Public modifier and give the method <Extension()> attribute

And you're on!

So, my Query class in C# 3.0 would be:

public static class Query

    public static IEnumerable<T> Where<T>(this IEnumerable<T> items, Func<T, bool> predicate)

        foreach (T item in items)

            if (predicate(item))

                yield return item;

    public static IEnumerable<U> Select<T, U>(this IEnumerable<T> source, Func<T, U> selector)

        foreach (T item in source)

            yield return selector(item);

        //return source;

Now, the implementations will be:

var processess = Process.GetProcesses();

var procnames = processess

    .Where(delegate(Process p) { return p.WorkingSet64 > (50 * 1024 * 1024); })

    .Select(delegate(Process p) { return p.ProcessName; });

foreach (String procname in procnames)

    Console.WriteLine(procname);

Console.ReadLine();

Yayy! It's more fluent! But... I think it's still noisy. Just look at the delegate syntax on Where and Select. It's simply a function with a parameter and an expression. I want to be more expressive.

Now is the close view of Lambda

Now, this is where Lambda Expression comes to help. Lambda expression, as Norman said in commenting blog entry :), is just basically writing inline function. Lambda expression is just a simple synonym of Lambda Calculus, which is one of the basic of functional programming.

Let's just go down to transform our delegate parameters above, into these:

var procnames = processess

    .Where((Process p) => { return p.WorkingSet64 > (50 * 1024 * 1024); })

    .Select((Process p) => { return p.ProcessName; });

The fat arrow "=>" is "goes to". It can be simplified as inline function that has parameter p and then "p -> p.ProcessName".

Thanks to local type inference, the lambda parameter type can be omitted:

var procnames = processess

    .Where((p) => { return p.WorkingSet64 > (50 * 1024 * 1024); })

    .Select((p) => { return p.ProcessName; });

If the parameter is just one, the parentheses () can be omitted too. Also, since the return value is just a simple expression, I can just make it more expressive and looks more functional instead of writing an imperative return statement.

Now the code above looks like this:

var procnames = processess

    .Where(p => p.WorkingSet64 > (50 * 1024 * 1024))

    .Select(p => p.ProcessName);

Now, the noises are gone. My code looks functional!

But it's still not the query I used to be, I know it's closer. It would be nice to have select and where as keywords, and be integrated into our code.

Now, C# 3.0 and VB 9.0 include this new feature: query comprehension.

Query that is so integrated into our code: Query comprehension

The code before now is transformed using this query comprehension into:

var procnames = from p in processess

                where p.WorkingSet64 > (50 * 1024 * 1024)

                select p.ProcessName;

and in VB 9.0:

Dim procnames = From p As Process In Process.GetProcesses() _

            Where p.WorkingSet64 > (50 * 1024 * 1024) _

            Select p.ProcessName

But the LINQ wave doesn't stop here! There are many other discrete cool features in C# 3.0 and VB 9.0 that forms LINQ.

(to be continued...)

Share this post: | | | |

A full speed ahead of 3G in this afternoon! Is it real?

2008-03-29T05:42:55Z

I was in the middle of downloading screencast from Channel9 of MSDN and also finishing my part 2 blog.

To my surprise, the 3G connection went so fast! Many thanks to my XL 3G for this connection:

Before this, I always complained to them about how slow it was.

But right after that, I test the real speed using intel bandwidth test:

It looks like I only have a quick surge of 3G speed. Well.. For this speed, it's still slower thean my ISDN connection at home. But, anyway, it's fun to test the real speed. Also, maybe I should sample more test.

I have tested it again many times, and this is what I got an average of 72kbps out of 5 times testing:

So, what I got is a quick surge of 3G speed. Has any of you experienced this phenomenon too?

Share this post: | | | |

LINQ, Lambda expressions, functional programming, F#, C# 3.0, VB 9.0 and what the heck of these guys are related? (part one)

2008-03-22T22:33:00Z

Yeah. I know. It's quite noisy, either in INDC's mailing list, or in many web that says cool features in VS 2008.

But let me straighthen up first, why I choose LINQ first? It's because becoming hot buzzwords number one. And it can get many wrong views.

UPDATE:

27th March, 2008: fixing typos, code samples are now in C# 3.0 and VB 9.0, not just C# 3.0.

LINQ views and what comes in a single query of LINQ

Ah. Language INtegrated Query. Everyone has been becoming crowded and many shouting at me, "I know it! Of course I know!" But many don't know, it's not just a new essential features of VS 2008, but it's more like one of new features of .NET 3.5.

I also often heard many mumbles that said, "LINQ is the only way","LINQ is the newest concept from Microsoft's family of programming languages", blah, blah, blah, and many leads to almost false altruism.

It can be a sad fact for us but it's true, LINQ is not all that new! In "C Omega", or Cω, the notion that you can include SQL query such as Select is already available before C# 3.0. The name itself is new. Yes, the term LINQ is new, but the concept behind it it's not new. But why I say, not all? The concept of bringing Lambda expressions to LINQ queries are new. I'll try to explain it after this LINQ views.

LINQ it's not exclusive of .NET 3.5, though. Because it's simply a set of new language features capabilities that built into the fabric of C# 3.0 and VB 9.0 language specifications in terms of new keywords and new syntaxes. Most of all, it's simply a syntactic sugar, to ease all of us writing codes especially when dealing with SQL query language syntaxes. And don't forget one thing, .NET 3.5 is still .NET 2.0 lies beneath. So, .NET 3.5 was built on top of .NET 2.0 added with .NET 3.0. It's not exclusive, right?

Since LINQ is not exclusive of .NET 3.5, it's also implied that you can still can do your hard work in doing querying data. Still, you can do many things in ".NET 2.0 ways". But we, as software developers, tend to be more productive, and can be we're obligated to be always more productive and also more innovative in doing our core responsibilities, solving business problems and coding.

So, I strongly suggest that you use LINQ if you have Visual Studio 2008, and please upgrade to VS 2008 if you have 2005 since your new learning curve is not that new. Why? I'm not a strong opponent of using LINQ. In fact, I (again) strongly suggest you to use LINQ as appropriate and wisely for your development. It's helpful. It's not a must, but it eases our coding, and also promoting easier to read and then to code (can be the other way around).

Why? Because you'll get compile time checking and Intellisense in your query syntaxes! This means less error, more focus to the query logic. Also another why is, it's a way to compose pieces of arcane nested select queries, which can have many side effects. This concept comes from functional programming, and later I'll explain this after LINQ stuffs.

But be prepared to dive the concept behind LINQ uses first. You have to know it. I strongly suiggest you to learn it also. There are some facets of many programming paradigm "hidden" from us!

A quick LINQ to SQL

First, easier to code. Why? Let me give you a basic example of LINQ querying a LINQ to SQL (formerly DLINQ)generated class that represents Customers, from our good old sample database of Northwind (it's not installled by default in SQL Server 2005, you can get it here).

These are quick step by step to get your feet wet quickly:

In this sample, I create a LINQ to SQL classes and name it Northwind.dbml

Now let's use this new classes, but please pay attention that you have to understand what really is "LINQ to SQL Classes" is.

Basically LINQ to SQL is a quick "one stop shopping ORM" tool that maps your SQL Server database, tables, relations, and also stored procedures into hierarchical objects and CLR methods.

Your database will be mapped into a DataContext, your table will be mapped to

Just add these tables from Northwind to the Northwind.dbml:

Customer
Order
Order_Detail

Just for fun, add the SalesByCategory stored procedure into Northwind.dbml and you'll see this:

Now... it's quite straightforward, right? But, where's the real LINQ?

Ah, LINQ is not pictures and models. This tool simply helps us visualize this code: (in the Northwind.designer.cs)

These are the code that represents Northwind database (also conceptually):

    public partial class NorthwindDataContext : System.Data.Linq.DataContext
    {
        
        private static System.Data.Linq.Mapping.MappingSource mappingSource = new AttributeMappingSource();
        
    #region Extensibility Method Definitions
    partial void OnCreated();
    partial void InsertCustomer(Customer instance);
    partial void UpdateCustomer(Customer instance);
    partial void DeleteCustomer(Customer instance);
    partial void InsertOrder(Order instance);
    partial void UpdateOrder(Order instance);
    partial void DeleteOrder(Order instance);
    partial void InsertOrder_Detail(Order_Detail instance);
    partial void UpdateOrder_Detail(Order_Detail instance);
    partial void DeleteOrder_Detail(Order_Detail instance);
    #endregion
        
        public NorthwindDataContext() : 
                base(global::WinFormDLinq.Properties.Settings.Default.NORTHWNDConnectionString, mappingSource)
        {
            OnCreated();
        }
        
        public NorthwindDataContext(string connection) : 
                base(connection, mappingSource)
        {
            OnCreated();
        }
        
        public NorthwindDataContext(System.Data.IDbConnection connection) : 
                base(connection, mappingSource)
        {
            OnCreated();
        }
        
        public NorthwindDataContext(string connection, System.Data.Linq.Mapping.MappingSource mappingSource) : 
                base(connection, mappingSource)
        {
            OnCreated();
        }
        
        public NorthwindDataContext(System.Data.IDbConnection connection, System.Data.Linq.Mapping.MappingSource mappingSource) : 
                base(connection, mappingSource)
        {
            OnCreated();
        }
        
        public System.Data.Linq.Table<Customer> Customers
        {
            get
            {
                return this.GetTable<Customer>();
            }
        }
        
        public System.Data.Linq.Table<Order> Orders
        {
            get
            {
                return this.GetTable<Order>();
            }
        }
        
        public System.Data.Linq.Table<Order_Detail> Order_Details
        {
            get
            {
                return this.GetTable<Order_Detail>();
            }
        }
        
        [Function(Name="dbo.SalesByCategory")]
        public ISingleResult<SalesByCategoryResult> SalesByCategory([Parameter(Name="CategoryName", DbType="NVarChar(15)")] string categoryName, [Parameter(Name="OrdYear", DbType="NVarChar(4)")] string ordYear)
        {
            IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), categoryName, ordYear);
            return ((ISingleResult<SalesByCategoryResult>)(result.ReturnValue));
        }
    }

In VB:

Again, quite straightforward, eh?

The rest of the code is the declaration of tables.

Now, again, where's the LINQ, or query, or the code thingy?

I simply use the NorthwindDataContext and create a new instance of it. Then, just get Customer table from it! With a hint from Intellisense. Yes.

Okay! Now the LINQ!

In this quick sample, I dump the output of the LINQ to SQL of Customer to an IEnumerable and then put it as a DataSource of a Windows Forms GridView:

in C#:

        private void Form1_Load(object sender, EventArgs e)
        {
            NorthwindDataContext dbnorth = new NorthwindDataContext();
            var qry = from c in dbnorth.Customers
                      select new { c.CustomerID, c.ContactName, c.CompanyName, c.City };
            this.dgvCustomer.DataSource = qry;
        }

In VB:

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim dbnorth As NorthwindDataContext = New NorthwindDataContext
        Dim qry = From c In dbnorth.Customers _
                  Select c.CustomerID, c.ContactName, c.CompanyName, c.City
        Me.dgvCustomer.DataSource = qry

    End Sub

Run it, you'll get the same column results from the select query above:

What if I want to filter it? Hmm... Let's just say I want to get data of customers in London.

Change the code above to this:

In C#:

        private void Form1_Load(object sender, EventArgs e)
        {
            NorthwindDataContext dbnorth = new NorthwindDataContext();
            var qry = from c in dbnorth.Customers
                      where c.City == "London"
                      select new { c.CustomerID, c.ContactName, c.CompanyName, c.City };
            this.dgvCustomer.DataSource = qry;
        }

In VB:

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim dbnorth As NorthwindDataContext = New NorthwindDataContext
        Dim qry = From c In dbnorth.Customers _
                  Where c.City = "London" _
                  Select c.CustomerID, c.ContactName, c.CompanyName, c.City
        Me.dgvCustomer.DataSource = qry

    End Sub

you'll get this:

Voila!

More productive, right? I just create this sample code less than 5 minutes!

As you see, the "select" is now keyword. So is "where" and "from". But from comes before select, which is different from the original SQL query of SELECT.

Why? Because SQL language is not quite natural in the way the ordinary compiler process. You can't put the "select" first, since you have to know from what kind of set of data you want to manipulate or to select.

The quick notion is: I have to know from what set of data I want to select, then select it. Not the way that SELECT SQL works. Because compiler can't know at first the variables you want to select if you don't define from what data first. Now, enter the world of Declarative Programming!

Why? Because you think what you want to, not how it can be done. Declarative programming is everywhere, from WPF's XAML, to XML Schema, and to quite old domain specific language such as Prolog and our old data centric language (and also domain specific language), SQL query.

Quite funny, isn't it? You've used SQL but you didn't know what kind of taxonomy SQL query was.

But don't be happy soon, C# is not entirely Declarative Programming. It's an imperative programming family member, same as VB.NET.

See? This is why I told you up front, you have to know some concept first. And the depth doesn't stop here. Let's see how the code above is translated into, and I call it, "first phase". But before that, enter another new cool features of C# 3.0 and VB 9.0: type inferencing.

Type inferencing

See this:

            var qry = from c in dbnorth.Customers
                      where c.City == "London"
                      select new { c.CustomerID, c.ContactName, c.CompanyName, c.City };

You may wonder, is it still type safe? Variable qry has no type defined up front! If you debug and hover your cursor to qry variable, you'll get IEnumerable. Actually, the code above says, "give variable qry the type of the right hand expression has". So, qry has the type of IEnumerable.

I can also create this variable x as Int32 using type inferencing:

            var x = 1;

It's using var and it functions the same as Dim in VB. VB also have it. But var looks like Javascript, and Javascript is dynamic language family member. Enter the world of dynamic language!

But, again, it's up to you to decide whether this is a good or bad news, since C# is not purely dynamic language. For me this fact can be understood perfectly, because C# is intended strongly typed at first, unlike Javascript.

Now, the query code above is translated into this first phase:

            var qry = dbnorth.Customers
                .Where(c => c.City == "London")
                .Select(c => new { c.CustomerID, c.ContactName, c.CompanyName, c.City });

Or in VB:

        Dim qry = dbnorth.Customers _
        .Where(Function(c) c.City = "London") _
        .Select(Function(c) New With {c.CustomerID, c.ContactName, c.CompanyName, c.City})

Have you seen this syntax above before? The "c=>"?

In C#3.0 and VB 9.0, it is called Lambda Expressions. But VB is not taking the same syntax, it's written as new Function which is then translated into Lambda function. VB programmer prefers syntax that's more verbose.

The idea of Lambda Expression itself was taken from a topic of Lambda Calculus, from mathematic foundation. We now turn our journey to the world of exotic Lambda Calculus, but only as an overview in C# or VB view. Now, we're now walking towards new world of Lambda Calculus.

Lambda Calculus (or Lambda Expression in C# 3.0 and VB 9.0)

Now, what is Lambda calculus anyway? It is simply a functional view of expressing your code. But in a deep glass magnifier view, it's a formal system (as in Wikipedia) to investigate function applications and recursion.

In C# and VB, it's a functional way to express delegate and expression tree types.

(To be continued..)

Share this post: | | | |