Paste: MSDN interview with the C # programming Rainbow (Translate)

Programming title MSDN interview with C # programming aRainbow (translation) keyword C#,MSDN source http://www.msdn.com

MSDN Interview (MSDN Show)
C # Programming


C # is a refreshing and spirits programming language designed to bring fast development capabilities to C + + programmers without sacrificing the functionality and control specific to C and C + +.
In this issue today, we will talk to Anders Hejlsberg, a senior engineer at Microsoft, who has been helping to design, develop and implement the language and play it in the future. NET platform. We're also talking to Jeffrey Richter, a well-known programming writer and consultant, who has been working in C # for more than a year.


Introduced

Robert Hess, Microsoft Product Manager and "show" host.


ROBERT HESS:Let's continue to focus on understanding. NET system (architecture). Today we will focus on the new C # (read "C Sharp" instead of "C Pound"!) Programming languages. First look at the MSDN News Update column.


MSDN Message Updates
chaired by technical editor Erica Wiechers
(Omit conversations that have nothing to do with C #)


Technical Chats (TECHNO BABBLE)
Robert Hess met with senior engineer Anders Hejlsberg to discuss ...???


ROBERT HESS: Welcome back to this column. Well, like any platform on which you want to develop software, one of the main things needed to make these apps really work is a programming language. At present,. NET already has a specialized language specially developed for this purpose, we call it C #. Today with us is Anders Hejlsberg, a senior engineer at Microsoft, in the C # language as well. NET platform field has played a key role in the previous "show" program that everyone has seen him. So I invited him to come here and talk to you about C #, what it is, what benefits programmers can derive from it, and how it really affects application development.
So, when did you begin to work on C #?

ANDERS Hejlsberg: In the last about 2.5 of the time, we have been engaged in C # research work. The design team was made up of 4 people, and during that time, I put the main focus on it. You know, for a new programming language, we have a lot of things to do. I think the first thing to do is to provide convenience for programmers, so that programmers develop more products is the ultimate goal. Today, although the benefits of the product is only taking shape, but it can be said that our goal, in a sense, not only to make C # have C + + powerful features and excellent performance, but also to make it simple and easy to use and RAD (Rapid application Development, Rapid application development) The productivity of the language.
We've done some work, for example, involving the scope of how programmers use better tools to write components. If you look at how we write the application, it should be everHow to write an application, if looking back, that is, 5 years or 10 ago, the application is so monolithic created, it and the operating system's only interaction, you know, is the file I/O operations, and in any case the operating system will load the application, then the user interacts with, and finally exit. Look at how we're creating Internet apps right now, which is a huge difference. The application is no longer monolithic, but consists of a series of smaller components that inhabit different environments. For example, you might have a component like a stored procedure (stored procedures) and SQL Server, or you might have a control that inhabits a browser, or code that exists in an ASP Web page. Business Objects live in the middle tier, and the component that calls the entire collection is equal to calling the application. So in order to make ....

ROBERT HESS: At the time you realized that each of these components was more complex than an application 5 or 10 years ago.

ANDERS Hejlsberg: Oh, absolutely, absolutely. Similarly, in order to reduce the complexity of creating components, unlike big programs, which have to create one of these components, there is no need to make a start, and should try to inherit something that already exists in these specialized habitats (hosting environment). If you want to write a control in the browser, to inherit from a base control, if you want to write a business object in the middle tier, you must inherit some business object classes, and to expose properties, methods, events, and so on, you need to show how they can be combined with the components by linking them to their habitats. You also need to be able to compose documents that are published with the component for these components.

ROBERT HESS: All of these are just standard object-oriented programming, Smalltalk The time to have this feature seems to have been short, and ...

ANDERS Hejlsberg: Well, absolutely, it's not impossible to do such a thing now. But if you look at the programming languages that have been widely used today, they don't really support the concept of component-oriented. If you had agreed when we would talk about components, it would be extremely common to think of them as having attributes, methods, and events today. But if you pay attention to C + +, you will find that it only mentions the concept of "method", no attributes, no events. Now you can simulate them with a naming pattern, that is, you can replace a color property with a get color and a set color method for an attribute, and instead of an event in a class that is a member of the first class, the interface you have for receiving events should be implemented. In order to do so, you have to deal with some trivial things ...

ROBERT HESS: Well, part of the reason is that C + + is based on C, it is just like preprocessing, and because C is not supported, C + + does not support ...

ANDERS Hejlsberg: Yes, actually I think what you see is the development process from C to C + + to C #. From c to C + +, the concept of object-oriented programming is added. If you go through C + + to C #, then I would say that the concept of component-oriented programming has been added, and there are really similarities between them. Just as you can use C instead of C + + for object-oriented programming, you can also use C + + instead of C # for component-oriented programming, but it is more difficult. C for object-oriented programming is extremely difficult, you have to manually layout the V Table (virtual function table), and also to deal with all the trivial things. Writing a component in C + + is also true, but you must manually set the naming pattern (naming patterns) for the attribute, you must implement event synchronization (events syncs), you must have an external IDL file, and you can have a property in the file (hosting attributes), must have external document files, and so on. We only really followed a reasonable step, which reflects how people write applications and integrate them into language

ROBERT HESS: So, what were some of the initial goals? Just from the heart, when you first started the project, what was the problem you were trying to solve and what direction was this new language to be determined?

ANDERS Hejlsberg: Well, I think as you said, component-oriented is just one aspect. Another key factor, I think, is simplicity. Make writing applications simpler, and don't allow programmers to do trivial things, machines can do it for you. A lot of simplification depends on the. NET runtime itself, but also on the language. Basically, what we do in the end is let you put more time and energy into the algorithm, and let the system do trivial things. I think that many other very important things are more realistic, and I can't tell people to throw away their existing code altogether. We have to find a trade-off, not just your programming skills, but also the pre-existing code you've written. So in C #, in the name of weighing your skill, we try to stick to the closest and truest place to the basic syntax of C + +. So using the c#,c++ programmer will immediately feel very familiar, very cordial.

ROBERT HESS: What you do should be based on C language, is it one of the original ideas? Or do you think that we should make a complete break with the past before we start designing a new language?

ANDERS Hejlsberg: Well, I think the language should appear in a new way, but we understand that C and C + + programmers must be familiar with the language. That, of course, means that in a way we have to transform the sentence structure from the curly braces into something else. We have laid some groundwork, but there are still some other key rules, such as allowing the writing of robust software, which means that functions like garbage collection (garbage collection), exception handling, type safety fundamentally change the way the language is designed, and are very difficult to start with, It is not easy to expand later. I mean, in C + +, the C + + language has one of the powerful features, but sometimes it is also one of the difficulties, in fact, you know, there is no type of security. If you know what you're going to do, you'll get a huge amount of power from it, otherwise you'll just have to ask for it. In C + +, obtaining a virtual suspension pointer (dangling pointer) is a breeze. Similarly, it is extremely easy to overwrite the tail of an array, or have an uninitialized variable, and so on. And we need to solve these problems. I think we can't just start and extend it from C + +. And really must retreat, with C + + soul to design a new plan, and these we have almost finished.

ROBERT HESS: What about other languages? Have you noticed what these languages are doing? If they are Pascal or Modular 2 or FORTH, what do you draw from it?

ANDERS HejlsbergAbsolute Oh, we thought, well, I mean, I was born in a deep Pascal background, so it's natural to take into account Pascal, Modula, Oberon, taking into account the smalltalk,java,c++ and all the languages. You know, today they can survive and be applied, and spread more or less.

ROBERT HESS: What do you think are the features of these languages that perform better than C and C + +? And you can introduce these features into the new language?

ANDERS Hejlsberg: Well, I think one thing is that I always like Smalltalk, because everything in that language is an object. This makes the program much simpler, because no matter what kind of data you have, you can move it from point A to point B as an object. In general, everything can be manipulated. You can put it in a container as an object type. In the actual implementation of Smalltalk, if you do this, the additional burden (overhead) of program performance will be greatly increased. For example, in Smalltalk, when a float is calculated, each new number is generated, such as when 1.0 and 2.0 are added together, and a new object containing 3.0 values is assigned. And the price is, of course, very expensive. Now in C #, we've done some renovation work that gives you the same benefits without an extra burden. If you use float as a float or double as a double, there is no price. But if you treat them as objects (and only when you do this), you have to assign them heaps (heap). As a result, there is a perfect unity that can give you a lot of benefits without the additional burden of program performance.

ROBERT HESS: What is the structure of the final result of C # generated? You get a text file of a C # program and compile it, what are the problems with the compiler itself, how do you design these solutions to be more efficient when you use them, and what other languages might have already done, and even eventually generate binary executables?

ANDERS Hejlsberg: Well, we've done some work involving how to encode. If you are a C + + programmer, of course familiar with how to do, in C + + declaration and implementation is separate. So all statements are placed in H file, then included in other modules (# include), and then written in the CPP file to implement the program. In C #, write them all in one place. In this way, you can write a declaration there and then write the implementation code immediately.

ROBERT HESS: What if you had to use some of the values declared in the main file in some other file?

ANDERS Hejlsberg: So what will happen? When compiling, the actual generated code or the regenerated output file contains two kinds of code: metadata (metadata), symbol tables (symbols table), or other related symbolic information (symbolic information). Instead of generating only X86 machine code that contains only executable code. In a sense, these codes become self-describing. So when you want to use another piece of code from a code slice, just reference them, and the code's self-describing enough to let people know what classes there are, what members they have, what methods they can call, what attributes are, what type names are, and so on.

ROBERT HESS: Well, isn't it like you mean. obj file or. exe file, or ...

ANDERS Hejlsberg: Well, you are right, we are. NET used in the format is the PE format, so you can point to another EXE or DLL. We call these assembler now and basically use this language to describe these high-level DLLs in large quantities, not only with code, but also with information such as what is in the code and what other assembler the code really refers to.

ROBERT HESS: The code you say refers to binary code or executable code.

ANDERS Hejlsberg: Well, in fact, instead of directly generating executable X86 machine code, we generate MSIL, which is the intermediate language, which consists of the. NET definition and compiled by the JIT (Just-in-time compiler).

ROBERT HESS: Ok, so it seems, you have an executable file that is itself associated with the intermediate language and metadata, and if I want to use it in one of the applications, I just point to it and say, hey, I'm going to borrow these classes, borrow these objects, and use it in a program like this. This reminds me of a problem many people have mentioned that there are potential vulnerabilities in the intermediate language that some people might grab and decompile and then revert back to the original source code. As a result, not all intelligent features (intellectual property) are beneficial to developers. What's the problem with that?

ANDERS Hejlsberg: Well, first of all, you can actually handle it with a DLL. This may be a bit difficult, but you can take a DLL that contains X86 code and then at least decompile it to the assembler. You can do the same ...

ROBERT HESS: On my Apple II, I've been doing this all along.

ANDERS Hejlsberg: Indeed, I am ashamed of it. However, you can do the same work using. NET DLLs and recompiling them into MSIL. They are not directly decompile into C #, although you might be right, but it's too difficult. The difference is that there is a lot of symbolic information (symbolic information) associated with code generated by C #, and MSIL, I'm sorry, it's. NET assembler. For example, you can learn from the code what classes are here, what their members are, and so on. This is a tricky problem to solve because there are a lot of benefits to having code self-describing (self describing), but the fact that the code is describing itself makes it seem easy to understand the code that the Decompile tool is dealing with. If we recognize the problem, basically what we're going to do is create something called a blender (Obfuscator) that adds and messes up the code, makes it almost impossible to read, and still retains the same common interface.

ROBERT HESS: Yes, because you have a problem: when you use and write these compiler programs, you want the compiler to understand the code (or similar processes, etc.), but don't want people to understand them at the same level.

ANDERS Hejlsberg: indeed, indeed. I do want to point out that for a small program, you can actually decompile it, give it enough time and resources, and you can even understand what it's doing. For an application in the real world, however, this is a daunting task. In reality you'd better run the application, understand what it's doing, and write a copy of it. You will soon reach this level.

ROBERT HESS: Maybe write a more cow program, because you are a more cattle programmer, right? To determine if our audience wants to start implementing the next C # project, what questions do they need to understand about C #?

ANDERS Hejlsberg: Well, I think first you have to consider your own foundation. If you have a ready-made code body, let's assume it's written in C + +, and perhaps the best way to migrate the code to the. NET framework is to use managed C + +, which is followed by the C + + compiler. NET published together. However, if you are looking at writing new code, that is, writing new modules, larger modules, adding to an application or a fully understood application, and you are proficient in C + +, then I recommend thinking about C #.

ROBERT HESS: Therefore, we do not need to say that everyone must rewrite their applications in C #. We're saying that people have to know the type of project they're working on, whether it's a ready-made project, a stale code, and sometimes some components in C #, can you use C # and C + + alternately?

ANDERS Hejlsberg: Oh, absolutely. First, if you have ready-made code, assuming that the code is written in any language supported by the Windows platform, compiling them into COM components or DLLs will give you strong interoperability with the code (interoperability). If you want to write code specifically for the. NET Framework, the new code for the. NET Framework is, of course, written in any language supported by the. NET Framework. We plan to be in visual Studio. NET is published in four languages: C #, C + +, Visual Basic, and Jscript. But in order to work with industry and academia, I think the latest statistics may not be very accurate, but I think a total of about 17 different languages are now aimed at this platform, ranging from APL to COBOL.

ROBERT HESS: So what is it like Fortran?

ANDERS Hejlsberg: I believe the relevant work is in progress, but I can't know exactly who is designing the FORTRAN compiler. But the point is, in fact, we have done a number of demonstrations, you can write a base class in C #, and inherit it in C + +, and then use the VB program to create one of its entities. Interoperability between different languages is seamless. I think it's these properties that make the. NET framework throw off the products of other competitors in the industry. (interested readers can go to http://www.lahey.com/net_down.htm to download Lahey/fujitsu Fortran for. NET Technology Preview 1 , )

ROBERT HESS: And it uses and allows for multilingual interoperability at the base level.

ANDERS Hejlsberg: Yes, very accurate. But it's at a very high level. You might argue that today's language can interoperate, but only at very low levels, such as the entry point of a DLL, the structure with pointers, and so on. And we're talking about a higher semantic level, which is at the object-oriented level, with classes and interfaces, and so on.