Anders hejlsberg on C # Design Process

I

1. C # Design Process

 

Bruce Eckel: I heard that C # was designed by an engineer team in a room?

Anders hejlsberg: Yes. We have been in this room for four years. Now, we are still meeting here every Monday, three, and five.

Bruce Eckel: I 'd like to know more about the C # design process. I have been directly or indirectly involved in the design of several languages, such as Python. During the python design process, Guido van rosum was dubbed as a "benevolent dictatorship ".

Anders hejlsberg: Oh, Guido van Rossum is equivalent to my location.

Bruce Eckel: So are you a C # group "benevolent dictatorship?

Anders hejlsberg: I generally assume the role of the final photographer. For example, when we are troubled by a problem and cannot solve it, we can only make the best choice. It is up to me to make the final decision. Of course, in most cases, the right choice is obvious.

Bruce Eckel: Is the design process of C # very similar to that of Turbo Pascal and Delphi?

Anders hejlsberg: the design process for the latter two is not so standard. Since Turbo Pascal is mainly designed by me, and Delphi is also completed by a few people, such as Chuck jazdzeski and Gary whizin, there is no need to introduce a very standard design process. On the contrary, the design process of C # is very standard. Every Monday, 3, and 5 from to, we will hold a formal meeting, and the agenda of the Meeting is quite flexible, all questions will be discussed publicly and carefully on the desktop. We have also established a wiki on the Internet. These problems, solutions, and other related things have been published.

Bruce Eckel: How did you find these problems?

Anders hejlsberg: Well, we have a set of effective methods. We can use many ways to get feedback on language design, such as software design consulting meetings and online news groups. These feedbacks include questions, software buckets, inconsistencies, and non-standard issues. In this way, we can be targeted. Finally, we organized these issues into tables and reproduced them one by one. We take every question seriously and ask ourselves: "Do we have new ideas on this question? Really? This issue has been put on hold for several weeks. We immediately spent 30 minutes studying it to see if it can be achieved this time ."

Bruce Eckel: Maybe a problem has not been solved for a long time ......

Anders hejlsberg: maybe some stinks can be solved only in the next version. However, I believe that such a process will ensure that no problems are missed because they are all registered. Sometimes, you have been sitting on these issues for a long time, and there may be no results. But after all, the problem is caught by us. One day we will "visit" it again. It may not be "visiting" again, but the problem will not be lost.

Bill Venners: C # who are included in the design team and What roles are they responsible?

Anders hejlsberg: Scott wiltamuth, Peter Golde, Peter sollich, Eric Gunnerson and I were involved in the initial C # design. C #2.0 design teams include Peter Hallam, Shon katzenberger, Todd proebsting, and myself. Don Syme and Andrew Kennedy from Microsoft Research Institute undertake most of the general research work.

 

 

2. language availability research and language Aesthetics

 

Bill Venners: in the design of C #, how is the focus of usability research, market strategy, and language aesthetics weighed?

Anders hejlsberg: In general, a good language design process reflects a Comprehensive Aesthetic Taste orientation of design team members, that is, the linguistic aesthetic view you just mentioned. Aesthetic taste is subjective and hard to determine. You can appreciate it carefully only after the product is released. I believe that availability research at any level cannot replace the value of language aesthetics, because availability research is very targeted and very specific. Someone may ask you, "What do you think of these functions ?" This question is hard to answer. "What do you think about this language ?" Where do you start? How can you solve all availability problems in two hours? Impossible.

Bruce Eckel: people must have a deep understanding of this issue.

Anders hejlsberg: using a programming language can experience a process of subtle changes. Only a few months later can users really like it. They will gradually find: "Oh, it makes people feel comfortable ." You cannot rush for success.

We have done a lot of work on availability research, but it is mainly for specific functions.

Bill Venners: Can I give an example?

Anders hejlsberg: we focus on implementing ide functions. We will ask ourselves: "Do users know what the result will be after right-clicking here ?" In the pure language feature section, we also considered some availability issues-for example, some attributes and events-but there is no need, really.

