C # chief designer Anders Hejlsberg interview (II)

Design I think that I think we use the IL way to be interested in this: 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.

Osborn:

Let's get into the grammatical details. I wonder if C # includes built-in support for regular expressions. I don't see it in the language reference, maybe it's somewhere else.

Hejlsberg:

First, there is a regular expression class in the base Class library. We don't include any direct support for regular expressions in the language, but we actually have some very similar features. It's not worth the big deal. But, for example, when you need to specify a time--we give you the ability to write a verbatim string without requiring you to write two slashes at a time. When you write a regular expression and when the quotation marks in your regular expression are enclosed in quotes, it actually helps a lot. While this help is not enough, it is clearly at its core. NET Framework, and this framework can be shared by any programming language.

Osborn:

C # and Java namespaces look different. Are they identical in concept and implemented differently?

Hejlsberg:

Conceptually yes, but very different in implementation. In Java, a package name is also a physical thing that specifies the directory structure of your source code files. In C #, the physical package and logical name are completely independent, regardless of how you call your namespace, it is irrelevant to the physical package of your actual code. This gives you more flexibility-wrapping the physically distributed units together and not forcing you to build a lot of catalogs. In the language itself, there are a lot of obvious differences. In Java, packages are also your physical structure, so Java source files must be in the correct path and can contain only one exposed type or one exposed class. Because C # doesn't have that kind of physical and logical binding, you can name your source files arbitrarily. Each source file can be used by multiple namespaces and can have multiple public classes. Further, you can write all the source code in a large file, or you can spread them across the small file. Conceptually, what happens when C # compiles-you provide the compiler with all the source files that make up your project, and then it goes ahead and points out what to do.

Osborn:

I have a question about generic programming: Do you think it's an important concept? Should it be part of an object-oriented language? If so, what are your plans for adding generic programming as part of C #?

Goodhew:

Good. The desire to include generic programming in the first version was limited. Microsoft does not have unlimited resources, as everyone thinks. In this first version, we have to make some difficult decisions.

Osborn:

How many people are involved in developing C #?

Hejlsberg:

The language design group consists of 4 people, and the compiler group is composed of another five developers.

Petrusha:

What about the framework?

Hejlsberg:

That's a lot, the whole company is involved.

Goodhew:

For the entire Visual Studio and the. NET Platform group, there are probably thousands of people in our department. Includes program managers, developers, testers, and everyone who creates routines, frameworks, runtimes, ASP programming models, and everyone else, like me, management.

Hejlsberg:

As for the generics aspect that you just said, I definitely think it's a very useful concept, and you can certainly enumerate the generic studies that happen in academia and in the industry. A template is a workaround for this problem. In our internal discussions, we decided to do it on a new platform. But what we really like to do is let the underlying runtime understand generics. This is different from how to create a generic stereotype. There is no real generics knowledge in the Java "erase" concept system. Multiple languages can share this functionality if the common language runtime understands the concept of generics. You can write a generic class in C # in one place, and others can use it in other languages.

Making generics part of the runtime also allows you to do certain things more efficiently. The ideal time to initialize generics is at run time. If you use C + +, the initialization of the template occurs at compile time, you have two choices: Allow your code to swell or try to get rid of some expansion code when linking. However, if you have multiple applications, you may forget this and you will only get the inflated code.

If you incorporate generic knowledge into the common language runtime, the runtime understands that when an application or component requests an "Foo" list, it first asks, "Do I already have an initialized" foo "list? "If it is, use that one." In fact, if Foo is a reference type and we design it correctly, we can have all reference types share initialization. For value types, such as integers and floating-point types, we can create an initialization for each value type, but this should be done when the request is applied. In order to add generics to the runtime, we have done a lot of design work and necessary basic work.

What you mentioned earlier about IL is interesting because the decision to add generics affects the design of IL. If the IL instruction embeds type information, if, for example, a "plus" instruction is no longer a "plus", but an integer "plus" or a floating-point number "plus" or a double precision "plus", and you add the type information to the instruction stream, and at this point the IL is not generic. Our IL format is actually really type neutral. And, to keep the type neutral, we can add generics later without causing us trouble, at least not too much trouble. That's one of the reasons our IL and Java bytecode look different. Our IL type is neutral. The "plus" instruction can add any two things to the top of the stack. In the generic world, when it is initialized, it can be translated into different code.

Osborn:

All. NET language can achieve generic capabilities?

Hejlsberg:

Yes. Shine has created a version of the common language runtime and the C # compiler that supports generics capabilities, and we are looking at how to move it forward as quickly as possible. The first version is not possible to add generics, we know so much. But we're working to make sure we do the right thing in the first version so that generics can be applied to the entire blueprint.

Osborn:

What is the planned release date for C # and the. NET Framework and the next version of Visual Studio?

Goodhew:

Well, we brought a technical preview for the 6,500 people who came here to join the PDC. We want to release the beta release sometime in the fall of 2000, and then when we're ready, we'll release the release. One of the really exciting things we do is to look at how Windows2000 releases are going to involve key customers in the process of collaborative development and collaborative deployment. About. NET framework and Visual Studio.NET, we will work with customers again to determine the release date of the final product. We are going to let them tell us when the product is ready. And, because there are real customers involved in the process, we will get better product quality. The downside of this approach is that the process of product development and release is somewhat uncertain. But this is a fundamental change. We're looking for a way to break down the quality of the product, not just pick an arbitrary date and say we're shipping it.

Osborn:

So instead of a code completion date, we're looking for a "ready to go" date?

Goodhew:

Yes. I think developers will find that the Visual Studio.NET release is one of the highest quality distributions in Microsoft's history.

Osborn:

You have already submitted C # to ecma[: European Computer Manufacturers ' Association. Is standardization really a serious goal? Do you want to use C # on other platforms as well?

Hejlsberg:

That's true! Providing C # as a possible standard is certainly our goal, which is one of the reasons we submitted it to ECMA. In the process of directing this publicly designed language with a common language infrastructure, we certainly want to be supported by ECMA. With regard to public infrastructure, I mean a core set of libraries as defined by this specification, and if other companies implement it using other platforms, they have reason to expect to find that they can be leveraged in their programs.

Goodhew:

What I want to point out is that we are making real open standards with ECMA. When ECMA for C # and the common language infrastructure, true openness will be achieved under ECMA's copyright and authorization policy. Any customer, anyone can be authorized to ECMA C # Standard, subset of, superset of, and do not have to pay royalties. They can be implemented on any platform and any device. We all want people to do that. This is fundamentally different from our competitors. They wander outside the standard, looking for someone to stamp their private language.

John:

I heard at breakfast and lunch: "If Microsoft didn't get COM to the infrastructure, how portable would the platform be?" ”

Hejlsberg:

It's entirely possible. COM is not necessary to standardize C # and the common Language infrastructure. Not at all. C # has a rich class model, while COM is looking at the interoperability of applications from another perspective. However, C # and the core of the public runtime have never said that there must be COM, GUID, HRESULT, AddRef, or release, and so on. None of them. The. NET common language runtime completely abandons COM, but it gives you huge COM interoperability capabilities. In view of the foregoing, I still believe that it will be very important, but not indispensable.

Goodhew:

I think these comments result from the initial version of the language specification that we have made public. Microsoft wrote it into the specification at a meeting. At that meeting, we thought it was very important to follow the Microsoft platform. As a result, we refer to COM and dll multiple times in the specification. A DLL is a special case of how to activate local code on a given platform for more general issues. One of the benefits of working together as a standard organization and with people like IBM (we work with them to develop SOAP specifications) is that we can do no such mention to prevent us from tying ourselves to something like a COM framework in future versions of the specification.

As Anders says, COM interoperability and COM support are extremely important to us and existing Microsoft customers. I think in order to be in. NET support COM we did a lot of work. However, people in the industry have read a lot of what we refer to in terms of COM and DLL words, which they infer. NET is only designed for Windows platforms, which is completely wrong.

Hejlsberg:

And, I think, just as COM's interoperability is important for Microsoft and customers who build solutions on the Microsoft platform, the standardization of C # and the common Language Infrastructure will allow you to choose to implement the language on any other platform to add significant interoperability capabilities.

Osborn:

So you're not going to insist on a "pure C #" and "Pure. NET" Implementation?

Hejlsberg:

What do you mean "pure"? How many "pure" Java apps really exist? I venture to speculate, very very little. That's the amount I estimate. Let's admit this, people want to take advantage of the code they already exist. It's impossible to ask those companies to throw everything away.

Goodhew:

Have you communicated with Roger Sessions? [Note: Roger Sessions is the CEO of Objectwatch Company and is the author of COM + and the Battle for the Middle Tier.)

