有感在先：
CodeSta 一家相当有活力的公司，最近和Microsoft的Peter Hallam进行了一次访谈，里面有一些非常有趣的信息，有趣的不是Codesta提的问题，而是Peter的回答；Codesta的问题在两年前就有人提过，问过微软的名人，比如：Anders Hejlsberg，有趣的是两年后的回答，答案显得更加自信而且听起来比两年前更加清楚，特别是一些战略方面的回答。
我想下面这些是需要你特别注意的：
1. Virtual machine的问题，为什么需要它，具体它是什么，和Java的有什么不同。
2. C#的设计理论，CLR又是如何和它进行配合的。
3. CLR类或.NET Framework的设计理念，性能、面向对象、版本、升级的处理策略
4. 如果你非常的喜欢C#/CLR,你认为它最Cool的地方是什么？
5. 未来可以预见的一年或两年，C#/CLR的未来会怎样？
6. Why use C# to build your next application or back-end system? －－高效+简单+我喜欢!
从中也会嗅出下面一些信息：
1. Microsoft不会停止有关预装Java的上诉，有了.NET Framework,有什么理由用Sun Java虚拟机，即使一定要还有Microsoft Java VM。
2. Microsoft 对C#/CLR的未来和进程非常的清晰，并且控制得非常好。
3. 工业支持问题？业界人士有多少人支持，这是微软很难以控制，但又必须努力去改善的。
4. C#本身，它最大的特性。如果它能作为一种语言而摆脱made in Microsoft的负面影响是非常重要的。可以说目前Microsoft遮盖了C#的许多光辉，未来呢？这似乎不是一个技术的问题。
5. 交互性，没有人比微软人更清楚如何在老的应用和新的应用中互相交互，也许.NET是微软唯一一个不是通过快速升级来拉动用户的产品，连接一切而不是征服一起，微软的2003温和了许多J
小气的神
2003-2-25
www.dotneTTools.org/weblog/weblog.html
=============================================
Talking C#/CLR with Microsoft
by Joseph Molnar
In this article Codesta interviews Peter Hallam, the development lead for the C# compiler. With questions ranging from why Microsoft invested in the creation of the new technologies, to discussing future features, the goal of the article is to get an inside look at Microsoft's newest programming language, C#, and the associated virtual machine, the Common Language Runtime (CLR).
Codesta: Why did Microsoft create a new language?
Peter Hallam: 删除xxx个字，太长
Codesta: Why build a virtual machine if you can guarantee your platform?
Peter Hallam: Virtual machines allow you to do some things which can be very difficult without them. Things like accurate garbage collection and code access security are dramatically easier to implement on top of a strongly typed virtual machine. Also, implementing RAD environments, which blur the line between design time and runtime, benefit significantly from virtual machine technology.
Microsoft has employed virtual machine technology in our products for a long time. The entire VB product line has been built on a virtual machine which has evolved since its inception.
One thing that Java did was bring garbage collection (automatic memory management) into the mainstream of programming. Before Java, garbage collecting programming systems were limited to a small fraction of the programming community. Java really proved to the programming community at large that garbage collection was mature enough for real world programming.
When COM was being designed (over a decade ago) there was serious discussion on whether it should be garbage collection based. Eventually the decision was made that the programming community wasn't ready for garbage collection.
The main argument against virtual machines has been performance, both memory usage and execution speed. Recent improvements in computing hardware have made virtual machine performance quite reasonable.
With garbage collection firmly entrenched in the mainstream development community, and networked computing driving security concerns, you will see more and more mainstream programming targeting virtual machines.
Codesta: What were some of the major design goals behind C#?
Peter Hallam: 再删除无数个字和两端代码
There are a lot of other great features in C# but that's an overview of some of the key design points in the language.
Codesta: And the CLR, what were some of its design goals?
Peter Hallam: While sharing some of the goals of C#, such as a unified type system, the CLR was designed to be a high performance platform for executing code. The Microsoft Intermediate Language (MSIL), the CLR's instruction set, was designed to be compiled to the native platform at install time or ‘just-in-time' (i.e. during execution) rather than being interpreted.
One of the primary goals of the CLR was to support multiple languages. This is reflected in the type system, object model and Intermediate Language (IL) which are general enough to support a broad range of languages. For the first time your C++ class can be a super class to a VB class. This has tremendous benefits for teams that include developers of varying backgrounds and skills.
At this moment there are over 20 languages targeting the CLR. Microsoft has C++, C#, VB, J#, and JScript. Outside of Microsoft you will find Cobol, Eiffel, Scheme, and many others.
Security was also quite important, though perhaps I am not the best to describe it. In general, the CLR has a rich security model to allow trusted code to safely interact with untrusted code.
Experience with DLL's and general application installation also played a role in designing the CLR. In particular the CLR was designed to allow easy deployment of applications, and to ensure that existing deployed systems are robust when new versions of existing components are installed. The CLR allows running multiple versions of the same component side by side.
Codesta: With Microsoft's push for increased security, how was the CLR affected?
Peter Hallam: Making it easier for our customers to write secure code is one of the core goals of the CLR. Running code on a secure virtual machine allows the barrier between untrusted and trusted computing to exist inside a single process. Trusted components can leverage the services of untrusted components within the same process. The CLR enables you to write secure components in this manner and evolves the programming model forward with respect to security.
Writing secure code is extremely difficult however, and there are no silver bullets. The only way to write secure code is to think hard about security through the entire design and development process. Secure code can be written using most programming environments. The CLR makes it easier for programmers to deliver secure solutions.
Codesta: C#/CLR has 2 kinds of code, safe and unsafe. What is it trying to provide and how did this affect the virtual machine?
Peter Hallam: For C# the terms are safe and unsafe. The CLR uses the terms verifiable and unverifiable.
When running verifiable code the CLR can enforce security policies; the CLR can prevent verifiable code from doing things that it doesn't have permission to do. When running potentially malicious code, code that was downloaded from the internet for example, the CLR will only run verifiable code, and will ensure that the untrusted code doesn't access anything that it doesn't have permission to access.
The use of standard C style pointers creates unverifiable code. The CLR supports C style pointers natively. Once you've got a C style pointer you can read or write to any byte of memory in the process, so the runtime cannot enforce security policy. Actually it could but the performance penalty would make it impractical.
Unverifiable code is useful for interoperating with existing non-CLR code (existing C DLLs and COM components). It can also be useful when dealing with existing binary formats found in things like disk files and low level network protocols. This way you don't need to write custom marshalling code in C++ to access legacy components and binary formats.
Any unverifiable code must be fully trusted for the CLR to run it. Unverifiable code is often used to write a secure API on top of an existing legacy component. Many of the .NET Framework libraries are written entirely in C# using unsafe features to access the underlying platform.
The term unsafe has always bothered me. Unsafe code in C# really means more power to access the machine at a lower level without resorting to a lower level language like C. It is certainly possible to write safe secure applications in unsafe C# in the same way that it is possible to write secure applications in C. The difference is that in safe C# the strongly typed nature of the language and the security features of the runtime make it significantly easier to write secure code.
When using unsafe C#, as with standard C code, much more of a burden is placed on the coder to write safe secure code. The tradeoff between safe and unsafe code is really productivity versus power. It is not a tradeoff of safety. The C# language designers wanted to discourage the use of C style pointers and so the best keyword they found was the unfortunately named ‘unsafe'.
Codesta: In the early days of Java you created an experimental Just-In-Time (JIT) compiler/virtual machine. How would you compare the Java and CLR virtual machines?
Peter Hallam: The CLR design is much more mature than the JVM. The JVM made some design choices which have proven to be fairly limiting in the real world.
The JVM byte code was originally designed to be interpreted even though most implementations of the JVM now compile to the native machine for better performance. MSIL was designed to be compiled up front so it is more compiler friendly.
The JVM was designed with only one language in mind so it is missing many useful constructs which makes targeting the JVM painful for other languages. This includes the lack of user defined value types, delegates (type safe function pointers), byref types as well as pointer types.
The JVM's class file format and deployment model have a number of shortcomings. The class file format makes some sense if you are deploying a single class at a time, but in the real world that rarely happens. Typically you deploy a library of inter-dependant classes which you've tested together.
In addition, the JVM has no story for executing multiple versions of a class library in the same environment. The CLR's side by side features and deployment model is an enormous win.
Finally, JNI, the JVM's interoperability story, is extremely weak. To interoperate with existing code you must always write a custom marshaling layer in another language like C/C++.
In C# and the CLR most legacy code can be accessed directly from C# code using the built-in platform invoke and COM interop features of the CLR and the unsafe features (C style pointers) in C#. This lowers the bar to interoperating with legacy systems. Often you don't need to go to another language to access underlying platform features when programming in C# or any other language which targets the CLR.
High level constructs provided by strongly typed object oriented languages are great for building complex systems but ultimately it all comes down to bits. Java and the JVM really make it difficult to access the underlying computing platform.
Codesta: Microsoft has often criticized for its lack of innovation. What features of C# and the CLR are truly innovative?
Peter Hallam: The list here is pretty long so I'll stick to a few highlights:
It is also true that many of the innovations in C# and the CLR are evolutions of technologies and designs which have been around for many years. Garbage collection is a good example. Garbage collection, including the features for getting good performance such as incremental and concurrent garbage collection, has been around for several decades. The garbage collector in the CLR, which was built upon research from the Compuer Science community, is truly world class.
Codesta: Where did some of the C#/CLR language features get their inspiration from?
Peter Hallam: C# and the CLR draw heavily from existing computing practice and theory. C# inherits most of its features from the C and C++ family of languages. Garbage collection comes from the dawn of computing (aka before I was born). Many of the component features (properties, delegates and events) come from the VB and COM world. The unified type system sprang from a desire to get the ease of use of fully object oriented type systems from languages like Smalltalk and combine it with the performance benefits of type systems from languages like C and Pascal. The versioning features are pretty much new to C#.
Codesta: Are there any future features in C# or the CLR you can talk about?
Peter Hallam: Anders Hejlsberg, the chief designer of C#, announced some of the plans for C# at OOPSLA 2002 in
Taking a closer look at generics, we've had some really smart guys in our research department working on a design for both C# and the CLR and they've done some amazing work. By adding generics to the CLR as well as to the language we really hit the sweet spot in all dimensions - execution performance, type soundness, type identity, MSIL size, and native code size.
Here's a quick example of what generics will look like:
class Stack<T>
{
T[] buffer;
int count;
public void Push(T value) {
buffer[count++] = value;
}
public T Pop() {
return buffer[--count];
}
// more code goes here ...
}
class GenericDemo
{
static void Main()
{
// generic types can be instantiated
// with reference types like string ...
Stack<string> strStack = new Stack<string>();
strStack.Push("hello");
// ... and also with value types like int
Stack<int> intStack = new Stack<int>();
intStack.Push(5);
}
}
Codesta: In their current incarnations, would you say C# or the CLR are more suitable for front-end development or back-end development?
Peter Hallam: Yes and Yes.
VB has been, and continues to be, Microsoft's premier front-end development tool. VB .NET, targeting the CLR, is the next step in Microsoft's RAD client side tools. C# .NET leverages much of the VB .NET design time tools and libraries so it has a great client side development story as well. A lot of great things like this fall out because the CLR and the .NET Framework libraries are designed to be multi language.
On the server side we've got ASP .NET, web services, database integration ... everything you want to write server side apps. We've gotten a ton of positive feedback on the runtime performance and programmer productivity of ASP .NET.
Codesta: Is there the possibility of seeing a product, such as Office, or maybe parts of future versions of Windows implemented in C# and/or making use of the CLR?
Peter Hallam: Actually some parts of Visual Studio .NET are already written in C#. Microsoft has made a huge bet on the CLR being a key part of our future platforms and you can expect to see that reflected in everything we do going forward.
Codesta: In general, what kind of industry support have you seen for C# and the CLR?
Peter Hallam: I'm probably not the right guy to ask about this, but the few times I have talked with customers I've received very positive responses. There are C# development tools being produced by other vendors; this is a great indication of industry support behind C# and the CLR. We've also had a lot of interest in the CLR from academia with the CLR being used as the target of many research compilers.
Codesta: What is your view of projects like Mono and your general opinion of bringing C# and the CLR to non-Microsoft platforms?
Peter Hallam: I think the Mono project is a great validation of our direction with C# and the CLR. It's great to see an independent implementation of C# and the CLR. I look forward to seeing what they produce.
C# and the Common Language Infrastructure (the CLI, a subset of the full Microsoft CLR) have been accepted as international standards by ECMA. Microsoft has also released Rotor, a shared source implementation of C# and the CLI which targets Windows XP, FreeBSD, and more recently Mac OS X 10.2.
Codesta: Final Questions, Why use C# to build your next application or back-end system?
Peter Hallam: Productivity. Simple as that.
C#'s goal is to be the most productive way to deliver your solution whether it's a rich client or server.
Codesta would like to thank Peter Hallam for his time and his willingness to answer these questions. C# and the CLR are important Microsoft technologies and the insight is much appreciated.
If you have any questions or comments regarding this article, please do not hesitate to e-mail [email protected]!
Peter Hallam's Biography
With over 10 years of experience Peter Hallam is the development lead on the C# compiler and a member of the C# language design team. He has worked at Microsoft for 7 years spending the last 4 years on the C# compiler. In previous roles at Microsoft he worked on Visual Basic for Applications, OLE Automation, Windows CE, and 64-bit Windows XP. Before joining Microsoft he was a software engineer at Iris Power Engineering and CitiBank. Peter Hallam graduated from the
本文地址：http://com.8s8s.com/it/it45769.htm