I think in terms of availability research, language features cannot bring the same benefits as IDE features. You can see that the user clicks a menu item to get the correct feedback immediately. For languages, the problem is more complicated. For example, "is its concept easy to understand ?" We have solved these problems through user consultation meetings and message boards. The user needs to have something to talk about. "How do you think about this new feature ?" The more you raise such questions, the better the sharpness, because you certainly want to know your thoughts before the product is released, rather than after the product is launched. Before a language feature is finalized, we usually consider users' suggestions and opinions.

 

II

1. reserved for the checked exceptions feature

 

(Note: When writing a program, if you do not use try-catch to catch exceptions or explicitly throw exceptions, and want the program to throw automatically, the compiler in some languages will not allow compilation to pass, such as Java. This is the basic meaning of checked exceptions. This feature is designed to ensure program security and robustness. Zee & snail key (MVP) has a very good image. For details, refer:

Http://www.blogcn.com/user2/zee/main.asp. Bruce Eckel also has a related article (does Java need checked exceptions). For details, see:

Http://www.mindview.net/Etc/Discussions/CheckedExceptions)

Bruce Eckel: C # No checked exceptions. How do you decide whether to place this feature in C?

Anders hejlsberg: I found that checked exceptions has two major problems: scalability and version control. I know that you have also written some things about checked exceptions, and we tend to think about it.

Bruce Eckel: I always think checked exceptions is very important.

Anders hejlsberg: Yes, to be honest, it seems very important, and there is nothing wrong with this point of view. I also really appreciate the wonderful features of checked exceptions. However, its implementation may cause some problems. For example, from the implementation of checked exceptions in Java, I think it has paid a series of new problems while solving a series of existing problems. In this way, I don't know whether the checked exceptions feature can really make our lives better. You may have different opinions on this.

Bruce Eckel: C # Does the design team have a lot of debate about the checked exceptions feature?

Anders hejlsberg: No, we have a broad consensus on this issue. C # currently, checked exceptions is reserved. Once there is a recognized and better solution, we will reconsider and adopt it where appropriate. I have a new message, that is, if you do not have the right to speak about the problem and cannot push forward the solution process, it is best to stay in silence and neutral, instead of posing a different posture.

Suppose you have a newbie compile a calendar control. They usually think like this: "Oh, I will write the best calendar control in the world! I want it to have a variety of calendar appearances. It has the display part, this, and that ......" They put all these ideas into the controls and spent two days writing a very bad calendar program. They thought, "in the next version of the program, I will implement more and better functions ."

However, once they begin to consider how to implement so many abstract ideas in their minds, they will find that their original design is completely wrong. Now, they are squatting in a corner, and they find that they must discard the original design. I did not see this situation twice. I am a minimalist. For problems that affect the global architecture, do not bring it into the entire framework until there is no actual solution. Otherwise, you will not know what the framework will look like in the future.

Bruce Eckel: "the easiest way to do the job," said the extreme programmers ."

Anders hejlsberg: Yes, Einstein also said: "act as simple as possible ." For the checked excpetions feature, I am most concerned about what problems it may bring to programmers. Imagine how messy and lengthy the program will become when a programmer calls a newly written API with a specific exception and throws a syntax. At this time, you will understand that checked exceptions is not to help programmers, but to make trouble. The correct method is that the API designer tells you how to handle exceptions rather than making yourself think about it.

 

2. Version relevance of checked exceptions

 

Bill Venners: You mentioned the scalability and version relevance of checked exceptions. Can you explain what they mean?

Anders hejlsberg: Let me first talk about version relevance, which is easier to understand. Suppose I have created a method Foo and declared that it may throw three exceptions: A, B, and C. In the new Foo version, I want to add some functions, and thus may need to throw an exception D. This produces a very destructive change, because it is almost impossible to handle the D exception when calling this method.

That is to say, when an exception is added in the new version, the user's code is damaged. Similar problems occur when using methods in interfaces. Once released, an interface implementing specific functions cannot be changed. New functions can only be added to the new interfaces. In other words, only new interfaces can be created. In the new version, you only have two options: Create a New Method foo2, foo2 can throw more exceptions, or capture exceptions in the new Foo, and convert it to the original Exception A, B, or C.

Bill Venners: But even in languages without the checked exceptions feature, isn't (adding new exceptions) the same damage to the program? If the new Foo version throws a new exception that needs to be handled by the user, is it possible for the user to ignore this exception only when writing code?

Anders hejlsberg: No, because in many cases, the user does not care at all (exception ). They will not handle any exceptions. In fact, there is a final exception handler in the message loop. It will display a dialog box prompting you to run an error. Programmers can use try finally anywhere to protect their code. Even if an exception occurs during running, the program can still run correctly. In fact, programmers do not care about exception handling.

The throws syntax (such as Java) in many languages does not need to force you to handle exceptions, that is, to force you to figure out the source of each exception. They require you to either capture declared exceptions or put them into throws statements. Programmers have done a lot of ridiculous things to meet this requirement. For example, when declaring each method, they must add the modifier "throws exception ". This is entirely a slap in the face of this feature. It only requires programmers to write more official articles, which is no good for anyone.

Bill Venners: in this case, do you think programmers are much more practical than explicitly handling every exception?

Anders hejlsberg: Why do people think (explicit) exception handling is very important? This is ridiculous. It doesn't matter at all. In my impression, in a very well-written Program, the number of try finally and try catch statements is about. In C #, you can also use a using statement similar to try finally to handle exceptions ).

Bill Venners: What did finally do?

Anders hejlsberg: Finally ensures that you are not disturbed by exceptions, but it does not directly handle exceptions. Exception Handling should be placed somewhere else. In fact, in any event-driven (such as the modern graphic interface) program, there is a default exception handling process in the main message loop, programmers only need to handle exceptions that are not handled by default. However, you must ensure that the originally allocated resources are destroyed in any abnormal circumstances. In this way, your program runs continuously. When you do not want to write a program, you must handle exceptions in 100 places and bring up a dialog box. If that is the case, it would be too bad for you to make changes. You should handle exceptions in a centralized manner and protect your code when exceptions occur.

 

3. scalability of checked exceptions

 

Bill Venners: What is the scalability of checked exceptions?

Anders hejlsberg: scalability is sometimes related to version. In a small program, checked exceptions looks quite charming. You can capture and display filenotfoundexception exceptions. Isn't it interesting? This is also wonderful when calling a single API. However, when developing a large system, the disaster will come. You plan to include four or five subsystems. Each subsystem throws 4 to 10 exceptions. However, every time you climb a level on a system integration ladder (during actual development), new exceptions that must be handled will increase exponentially. Finally, each subsystem may need to throw 40 exceptions. When you integrate two subsystems, you must write 80 throw statements. Finally, you may not be able to control it.

In many cases, checked exceptions will irritate programmers, so programmers will try to bypass this feature. He either writes throws exception everywhere, or -- I don't know how many times I have seen -- write "try, da: catch curly (Translator's note: '{}') "and then say," oh, I will go back and handle these null Exception Handling statements." In fact, no one, of course, will go back to these tasks. At this time, checked exceptions has greatly reduced the system quality.

