C # chief designer Anders Hejlsberg interview (1) turn

Design Author: John Osborn

Translator: Glory

[Preface: Wonderful technology, not to be missed! Limited to time and ability, if there is corruption, the original English will prevail. ]



July, O ' Reilly editor John Osborn attended the Microsoft Career Developer Conference. Here he is to the famous engineer, Microsoft. NET Framework designer, C # programming language chief designer Anders Hejlsberg interviewed. Anders Hejlsberg is famous for designing one of the earliest languages on the PC,-turbo Pascal. He authorized the Turbo Pascal to Borland Company, and then the team developed delphi-a very successful visualization of the customer/service application design tools [: Here do not take the Midas such as Serious j]. The visit was also attended by Microsoft C # product manager Tony Goodhew and O ' Reilly's Windows editor Ron Petrusha.

Osborn:

I've seen some news stories about c#[pronounced "see sharp", and I've noticed that there are a lot of ideas that seem to be inclined-or, theoretically,-c# is not a Java clone or a Java Microsoft alternative. If you write this title, how do you want people to comment on the language?

Hejlsberg:

First, C # is not a Java clone. During the design of C #, we examined a number of languages, such as C + +, Java, Modula 2, C, Smalltalk, and so on. Many languages have the same core ideas that we are interested in, such as depth-oriented objects, simplifying objects, and so on.

The key difference between C # and these other languages, especially Java, is that it is very close to C + +. In the design of our efforts. C # directly borrows most of the operators, keywords, and declarations from C + +. We have also retained many of the language features discarded by Java. Why is there no enumeration in Java? I mean, what is the rationale behind abandoning them? In C + +, enumerations are clearly a very meaningful concept. In C #, we retain enumerations and also make them type-safe. Also, enumerations are not just integral types, they are actually from. NET base Class library, a strongly typed value type derived from the System.Enum. Enum type ' foo ' and enum type ' bar ' are not interchangeable without styling conversions. I think this is an important difference. We have also retained operator overloading and type conversions. The overall structure of the C # namespace is also very close to C + +.

However, beyond these traditional language topics, one of the key goals of our language design is to make C # oriented to components. We have added to the language itself all the concepts you need to write your component. For example, the property, translated as "property", is a long-standing. I doubt if the first attribute, the property will be translated as "nature", "characteristics", and attribute is "attributes": JL], methods, events, characteristics [of], so far, the translation of this noun is still more confusing. Some translation and property are not differentiated, also translated as "attributes", some translated as "characteristics", and some translated as "attribute information." Before the translation of the noun has yet been unified, the author first translates it into "characteristics" in the principle of simplification. Note, however, that the translation of attributes in XML is generally uniform, that is, "attribute" (because there is nothing in XML that resembles a property that can be confused with it). So, in the end, this article is a cross description of C # and XML parts, please pay attention to "attributes", "attributes" each point. and documents, they are all first-class language structures. The work we do on features is new and innovative. Attributes can be used to add typed, extensible metadata to any object. This is not visible in any other program language at the moment. C # is also the first language to merge XML annotation tags, which the compiler can use to generate readable documents directly from the source code.

Another important concept is what I call "one-stop shopping software" [One-stop-shopping Software]. Once you write code in C #, you write everything in this place. header files, IDL (interface Definition Language) files, GUIDs, and complex interfaces are no longer required. Because it is self-contained unit. Once you write your own code in this way, you can embed your software in an ASP page or in a variety of environments that were previously impossible.

But let's go back to the important concept of component. The industry has a lot of arguments about whether the language should support attributes or events. Yes, we can express this concept in a way. We can simulate the behavior of a property using the naming pattern of a program block such as "get" or "set". We can use the interface and the adapter that implements the interface and forward it to the object. This is possible, as is possible with object-oriented programming in the C language. It's just too difficult, it takes too much manual labor, and in order to express your true thoughts, you end up having to do all the work. We think it's time to have a language that makes it easier to create components. Today programmers are creating software components. They are not creating the entire application or the entire class library. Everyone is a component that inherits from the base component provided from the hosting environment. These components overload the methods and properties that handle some of the events and install the components back to the system. Setting up these concepts is the key lesson of the first.

