Anders Hejlsberg talking C # design process
Original: http://msdn.microsoft.com/vcsharp/headlines/hejlsberg/default.aspx
Anders Hejlsberg worked for 13 Spring and Autumn in Borland, Join Microsoft in 1996, initially participated in the design of Visual J and WFC (Windows Foundation Classes). Then, serve as the core member of the C # Chief Designer and Microsoft .NET Framework design team. Currently, he will continue to lead the design work of the C # language subsequent version.
On July 30, 2003, Hejlsberg met with Bruce Eckel ("Thinking In C " and "Thinking In Java", Bill Venners (edited). The conversation content is mainly divided into three parts:
I. C # design process; language availability research and language aesthetics.
Second, the version correlation and scalability of Checked Exceptions feature.
Third, the concept of the entrusted; the component concept is at the highest position in C #.
One
1, C # design process
Bruce eckel: I heard that C # is an engineer group design in a room?
Anders Hejlsberg: Yes. For 4 years, we have been staying in this room. Now, we are still here every Monday, 3, and 5.
Bruce Eckel: I really want to know some situations about the C # design process. I have participated in the design work of several languages directly or indirectly, such as Python. During the Python design, Guido Van Rossum was "kinderian dictator".
Anders Hejlsberg: Oh, Guido Van Rossum is equivalent to my location.
Bruce Eckel: So you are a C # group "kinderian"? "
Anders Hejlsberg: I usually play the role of the last clasp. For example, we have troublesome more than a problem, it is not solved, and it can only be done when it is not a choice. Of course, most of this case, the correct choice is obvious.
Bruce Eckel: The design process of the C # is very similar to Turbo Pascal, Delphi?
Anders Hejlsberg: The design process of the back is not so standardized. Because Turbo Pascal is mainly designed by me, and Delphi is also a few people who are all in CHUCK JAZDZEWSKI, Gary Whizin, so there is no need to introduce a very standardized design process. On the contrary, the design process of the C # is very standardized, every Monday, 3, and 5 from 1:00 to 3:00, we will also hold a formal meeting, the meeting agenda is also quite flexible, all the questions will be discussed on the desktop, Carefully scrutinize. We also have a Wiki on the Internet, these issues and their solutions, and some other related things are released.
Bruce Eckel: How do you find these questions?
Anders Hejlsberg: Oh, we have a set of effective methods. We can get a lot of ways to get feedback from language design - such as software design consultation, online newsgroups. These feedback includes: doubt, software BUGS, inconsistencies, irregular issues, etc. In this way, we can have more. Finally, we will organize these questions into tables and will reach them one by one. For each question, we will treat yourself, ask yourself: "Do we have new ideas for this question? Really? This question has been put on hold for a few weeks, we will spend 30 minutes to concentrate on research, see this Whether it can be died. "Bruce Eckel: That may have a problem for a long time, it is smelling ...
Anders Hejlsberg: Perhaps some smelling issues can only solve the next version. But I think such a process ensures that you will not miss any problems because they are all registered. Sometimes, you are looking for a long time, there may be no results. But after all, I was caught by us, and I will go to "visit" one day. It may not be "visited" any more, but the problem will not be blocked.
Bill Venners: C # Design Group contains which members, what role is they doing?
Anders Hejlsberg: Participated in the original C # design with Scott Wiltamuth, Peter Golde, Peter Sollich, Eric Gunnerson, and I. C # 2.0 Design teams include: Peter Hallam, shon katzenberger, today, and I am. Microsoft Research Institute Don Syme and Andrew Kennedy have undertaken most of the general research work.
2, language availability research and language aesthetics
Bill Venners: How is the terms of availability research, market strategy and language aesthetics?
Anders Hejlsberg: In general, a good language design process reflects the synthesis of the aesthetic taste orientation of the design team members, which is what you just said. Aesthetic taste has a great subjectivity, it is difficult to agree, only after the product comes out, you can carefully taste it. I think any degree of availability research cannot replace the value of language aesthetics, as usability research is extremely targeted, very specific. Someone may ask you: "What do you think this part of this function?" This problem is hard to answer. "What do you think of this language?" What did you talk? " How can you spend two hours to solve all availability problems? Never possible.
Bruce Eckel: People must understand this problem in depth.
Anders Hejlsberg: Using a programming language experience a process of feeling subtle changes. Only after the user can truly like it after a few months. They will gradually discover: "Oh, it feels very comfortable to people." You can't worry.
I have started to say that we have done a lot of work in availability research, but mainly for specific functions.
Bill Venners: Can you give an example?
Anders Hejlsberg: We put the focus of availability research on the IDE function. We will ask yourself: "Does the user know what results will there be?" In the pure language function, we also consider some availability issues - such as in some properties and events - but there is nothing necessary, true.
I want to study in availability, language characteristics impossible to bring as high as IDE characteristics. You can see the user to get the correct feedback information immediately by clicking a menu item. And for the language, the problem is complex. For example: "Is its concept easy to understand?" We adopted the user consulting meeting, the message board, and better solved these problems. Users need to have a speech. "For this new feature, I have some ideas, how do you think about it?" This kind of problem is mentioned, and sharp and better, because you must most want to come out before the product You can know the user's idea, not after the product is launched. Before a language feature is fully finalized, we usually consider users' advice and opinions. two
1, retention attitude toward checked exceptions
(Translator Note: When writing a program, if you do not use try-catch to capture an exception or explicitly throw anomalies, you want the program to automatically throw, some language compilers do not allow compilation through, such as Java is like this. This is the most basic meaning of Checked Exceptions. The purpose of this feature is to ensure the security and robustness of the program. Zee & Snakey (MVP) has a very image of this, you can see:
Http://www.blogcn.com/User2/zee/main.asp. Bruce Eckel also has a related article (Does Java Need Checked Exceptions "), see:
http://www.mindview.net/etc/discussions/checkedexceptions)
Bruce Eckel: C # No Checked Exceptions, how did you decide whether this feature is placed in C #?
Anders Hejlsberg: I found Checked Exceptions There are more big issues in two aspects: scalability and version control. I know that some things about Checked Exceptions are also tend to be our view to this problem.
Bruce Eckel: I have always thought that Checked Exceptions is very important.
Anders Hejlsberg: Yes, honestly, it looks quite important, this view is not wrong. I also praised the wonderful checked Exceptions feature. But its implementation of some aspects will bring some problems. For example, from the implementation of Checked Exceptions in Java, I think it has a series of new problems while solving a series of problems. In this way, I can't figure out whether the Checked Exceptions feature can really make our lives more wonderful. There are different opinions on this.
Bruce Eckel: C # Design Group Do you have a lot of debate on Checked Exceptions?
Anders Hejlsberg: No, on this issue, we have a wide range of consensus. C # is currently kept skewer in Checked Exceptions. Once there is a well-recognized solution, we will reconsider and adopted in the appropriate place. I have a business creed, that is - if you don't have a say, there is no way to advance its solution, then it is best to keep silent and neutral, and should not put a rack of this.
Suppose you let a novice to edit a calendar control, they usually think this: "Oh, I will write the best calendar control in the world! I want it to have a variety of calendar appearance. It has a display section, There is this, there is that ... "They put all these ideas into the control, then spent two days to write a very foot calendar program. They want: "In the next version of the program, I will implement more and better features." However, once they start thinking about how many abstract thoughts in my mind, they will find their original design. It is completely wrong. Now, they are suffering from a corner, they find that the original design must be abandoned. I didn't see it twice once. I am a minimum programist. For issues that affect global solutions, don't bring it into the entire frame before there is no practical solution, otherwise you will not know what this frame will become in the future.
Bruce Eckel: The Extreme Programmers says: "" "" is used to complete the work. "
Anders Hejlsberg: Yeah, Einstein also said: "As much as possible." For Checked ExcPETIS features, I am most concerned about what issues may bring to programmers. Imagine, when the programmer calls some newly written APIs with their own specific exceptions, the program will become so messy and lengthy. At this time you will understand that Checked Excetion is not in helping the programmer, but it is in touch. The correct approach is that the API designer tells you how to deal with exceptions instead of let you want to break your head.
2, CHECKED Exceptions version correlation
Bill Venners: You mentioned two questions that CHECKED Exceptions scalability and version correlation. Can I explain what they mean now?
Anders Hejlsberg: Let me talk about version-related version, this problem is more likely to understand. Suppose I created a method foo and declare that it may throw out the A, B, and C. In the new version of Foo, I have to add some features, thereby impossible to throw an exception D. This will produce a very destructive change because it is almost impossible to handle D exception when this method is called.
That is to say, when an abnormality thrown in the new version, the code to the user has brought destruction. There are similar problems when using methods in an interface. An interface that implements a particular function is released, it is not changeable, and new features can only be added in the new interface. In other words, it is only to create a new interface. In the new version, you only have two options, either build a new method foo2, FOO2 can throw more exception, or capture exception D in new FOO, and convert to the original exception A, B or C.
Bill Venners: But even in languages without Checked Exceptions, (add new abnormalities) Does it also damage the program? If the new version of FOO throws a new exception that requires users, is it only because the user does not want this anomalies, can he write a code when you write a code?
Anders Hejlsberg: No, because in many cases, the user does not care at all (abnormal). They don't deal with any exceptions. In fact, there is a final exception handler in the message loop, which will display a dialog prompt you to run an error. Programmers can use Try Finally to protect their code anywhere, and the program can still run correctly even if there is an abnormality at runtime. For the processing of an exception itself, in fact, the programmer is not concerned.
Many language of Throws syntax (such as Java), there is no need to force you to deal with exception, that is, forced you to figure out every unusual source. They ask you either to capture the abnormality of the declaration, or put them in the throws statement. In order to achieve this request, the programmer has done a lot of ridiculous things. For example, when they declare each method, they must add a modifier: "Throws Exception". This is entirely in the slap in the feature, but it is required to make more official articles, no benefit. Bill Venners: So, do you think that the programmer does not require the appointment to deal with each abnormal approach, do you have much in reality?
Anders Hejlsberg: Why do people think (explicit) exception handling is very important? This is so ridiculous. It is not important at all. In my impression, a very good program, the number of TRY Finally and TRY CATCH statements is approximately 10: 1. In C #, you can also use and similar to the use farly (to process exception).
What do Bill Venners: FINALLY did?
Anders Hejlsberg: Finally guarantees that you are not abnormal, but it does not directly process exceptions. An exception handling should be placed elsewhere. In fact, in any event-driven (such as a modern graphical interface) program, there is a default anomalous process in the main message loop, and programmers only have to handle those who have not been default. But you must ensure that the original allocated resources can be destroyed in any abnormal situation. In this way, your program is sustainable. You must do not want to write a program, you have to deal with an exception and pop up the dialog box in 100 places. If you do, you have to make your mildew when you modify it. An exception should be centralized and protect your code at an exception.
3, Checked Exceptions scalability
Bill Venners: What is the extensibility of Checked Exceptions?
Anders Hejlsberg: Scalability Sometimes and version is related. In a small program, Checked Exceptions is very charming. Can you capture FileNotFoundException anomalies and display it, is it interesting? This is also very wonderful when calling a single API. But when developing a large system, the disaster is coming. You plan to include 4,5 subsystems, each subsystem throws 4 to 10 exceptions. But (when actually developed), you climb the first level on the ladder of the system, and the new exceptions that must be processed will grow index. Finally, 40 exceptions can be thrown each subsystem. When you integrate two subsystems, you will have to write 80 THROW statements. Finally, you may not be controlled.
Many times, Checked Exceptions will irritate programmers, so programmers will find ways to bypass this feature. He is either all written "throws exception", or - I don't know how much I have seen - Write "TRY, DA Da Da Da Da (Translator Note: Meaning Flying a code), Catch Curly Curly (Translator Note: 即 '{}') ", then said:" Oh, I will turn back to handle these empty anomalous handling statements. "In fact, there is no one if anyone will go back to these things. At this time, Checked Excetion has caused a great drop in system quality.
So, you may pay great attention to these issues, but when we decide whether to put some mechanisms of Checked Excetions in C #, it is quite a thing. Of course, know what exception may throw it in the program, there is still a considerable value, and some tools can also be checked in this regard. I don't think we can build a sufficiently strict and rigorous rule (to complete the abnormal check), because (abnormal) may be caused by the compiler's error. But I think it can be able to analyze the tools in (program) analysis tools, check whether there is suspicious code, whether there is unpreciated exception, and point these hidden vulnerabilities. three
1, Simplicity and SimpleXity
Bill Venners: C # and Java delivery object events have different ways. Java uses classes (INNER CLASSES), which implements the listener interfaces. C # uses delegates (delegates. Translator Note: VJ 6.0 introduces Delegates), it is a bit similar to function pointer. Why use the entrustment method?
Anders Hejlsberg: Please allow me to talk about the view of Simplicity in the general sense. No one is suspected of simple correctness, but there is a difference in how to achieve a simple problem. There is a simple, I want to call SimpleXity. You have made a very complicated thing, when you pack it as a simple thing, usually hide its complexity. So actually, you are not in designing a truly simple system. Such a packaging process, from some perspectives, the system may be more complicated by you, because users sometimes need to know that they are hidden. This is what I said simplexity.
For me, it is simple to be true, that is, when you need to drill the internal structure of the system in the future, it should be simpler, not more complicated than it.
2, commission and interface
Anders Hejlsberg: Entrustment provides unrelated to classes and interfaces, which is the most important place I think. Many programming languages in the past have recognized the importance of this approach. This approach has many names, such as function pointers, member function pointers, in Lisp languages, known as Closures, it is very useful.
Bill Venners: How is this implementation?
Anders Hejlsberg: Using the interface can indeed complete all the features of the delegate, but you will be forced to face troubled "household management". We can compare the procedures for Java and .NET processing events. Because there is no delegate in Java, the interface must eventually use.
The interface corresponds to an event, one interface can define 1, 2, 3, 4 or more methods. This has produced problems because this "correspondence" has no clear specifications. How many interfaces should I define how many interfaces are handled? Is every an interface corresponding to an interface or all events with an interface? Let you hide. Ok, let's choose the event of the component. Next, you must implement these interfaces. It is reasonable, if you handle the same events of the two components, you must implement the interface twice - you are of course not willing to do it, so in this case you need to create an adapter. In this way, the annoying "household management" will come to you.
Internal classes can help do little busy, but in the end, some questions You are can't escape - the event recipient must know when it receives an event. This way you must make a clear implementation of a monitor interface. In contrast, if you use a delegate, as long as the information is compatible, you can put all events together. This guy is not concerned how he is called, it is just a (handling event) method. Bruce Eckel: It seems that the entrustment is very thin.
Anders Hejlsberg: Yes, it is true.
Bruce Eckel: It is also more flexible.
Anders Hejlsberg: It is true. It relies only to information compatibility, such as whether the parameter is consistent. If it is compatible, you can put multiple events together. From the conceptual say, this is also fully satisfied with the expectations of the user's callback, right? Just give me some parameters, I can write a program. It sounds like a method, then I give a reference to this method, this reference is the entrusted of what I said.
Bruce Eckel: Finally, you will not drop the type check. Type check Is it in runtime?
Anders Hejlsberg: No, most of them are done when compiling. Once you create a commissioned instance, it is similar to the member function pointer used by the programmer in C . Delegate pointing to a method of an object. If it is a virtual method, you can also accurately determine the point of delegate. So in a sense, you can solve the virtual problem when instantiate. Calling can be seen as an indirect (Method) call instruction by the invocation of the entrustment.
Bruce Eckel: In addition to this, no longer need other indirect support.
Anders Hejlsberg: Yes, when constructing a delegate, you can solve the virtual function table (VTBL) and the point-to-direction problem of the delegate; the call to be implemented can be directly accurate. Therefore, it is necessary to dispatch more efficient than the interface, even if compared to standard methods, it is also high.
Bruce Eckel: C # also has a Multicast type delegation (Translator Note: Multicast is multi-point transmission. Refers to a delegate to correspond to multiple methods; if the delegate is called, it can cause calls to multiple methods. More detailed description Reference: http://msdn.microsoft.com/vjsharp/productinfo/
Visualj / Visualj6 / Technical / Articles / General / Delegates /), which enables multiple functions to be called. Is this an Orthogonal feature?
Anders Hejlsberg: Multicast is a complete Orthogonal feature. Honestly, if Multicast is important, I also hold a reservation attitude. I admit that it has its use, but if you speak, I think all the delegates are Single Cast. Some people think that Multicast is very important, using it has a lot of advantages, but in most cases, the commission is exactly Single Cast. In fact, we constructed (C #) The system is using Single Cast, as long as you (in this system) does not use Multicast, it will not pay for it.
Bill Venners: How is the delegation to reflect the simplicity and simplexity you mentioned earlier? Where are they reflected? Anders Hejlsberg: If you imitate the interface to achieve a delegate, then you will not be avoided to face "household management" and adapter issues. In fact, we can observe any development tools bundled with JavaBeans, they all generate some adapters and tell you: "You don't modify the following code, I will distribute some very thin and small help classes to you." This is for me Too complicated. It is not a truly simple system, it is actually very complicated, but it seems simple.
3, component concept in C # to high status
Bill Venners: O'Reilly website released an interview with you, at that time, you evaluated C # for properties and events: "Now, programmers are developing a large number of software components every day. They are not developing each other Programs and class libraries. Everyone develops new components that inherit the components provided from the environment. These new components overwrite some of the methods, attributes, and process some events, and then put these new components back (to the component library). This is a concept that must be established. "
I hope to better understand your conversation, because I have always thought that I was developing, not a component. Do you mean that many people are developing components used in Delphi, VB and Java for others? What is your "Components"?
Anders Hejlsberg: The most important meaning of the term "component" is that components can be portable well. This sounds very wonderful, but we may have different understandings. In a simplest Form, a component may be equivalent to a class attached to some data. Components are a separate software component that does not only contain code and data. It is a class that achieves self-exposure by attribute, method, and events; it is a class containing many additional features such as metadata, named mode. These features provide dynamic information to a particular development environment, such as how components use, how components persist themselves. The development environment can implement the intelligent interpretation of the component function and give the appropriate documentation. "Components" contain all (content) as described above.
Bill Venners: I thought when I was using Java, I was developing class libraries instead of component libraries, maybe because I think Get / Set is too cumbersome. When I have inspired the event, I also use GET / SET, but I didn't intend to get these classes to use it in an integrated development environment. I have always imagined these classes to use those purely encoded people. So I really want to know how many people now develop components like JavaBean, whether or not the assembly development is a future trend, because in my career, there is too little.
Anders Hejlsberg: Today, mainstream object-oriented programming languages are actually mixed. There is a large number of structured programming, and the object is basically just a structure containing a series of methods and a THIS pointer. When you think of an object or component, I think, from the concept, you should realize that it is attribute and event. If the programming language can give these conceptual heads, it is easy to understand it.
Some people may say that C # is supported by the attributes and events is just a "sweet fruit" (the translator Note: the original text is a term invented by syntactic sugar.peter Landin, meaning "Increase in the language, let people feel more comfortable "). In fact, it is indeed a sweet fruit, right? Oh, the object is a sweet fruit. But just in those virtual function tables (VTBL), you can implement the macro in the C language, right? Really, you can use C language to program objects, but it's complicated to let you fall into hell. Similarly, you can write components in C or Java, but because these languages are not given to component concepts enough, they have much pain. Also, what is, the property is not really an attribute, but getBLA and SetBLA (two methods). In the properties viewer, what you see is Black, but you should know that it is mapped to GET / SET. Obviously, component orientation is a general trend. We are using our classes through components, but in most languages, components do not become the most important concept. What I want to emphasize is that the component should have a head and other status. For PME programming mode - attributes, methods, events have lasted for a long time, we have also used these things in the day, why not give it to it in the programming language Treatment?
Note: Anders Hejlsberg resume
Anders Hejlsberg is a superior software engineer of Microsoft, and the leadership design C # (pronounced "C Sharp") programming language. HEJLSBERG worked in software career in the early 1980s, developed a Pascal compiler for MS-DOS and CP / M platforms. A small company in the establishment of a small company --borland - quickly hired Hejlsberg and acquired his compiler and then renamed Turbo Pascal. Hejlsberg Next leaders developed the replacement of Turbo Pascal: Delphi. In 1996, Hejlsberg was joining Microsoft after 13 Spring and Autumn for Borland (the translator's note: Borland contradicts and Microsoft's Attentive).