Therefore, you may pay great attention to these issues, but it is quite time-consuming to decide whether to put some mechanisms of checked exceptions into C. Of course, knowing what exceptions may be thrown in the program is quite valuable. Some tools can also be used for this check. I don't think we can establish a set of strict and rigorous rules (to complete exception checks), because (Exceptions) may also be caused by compiler errors. However, I think you can make some effort in the (Program) analysis tool to detect suspicious code, uncaptured exceptions, and point out these hidden vulnerabilities to you.

 

 

3.

1. Simplicity and simplexity

 

Bill Venners: C # and Java use different methods to pass object events. Java class (usually internal class (inner classes), which implements the listener interface (listener interfaces ). C # uses the delegate. Note: VJ ++ 6.0 introduces delegates, which is similar to function pointers. Why do we need to use delegation?

Anders hejlsberg: Let me first talk about simplicity in the general sense. No one doubts the correctness of simplicity, but the question of how to implement simplicity varies widely. I want to call it simplexity. You have made a very complex thing. When you wrap it into a simple thing, it usually hides its complexity. So in fact, you are not designing a really simple system. From some perspective, the system may be more complicated because users sometimes need to know what is hidden. This is what I call simplexity.

For me, simplicity must be really simple. That is to say, when you need to study the internal structure of the system at some point in the future, it should be simpler, not more complex than what it looks like.

 