Osborn:

When you recently introduced C #, the first slide read: "The first component-oriented language in the C + + family."

Hejlsberg:

Yes. This is one of my primary goals. It's also crucial that we talk about how everything is the object. It used to be like Smalltalk and Lisp, but it was expensive. I think C # contains some beautiful and interesting innovations that make component development easier. such as the concept of boxing and unpacking. Boxing can convert the value of a value type to an object, and the unboxing can convert an object to a value of a simple type. This may have been the same in the past, but the way we apply it to language is a beautiful innovation.

We strive to avoid designing the C # and. NET Framework in an "ivory tower" fashion. We can't afford to rewrite all of our software. The industry cannot afford it, especially today we are moving to the internet age. You have to be good at making use of what you already have. So, I think interoperability is also critical. We are committed to providing programmers with the right interoperability solutions for all Internet standards, such as HTTP, HTML, XML, and Microsoft's existing technologies. So you're not going to have the moment to fall into the abyss-discover new. NET Framework does not provide you with some of the things you use, or you realize that you want to take advantage of some existing APIs or components. You've seen that we've built all of COM's interoperability into language and public runtime; you've seen that you can use the DllImport feature to import existing dll[dynamic connection libraries]; you've seen that even if that's not what you want, we have the concept of unsafe code. Unsafe code allows you to write an inline C code that uses pointers to make unsafe styling conversions that can inhibit memory so that it is not accidentally garbage collected [as Verb j].

There's a lot of controversy about the unrest, and people seem to think we're taking drugs or doing other bad things. I think it's a misunderstanding. The code does not mean that it is not controlled simply because it is labeled "unsafe." Of course, we don't throw unsafe pointers that make people vulnerable to unsafe code downloaded from the Internet. Unsafe code is deeply constrained in a secure environment. We offer such resilience: 1. Stay in a controlled code box and do the work without falling into the abyss; 2. Go to a different language and write local code using a different programming model. If you stay in this box, we'll make the code more secure because the system knows what it's going to do. In fact, even if you write unsafe code, it doesn't mean you're out of the control space. Your unsafe code will become more efficient.

Osborn:

Please tell me more about the mechanism of handling unsafe code in a controlled environment.

Hejlsberg:

Good. Describes a controlled execution environment, such as the Smalltalk, Java, and. NET common language runtime, an important feature of which is that they provide a garbage collection mechanism. To provide a garbage collection mechanism, at least a modern garbage collector, a "tag and sweep" garbage collector, is provided. You have to know more about the code being executed than the traditional unregulated code. To find out which dead objects to exclude, you must be able to traverse the stack, find the root of all activities, and indicate which objects are active and which are no longer accessed. However, in order to achieve this goal, you must work closely with the code you execute. The code must be more descriptive. It tells you how it is distributed on the stack, where its local variables are stored, and so on.

When we write unsafe code in C #, you can do things that are not type-safe, such as pointer manipulation. Code that is marked as unsafe is not absolutely enforced in an untrusted environment. In order for it to execute, you must grant trust, otherwise the code will not execute. From this point of view, there is no difference from other native code-the real difference is that they still run in a controlled space. The method you write has a descriptive table that tells you which objects are active, so you don't have to go through the column set boundaries whenever you enter the code. Otherwise, when you enter an unmanaged, unregulated code (such as through the Java Local interface), you have to set a watermark on the stack or set a barrier. You must rearrange all the parameters outside the box. Once you start using the object, you have to be careful about what you touch, because the gc[garbage collector is still running on another different thread. If you do not use some obscure method to lock the object to properly suppress the garbage collector, it may remove the object. If you forget to do that, you will be unlucky.

We have adopted a different approach. We said, "Let's integrate this into the language." Let's provide a statement, such as a fixed statement, that allows you to suppress objects to collaborate and integrate with the GC. "In this way, we provide the best way to lead all existing code along, rather than simply discarding them." This is a different way of designing.

Osborn:

So the way you deal with unsafe code is that the memory of unsafe code is actually under the watch of the garbage collector?

Hejlsberg:

Yes. However, it is not safe, as the so-called "buyer beware, not to be exchanged". You can get the pointers and do the wrong things-of course, you could do the same wrong in the local code.

