The future of. Net and the path (top and bottom) of VB and C #

The future of. Net and the path (top and bottom) of VB and C #

The future of. Net and the path of VB and C # (I)

[Csdn compilation in February 9] at Microsoft's professional Developer Conference last year (Professional Developers Conference PDC 2008), Microsoft developers were there. the future of the net platform has made a detailed outlook. In this article, we will give a general look at the coming. net 4.0 framework, as well as the new Microsoft programming language. NET platform's long-term prospects in the next few years.

 

Joint development of VB. NET and C #

 

Currently, one of the most important information from software is for Microsoft Visual Basic. NET developers. VB. net and Microsoft Visual C # are both built on the Common Language Runtime (Common Language Runtime-CLR), which means they are all compiled down to the common intermediate language-pencil ). Since both of them are compiled into the same Code, there is no big difference between the two languages. However, the two languages are maintained by two different Microsoft teams. This separation over the past few years has resulted in C # and VB due to the different perspectives and ideas of the development teams on their respective products. net Language has evolved many language features. Many exciting features first appeared in C #, but finally became a feature of VB. NET, which many VB. NET developers feel. Naturally, this caused dissatisfaction in the VB. NET camp.

 

Joint development is Microsoft's commitment to acknowledge C # and VB. net is the same important language, and Microsoft promises to add these features to both languages in terms of language feature development. Developers no longer need to select a language for a specific feature or discuss which language is better. All they need to do is to select their own language in terms of syntax. Maybe C # developers will have a lingering sense of superiority, VB. NET developers will be upset about this, but after the joint development, VB. NET developers can remind C # developers who are "proud", because the two languages are just the same thing in different appearances.

 

Introduction to Dynamic Language Runtime

 

Microsoft is very sensitive to realize that. NET Framework is not the only choice for building applications. A quick look at the current development environment, you will find that there are many language choices. People spend time and energy writing useful components in these languages. The question is: how can these components written in other languages not be rewritten on. NET?

 

Perhaps the most exciting new feature of. Net 4.0 to be released is the Dynamic Language Runtime (Dynamic Language Runtime-DLR ). Just as the common language runtime-CLR is a static language such as C # and VB. NET provides a general platform, like Dynamic Language Runtime (Dynamic Language Runtime-DLR), for dynamic languages such as JavaScript, Ruby, Python and even COM components. This indicates. NET framework makes a huge step forward in terms of interoperability. It provides language operation abstraction, and the shared storage space avoids repeated collection of data in the process, A set of common language features like garbage collection, and converts one data expression to another.

 

At a higher level, you can think that the Dynamic Language Runtime (Dynamic Language Runtime-DLR) has three layers:

*. Net Language integration)

* DLR Core Components)

* Language Binders)

 

The future of. Net and the path to VB and C # (bottom)[Csdn February 10 compilation]

 

Level 1. Net Language integration represents the concept of the. NET language, that is, what is the DLR and how it is used. In most cases, you don't even notice this aspect of DLR, because most. NET languages have a natural integration point. Ironruby and ironpython are both dynamic languages, so DLR is consistent with VB. net always supports the concept of late binding in object types. Therefore, DLR is well integrated with late binding. However, C # does not have the concept of late binding, so an additional static type is required to support dynamic languages.

 

Layer 2Is the Dynamic Language Runtime (Dynamic Language Runtime-DLR) itself, composed of three core components: Expression Tree (expression trees), Dynamic Allocation (Dynamic dispatch ), and call site caching ). An Expression Tree is a tree-like code representation. It abstracts the language into a continuous format that can be operated by DLR. Once dynamic code is presented as a tree, DLR can read this tree and generate CLR code from this tree for actual execution. The Code is interpreted as an Expression Tree, and creating CLR is an expensive operation. Therefore, DLR adopts a performance technology that we know about call site caching) to avoid re-compilation every time dynamic code is called. Dynamic Distribution ensures that language binders can be used for dynamic calls.

 

Language CombinationLanguage binders is the third layer. It is a language-specific tool for certain operations required by Dynamic Language Runtime-DLR. Of course, DLR is far more detailed and powerful than this article. More information comes from your own applications.

 

Reprinted statement:This article from the csdn blog, reprinted please indicate the source http://blog.csdn.net/gouyue/archive/2009/02/11/3876243.aspx