2. Delegation and interfaces

 

Anders hejlsberg: The delegate provides implementation methods unrelated to classes and interfaces, which is what I think is the most important. Many programming languages in the past have recognized the importance of this method. This method has many names, such as function pointers and member function pointers. In lisp, closures is very useful.

Bill Venners: how is this implemented?

Anders hejlsberg: Using Interfaces can indeed complete all the functions of delegation, but you will be forced to face complicated "Household Management ". We can compare the process of processing events in Java and. net. Because there is no delegate in Java, the interface must be used in the end.

An interface corresponds to an event. An interface can define 1, 2, 3, 4, or more methods. This has produced problems because there is no clear specification for this "correspondence. How many interfaces should be defined to process events? Is an event corresponding to an interface or an interface used for all events? This makes it difficult for you to choose. Well, let's randomly select one of them to process component events. Next, you must implement these interfaces. Of course, if you are dealing with the same events of two components, you must implement the interface twice-You certainly do not want to do this, so in this case, you also need to create an adapter. In this way, the complicated "Housework management" will come to you.

The internal class can be a little helpful in dealing with the issue, but in the end, you cannot escape some problems-the event receiver must know when it will receive the event. In this way, you must implement a listener interface explicitly. In contrast, if you use a delegate, as long as the information is compatible, you can put all events together for processing. This guy doesn't care how he is called. It is just a (event processing) method.

Bruce Eckel: It seems that the Commission is very lean.

Anders hejlsberg: Yes, indeed.

Bruce Eckel: it is also more flexible.

Anders hejlsberg: Indeed. It only depends on information compatibility, such as whether the parameters are consistent. If it is compatible, you can put multiple events together for processing. In terms of concept, this fully satisfies the user's expectation for a callback result, right? Just give me some parameters and I can write the program. It sounds like a method, so I give a reference to this method, and this reference is what I call delegate.

Bruce Eckel: In the end, you won't lose the type check. Is the type check performed at runtime?

Anders hejlsberg: No. Most of them are performed during compilation. After you create a delegate instance, it is similar to the member function pointer used by programmers in C ++. A delegate is a method that points to an object. If it is a virtual method, you can accurately determine the direction of the delegate. So in a sense, you can solve the virtual problem when instantiating the delegate. The call implemented by delegation can be considered as an indirect (method) Call Command.

Bruce Eckel: In addition, other indirect support is no longer needed.

Anders hejlsberg: Yes. When constructing a delegate, you can solve the virtual function table (vtbl) and delegate pointing problems at one time; the corresponding methods can be obtained directly and accurately through calls implemented by delegation. Therefore, delegation is more efficient than interface dispatch, even though it is more efficient than standard method dispatch.

Bruce Eckel: C # also has multicast-type delegation. A delegate can correspond to multiple methods. When a delegate is called, multiple methods can be called. More detailed description can refer to: http://msdn.microsoft.com/vjsharp/productinfo/

Visualj/visualj6/technical/articles/General/delegates/), which can call multiple functions. Is this an orthogonal feature?