Osborn:

I think another confusing place is to understand where C # starts when it stops and where the public runs. What is the C # language's own innovation compared to what it gets from the public runtime library?

Hejlsberg:

Well, I guess the confusion comes from the fact that when people talk about Java, they don't really know which language is the runtime. When people talk about Java, confusion happens. Which language is the runtime? When they talk about Java, what exactly are they referring to? Java, language? Java, Syntax? Or Java, platform? People put these different aspects into a group. Our approach shows that we want to be a cross-platform platform. We will create a platform that allows you to program in multiple languages and share a common set of APIs (application programming interfaces). Let's admit this, some people like to use COBOL programming, some people like to use basic programming, some people like to use C + +, and some people will like to use c#-I hope. But we will not try to tell you, forget all the things you have done, we will not say, "There is only one language now, there will be no innovation in this competition." We say the industry is friendly because it is flexible. How does Java come in? It appears because some programming languages already exist before it, and some programming languages will appear after it. We want to build a platform where you can prefer a language but not deny the whole value orientation; we want to build a platform that will be innovative. Who is helping COBOL programmers today? Who brought them into the web? Only in. NET platform before you can embed Fujitsu COBOL into ASP pages. I mean, it's really revolutionary!

Osborn:

Assume. NET platform, why choose C # rather than visual Basic, C + +, or even COBOL? What makes C # so compelling?

Hejlsberg:

First of all, C # allows us to start with a piece of white paper. In other words, we don't have any backward compatibility burdens. This would obviously make things simpler, from the standpoint of the realization and from the standpoint of use. For example, in C #, we have only one type of class and are always garbage collected. On the other hand, there are two sets of controlled C + +. Because it retains the non garbage collection style of programming. Therefore, in C #, you only need to understand some simple concepts.

Language is an interesting thing, it is a taste; language is a serious thing, it is a way of life that programmers choose. I mean, we realize we can't go out and say, "Here's a platform where you can just use one of the basic languages." "Even if you can do everything in one language on that platform, people may not like the syntax," he said. They may like curly braces or some other block delimiters. That's what they're familiar with. That's what makes them feel comfortable and productive and capable. The way we treat C # is simply to provide an alternative to C + + programmers who think language is too complex and Java programmers who think that some of the C and C + + language features are missing. We seek a simplified C + + approach and invest in a multilingual platform that provides greater interoperability, and it provides complete component concepts, among other things.

Goodhew:

One interesting thing is that we track developers, and more than 60% of career developers use two or more languages to create their apps. Especially when we ask them what development tools they use, the answer is: no development language will be a terminator and all programmers will use it. As Anders earlier, people expect some kind of grammar that can satisfy what they do or feel. This is a personal choice. This is also the whole. NET Platform Cares-provides developers with a language implementation choice. I think we did a beautiful job. You can basically do the same thing in Visual Basic.NET and C #. Visual Basic is still easy to accept for most programmers. C # has more active space and is more powerful than VB.

Osborn:

Does this mean that more can be implemented in C # with fewer declarations?

Hejlsberg:

Yes. means that you can get more power through unsafe code.

Osborn:

In other words, can't write unsafe code in VB?

Hejlsberg:

Yes. No.

Goodhew:

But, basically, both languages can do the same thing. This is a fundamental change compared to visual Studio 6. In Visual Studio 6.0, if you want to create a multi-threaded MTS object, and you're a VB programmer, you don't. You have to use C + +. Now, there it is. NET Framework, you can use any kind of language you like.

Hejlsberg:

That's what I said in a general meeting conversation. NET Framework provides a consistent programming model. In the evolution of language and framework, we always seem to be tying a program language to a particular API and a particular programming approach. VB is a rapid application development tool, MFC (Microsoft base class) is a subclass of the way, the ASP is to plug things into the Web page. In each case, your choice of the programming model determines your choice of program language and API that you can use. Each time you change the frame, it increases the amount of work you can do to learn a new language and API. We really strive to unify all of this, we provide a set of APIs, a set of tools that support visual design, and we offer a flexibility to choose a language that suits you.

Osborn:

I don't know what this does for those who use VBScript and JScript scripting languages?

