Ajaxus place on the net

I have found this post at somasegar’s blog writing about the new enhancements in VB and C# languages.

About VB.NET they include:
- removed the underscore (“_”) character when breaking a code statement across multiple lines
- simple way of declaring properties
- collection initializers and array literals are simpler as well
- better support for lambdas
- interoperating with dynamic language code such as Python and Ruby are simpler

Read also about C# improvements and find nice code samples here.

• Brad Abrams writes about “What is .NET RIA Services“. Here is a small bit of this article:
  
  Microsoft .NET RIA Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. The RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier.
• C# 4.0 goes dynamic - a step too far? Here is a small bit of this article:

  With C# 3.0 still so new that many are only just beginning to appreciate, let alone use, its new features it might seem premature to be discussing the next version of the most popular .NET language. Microsoft, however, has its plans for C# 4.0 well advanced, and the changes are so important that you might not recognise your favourite language after the upgrade. Now is the time to look over the horizon in the hope that end users can influence the outcome.

  The first thing to say is that C# occupies a very special niche in the panoply of .NET languages. When it was introduced there were essentially two classes of Windows programmers corresponding to mastery and use of either VB or C++. The split was fairly clear-cut as VB was easy to learn and easy to use but limited, and C++ was difficult to fathom but could do anything. You can even think of C++ as an object-oriented machine-independent assembly language if you want to, but VB, being interpreted and well removed from machine constructs, was no such thing. In addition there was also the aesthetic distinction to take into account – VB being messy and pragmatic and C++ pure and logical. Of course none of these characterisations is 100% true, they are just approximations to an average truth that is at least recognised by most programmers even if they’d argue over the fine details.

I came across this article and really enjoyed it, thats why I have to share it with you. Written by Damon Armstrong this article gives a bit of light what is next in .NET field.

Co-Evolution for VB.NET and C#

One of the most prominent messages coming from Microsoft right now is geared towards Microsoft Visual Basic® .NET developers. VB.NET and Microsoft Visual C#® are both built on top of the Common Language Runtime (CLR), which means they both compile down into the same Common Intermediate Language (CIL). Since they both compile down to the same code, there should be no intrinsic benefit of one language over another. However, both languages are maintained by separate teams at Microsoft, and over the years this separation has led to a variety of language-specific features in both C# and VB.NET as the teams focus on different areas with their respective products. Many VB.NET developers feel that the most exciting new features appear in C# first and are only later introduced into VB.NET. Naturally, this has generated a bit of animosity in the VB.NET community.

Introducing the Dynamic Language Runtime

Microsoft is acutely aware that the .NET Framework is not the only choice for building applications. All you have to do is take a quick glance around the development sphere and you’ll find a number of language options, and that number is only expected to rise as domain-specific languages emerge. People are spending time and energy writing useful components in these languages, so the question is, how can you use a component written in another language without having to rewrite it in .NET?

At a high level, you can think of the Dynamic Language Runtime as having three layers (see figure 1 below):

* .NET Language Integration
* DLR Core Components
* Language Binders

The first layer, .NET Language Integration, simply represents the need for .NET languages to have a notion of what the DLR is and how to use it. For the most part, you won’t even notice this aspect of the DLR because most of the .NET languages had a natural integration point. IronRuby and IronPython are both dynamically typed languages, so the DLR fit right in. VB.NET has always supported the notion of late binding on the Object type, so the DLR incorporated nicely into late binding resolution. C#, however, has no notion of late binding and needed an additional static type for dynamic language support. It’s called the dynamic type, and we’ll talk about it in more detail a bit later.

Language Binders, which make up the third layer, are language-specific implementations of certain operations the Dynamic Language Runtime needs to understand about each language that wishes to participate in the DLR.

New Language Features in .NET 4.0
- Dynamic Lookup (New to C#)
- Named and Optional Parameters (New to C#)
- Anonymous Method Support (New to VB.NET)
- Co-variance and Contra-variance (New to C# and VB.NET)
- Dynamic Import (New to C#)
- Omitting Ref Parameters (New to C#)
- Compiling without Primary Interop Assemblies (New to C# and VB.NET)
- Implicit Line Continuation (New to VB.NET)
- Simplified Property Syntax (New to VB.NET)
- Array Type Inference and Jagged Arrays (New to VB.NET)
- From Keyword (New to VB.NET)

Functional Programming with F#

F# is a succinct, high performance, type-inferred, functional language built on top of the .NET Framework. Microsoft has a solid base of imperative programming languages with VB.NET and C#, but there is a trend in computing that tends to be moving towards a more declarative style of programming. What’s the difference? In an imperative language you write code that tells the compiler exactly how to do something, whereas in a declarative language you write code that says what you want to do, but leave the “how” part up to the compiler. Now, the ultimate declarative language would allow you to write something like “Morph the screen into something cool” and then compile your thoughts into a wicked screen saver or some such, but we’re not there just yet. F# offers developers the opportunity to explore declarative concepts and offer a useful language to customers whose thinking is geared more towards functional development.

Read the whole of this article from the source.