Anders hejlsberg: multicast is a complete orthogonal feature. To be honest, I am also reserved for the importance of multicast. I admit that it is useful, but conservatively speaking, I think all the delegates are single cast. Some people think that multicast is very important. Using it has many advantages, but in most cases, the delegate is exactly single cast. In fact, the (C #) system we construct uses single cast. As long as (in this system) You do not use multicast, you will not pay for it.

Bill Venners: How does delegate reflect the simplicity and simplexity you mentioned earlier? Where are they all reflected?

Anders hejlsberg: if you follow the interface to implement delegation, you will inevitably face "Housework management" and adapter problems. In fact, we can observe any development tool bundled with JavaBeans, which will generate some adapters and tell you: "You do not need to modify the following code, I will distribute some very small help classes to you." This is too complicated for me. It is not really a simple system. It is actually very complicated, but it seems simple.

 

3. Component concept in C #

 

Bill Venners: O 'Reilly posted an interview with you. At that time, you evaluated C #'s support for attributes and events: "Now, programmers develop a large number of software components every day. They are not developing isolated applications and class libraries. Everyone is developing new components that inherit the components provided by the environment. These new components cover some methods and attributes of the parent component, process some events, and then put these new components back (to the component library ). This is the first concept to be established ."

I hope to better understand your conversation spirit, because I always think that I am in development rather than components. Do you mean that many people are developing components used in Delphi, VB, and Java for others? What are the "components" you are talking about?

Anders hejlsberg: the most important word contained in the word "component" means that the component can be well transplanted. This sounds wonderful, but we may have different understandings about it. In the simplest form, a component may be equivalent to a class with some data appended. A component is an independent software component that not only contains code and data. It is a class that implements self-exposure through attributes, methods, and events. It is a class that contains metadata, naming patterns, and many other additional features. These features provide dynamic information for specific development environments, such as how components are used and how components persist their data. The development environment uses the metadata of components to Intelligently interpret component functions and provide relevant instructions. The "component" contains all (content) described above ).

Bill Venners: When I use Java for development, I think that I am developing a class library instead of a component library, probably because I think get/set is too heavy. I also use GET/set when initiating events, but I am not planning to use these classes in the integrated development environment, I have always imagined that these classes are used by pure coding people. So I really want to know how many people are developing components similar to JavaBean, and whether component-oriented development is a future trend, because in my career, too little dealing with components.

Anders hejlsberg: Today, mainstream object-oriented programming languages are actually mixed. There are a lot of structured programming, and the object is basically a struct containing a series of methods and a this pointer. When you think of an object or component, I think, in terms of concept, you should realize that it has attributes and events. If programming languages can give these concepts a top priority, it is easier to understand them.

It may be said that C #'s support for attributes and events is just a "sweet fruit" (Translator's note: the original article is syntactic sugar. A term invented by Peter landin means "adding to the language and making people feel more comfortable. In fact, it is indeed a sweet fruit, right? Well, the object is a sweet fruit. We just need to compress on those virtual function tables (vtbl). You can also use the Macros in C language, right? Really, you can use C language for Object-Oriented Programming, but its complexity can make you fall into hell. Similarly, you can write components in C ++ or Java, but it is much more painful because these languages do not give the component concept an important position. It must be noted that the property is not really an attribute, but getbla and setbla (two methods ). In the attribute observer, You can see Bla, but you should know that it is mapped to get/set internally.

Obviously, component orientation is the trend of the times. We use our classes through components, but in most languages, components are not the most important concept. I want to emphasize that components should have a top priority. We have been talking about PME programming patterns-attributes, methods, and events-for a long time, and we are all using these things for programming day after day, so why not give it the highest treatment in programming languages?

 

 

Note: Resume of Anders hejlsberg

Anders hejlsberg is an excellent software engineer at Microsoft, leading the design of C # (pronounced "C sharp") programming language. Hejlsberg joined the software business in the early 1980s S and developed the PASCAL Compiler for the MS-DOS and CP/M platform. Borland, a short-founded company, quickly hired hejlsberg, acquired his compiler, and renamed it Turbo Pascal. Hejlsberg then led the development of the replacement product of Turbo Pascal: Delphi. In 1996, hejlsberg joined Microsoft after 13 years of work for Borland ).