Hejlsberg:

. NET Framework one of the wonderful things is to make scripting languages compile. Look at the asp+, now, actually, the code that runs in your page is really compiled. It's not a post-bound, scheduled lookup-you don't see a run-time error if the user doesn't click on the page. Asp+ developers can use Visual Basic.NET complete power rather than VBScript. And for the first time, they can use Perl, Python, and other popular languages, if they choose.

Petrusha:

Server-side JavaScript can now be compiled as well?

Hejlsberg:

That's right.

Goodhew:

. NET Framework makes it possible to use scripting languages just as you would with fully-characteristic languages, because they now access a real programming framework and access the same base class API. You should see what the guys who are doing with JScript have achieved. [Note: JScript is the implementation of Microsoft's ECMA 262 language Specification (ECMAScript version 3), with only minor exceptions (for backward compatibility), JScript is a complete implementation of the ECMA standard. So. NET platform provides a common language framework that is of great benefit to scripting writers.

Osborn:

We've talked about Java, C + +, and scripts. At pdc[: [Microsoft] Professional Developer Conference] I hear a lot of people arguing. NET Il (il is the Microsoft intermediate language, all compilers must produce it to run in. NET Framework) and Java bytecode running in Java virtual machines are no different. From your conversation, obviously you don't agree with that. Would you mind further commenting on the difference between them?

Hejlsberg:

Good. First of all, IL's thought is a very old thought. You can trace this concept to UCSD Pascal P-machine (an early PC Pascal implementation) or Smalltalk. P-code has been used by basic and Visual Basic, a component of word that uses the P-code engine internally because it is more streamlined. So, P-code is not something new.

I think that I think we're interested in the way we use the IL: we give you a choice--if you want--you can control the timing of compiling or translating Il into local code. In fact, using controlled C + +, you can generate local code directly from the source program. Controlled C + + can also generate IL, just like C # and VB. When you install your code, we give you an option to compile the IL to compile the cost of the code. Therefore, when you run them, there will be no just-in-time compilation burden. We also provide you with an option to dynamically run and compile the code-just-in-time compilation. With IL, you have a lot of conveniences, such as the ability to migrate to different CPU architectures and introduce real type security and create secure systems on top of it.

I think the key difference between the design of our IL and the Java bytecode is that we made a decision ahead of us-without the interpreter. Our code is always running locally. So, even if you produce IL, you will not run the interpreter. We also have different styles of JIT. For a streamlined framework, we have Econnojit, as we call it, a very simple jit[note: streamlining. NET is a subset of the. NET Framework, designed for porting to other devices and platforms. For the desktop version, we have a fully functional JIT. We even have a back-end JIT that can be shared with our C + + compiler. However, this can be time-consuming, so you should only use them at installation time.

Once you make a decision in favor of executing the local code rather than the interpretation code, it will deeply affect the IL design. It changes how the instructions should be included, what type of information should be included, and how it should be transmitted. If you take a closer look at the two il[:. NET il and Java bytecode, you'll find that they are very different. In a sense, our il is of type neutrality. The information for the parameter type is not specified in the directive. Further, it is inferred from what has been pressed on the stack. This approach makes IL more streamlined. In any case, a JIT compiler needs to know what information, so there's no reason to carry them in the instructions. So, in the end, we made different design decisions, which makes it easy to translate il into native code.

Osborn:

How is the explanation different from the way you describe it?

Hejlsberg:

The core of the interpreter is a loop--the P-code stream gets some bytes, and then goes into a big switch[: "Oh, this is the add instruction, so it comes here, but it's not ..." and so on.

The interpreter simulates the CPU. We do the opposite, we only go one way, we always go one way, we translate the instructions to machine code. Now, in the case of Econojit, the machine code is actually very simple, it creates only a list of call and stack instructions, and invokes the Run-time helper, and then the runtime helper replaces the list. Of course, this code executes faster than the interpreter code.

Osborn:

Let me conclude with a sentence: You compile the code completely. So when you compile, the bytes are fully ready to run, although the timing of translating from IL to machine code may be different.

Hejlsberg:

Yes. However, if it is in the context of a small, memory-constrained device, it may be thrown out when it is run.