Osborn:

No.

Goodhew:

Roger talked about the relevant chapters of the EJB specification, where the seller [vendor] license extension was spoken. Not surprisingly, vendor extensions include such things as transaction management, security, messaging, and more, which is important in building enterprise-class systems. In an article [http://www.objectwatch.com/issue_24.htm], sessions a rough list of the functions of 11 areas, which are acceptable sellers specifications. Therefore, if you choose IBM WebSphere as your EJB implementation, the code you write for your EJB application will inevitably be locked in WebSphere. Java is 100% pure and 100% portable concepts that are not correct. At IBM's developer work site, there is a great interview [http://www-106.ibm.com/developerworks/features/gosling/index.html]. James Gosling directly points to this point. He said, yes, the whole "write a run Everywhere", "100% of pure things" is a stupid idea, more of it belongs to marketing things. In fact, he said, "We don't think we can deliver all of this, basically, we can't do it." This is what the inventor of the language says, there is no purity or portability.

Osborn:

Have we omitted some of the great features or innovations of C # that have not been disclosed, would you like to add?

Hejlsberg:

About. NET Framework, implicitly, as well as C #, I would like to mention that it is a means of building distributed applications. Not long ago, we created two classes of client/service applications, and then object protocols such as CORBA, IIOP, RMI, and DCOM ensued. This type of programming is the foundation of ejb-(except for the low-level implementations of CORBA or RMI). We've built this strong-connected distributed system, but they don't have scalability. They're not scalable on the web because they're stateful, they're in the service side, you can't move to another machine, plug it in and let the stuff replicate itself.

When we sat down and started to design. NET Framework, we looked back at what was going on on the web. It is becoming a loosely connected, very distributed world. We try to understand its impact on the potential programming model. Therefore, we fundamentally assume that distributed applications are built in a loosely connected, stateless style. In this way, the design we make can provide great scalability. You just expand. You move into more frames and plug them in. Once this fundamental assumption is made, everything changes. It changes how you design your basic services, how you design your messages, and even how you design your user interface. This is a new programming model. We have chosen XML and soap as the way to make this model work. They are deeply integrated into. Net. And this integration is designed for us. NET Framework makes every decision so central that it's not the kind of thing you can just come in and stroll around.

Osborn:

Can you point out something that is obviously special to programmers?

Hejlsberg:

A pretty good example is how XML is integrated into C #. In C # There is the concept of attribute, the description of the translation of nouns, described above, which allows you to add the claim information to the type and members. As you can say that a member is public or private, you may also want to say that it is a transaction, or that this assumption is a Web service, or that this assumption is supported by serialization in XML format. So we're adding features to provide a general mechanism, but we're using it in all the Web services and XML infrastructures. We also give you the ability to decorate classes and fields with attributes. In your class, you can say, "When this type becomes XML, it should become the" this "tag name and belong to the" this "XML namespace. "You will have the ability to specify a field to become an element, and another to become an attribute [here is the attribute in XML]." You also have the ability to control the XML schema [the schema]; control it where your class declaration is, so that all the additional declarative information is available. Once you modify your C # code correctly in this way, the system can simply convert it to a specified class in XML, transmit it online, and, when it returns, recreate the object on the other end. It's all done in one place. It is not like a traditional definition file or a variety of information and naming patterns. It's right over there. When you create them in the IDE, it gives you a complete statement. We can also provide advanced tools to help you do this.

I know I digress a little, but the infrastructure we provide is really exciting. Simply because we have these features, you can request an XML serialization infrastructure or Web service infrastructure to translate the given classes into XML. When you do this, we're actually going to match this class with the XSD schema, and we'll create a special parser that derives from our general XML parser (part of the. NET base class) and overloads the methods and joins the logic, so it's specifically for that pattern. So, we've initialized a parser that can parse XML at the speed of local code. If it is not correct, we will give you a decent error message that can tell you exactly what went wrong. We can cache it in the code caching infrastructure, and it waits until the next time a class with the same pattern comes along and it's going to work, "Bam!" "I mean, incredibly, incredibly productive!

Osborn:

So there are really a lot of interesting engines underneath the lid.

Hejlsberg:

Yes, and I think that when we reach this idea in this field, we are the leading generation.

Osborn:

Wonderful. Thank you, I'm wasting your time.

Hejlsberg:

You are welcome.