Anders Hejlsberg on the process of C # design

Process | Design a

1. C # Design Process

?

Bruce Eckel: I heard that C # is an engineering team designed in a room?

Anders Hejlsberg: Yes. We have been in this room for 4 of years. Now, every Monday, five, we are still here to meet.

Bruce Eckel: I'd like to know something about the C # design process. I have been directly or indirectly involved in several language design tasks, such as Python. In the Python design process, Guido van Rossum was dubbed "benevolent Dictator" by us.

Anders Hejlsberg: Oh, Guido van Rossum is the equivalent of my position.

Bruce Eckel: So are you the "benevolent dictator" of the C # Group?

Anders Hejlsberg: I usually play the role of the last person to be the decider. For example, we have been plagued by a problem for a long time, and it is up to me to make the final decision when it is not possible to solve it but to make a choice. Of course, in most of these cases, the right choice is obvious.

Is Bruce eckel:c# 's design process similar to Turbo Pascal and Delphi?

Anders Hejlsberg: The design process of the latter two is not so normative. Because Turbo Pascal was designed by me alone, and Delphi was one of the few people I had with Chuck Jazdzewski and Gary Whizin, there was no need to introduce a very normative design process. On the contrary, C # 's design process is very normative, every Monday, five from 1:00 to 3:00, we will convene a formal meeting, the meeting agenda is quite flexible, all the questions will be on the table open discussion, careful scrutiny. We have also created a wiki on the Internet, and these problems and their solutions, and other related things are posted on it.

Bruce Eckel: So how did you find out about these problems?

Anders Hejlsberg: Oh, we have a set of effective methods. There are a number of ways in which users can get feedback on language design, such as software design consulting, network newsgroups. These feedback include: doubt, software bugs, inconsistency, nonstandard problem. So we can be targeted. Finally, we put these questions together and reproduce them. For each question, we will take it seriously and ask ourselves: "Do we have new ideas for this problem?" No, really? The problem has been on the shelf for weeks, and we'll take 30 minutes to focus on it and see if we can make a difference this time. ”

Bruce Eckel: That may be a problem for a long time unresolved, all stink ...

Anders Hejlsberg: Maybe some smelly problems can only be solved by putting them in the next version. But I think such a process would ensure that no problems are omitted, as they are all registered. Sometimes you sit for a long time with these problems and may not be the result. But the problem is, after all, caught by us, one day we will visit it again. It may not be a "visit", but the problem will not be lost.

What are the members of Bill Venners:c# 's design team and what role do they play?

Anders Hejlsberg: Scott Wiltamuth, Peter Golde, Peter Sollich, Eric Gunnerson and I were involved in the original C # design. The c#2.0 design team includes: Peter Hallam, Shon Katzenberger, Todd proebsting, and myself. Don Syme and Andrew Kennedy, of Microsoft Research, undertook most of the general work.

?

?

2. Language usability research and language aesthetics

?

Bill Venners: How does usability research, marketing strategy, and language aesthetics weigh in C # 's design?

Anders Hejlsberg: Generally speaking, good language design process embodies the aesthetic taste of the design team members of the integration, that is, you just said the language aesthetics. Aesthetic taste with great subjectivity, it is difficult to conclude, only after the product comes out, you can carefully appreciate it. I don't think any degree of usability research can replace the value of language aesthetics, because usability research is highly targeted and very specific. Someone may ask you: "What do you think of this part of the function?" "This question is difficult to answer. "What do you think of the language?" "Where do you start?" he said. How can you take two hours to get rid of all usability problems? There is no chance.

Bruce Eckel: People must understand this problem in depth.

Anders Hejlsberg: Using a programming language can go through a process of feeling subtle change. Only a few months after the user can really like it. They will gradually find out: "Oh, it feels very comfortable." "You can't be impatient.

As we started, we've done a lot of work on usability research, but it's mainly about specific features.

Bill Venners: Can you give me an example?

Anders Hejlsberg: We focus usability research on IDE functionality implementations. We ask ourselves: "Does the user know what will happen if the right button is clicked here?" "In the pure language feature, we've also considered usability issues--for example, on some properties and events--but it's not necessary, really.

I think in usability research, language features are unlikely to bring the same benefits as IDE features. You can see that the user clicks on a menu item to get the correct feedback immediately. But for language, the problem is a little more complicated. For example: "Is it easy to understand the concept?" "We have solved these problems better through user consultation and message boards," he said. Users need to have a place to talk, "I have some ideas for this new feature, how do you think about it?" "The more and sharper the problem, the better, because you're certainly the one who wants to know what the user thinks before it comes out, not after the product is launched." We usually consider the user's suggestions and comments before a language feature is completely finalized.

?

Two

1, the checked exceptions characteristic holds the attitude

?

(Translator Note: When writing a program, if you do not catch an exception with Try-catch or explicitly throw an exception, and you want the program to automatically throw, some language compiler will not allow the compiler to pass, such as Java is the case.) 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 good 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 do you decide whether to place this feature in C #?

Anders Hejlsberg: I found that checked exceptions has a larger problem with two aspects: extensibility and versioning. I know you've written something about checked exceptions, and you're leaning towards our view of the problem.

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

Anders Hejlsberg: Yes, to be honest, it does seem really important, and there's nothing wrong with that. I also applaud the wonderful nature of checked exceptions. But some aspects of its implementation will bring some problems. For example, from the implementation approach of checked exceptions in Java, I think it pays for a series of new problems while solving a series of problems. As a result, I don't know if checked exceptions characteristics can really make our life a little more beautiful. You may have a different view on this.

Has there been a lot of controversy over the checked exceptions characteristics of the Bruce eckel:c# design team?

Anders Hejlsberg: No, we have a broad consensus on this issue. C # is now silent on the checked exceptions. Once there is a recognized and better solution, we will reconsider it and adopt it where appropriate. I have a credo in life, and that is-if you don't have a say in the matter and you can't move forward with it, it's best to remain silent and neutral instead of an either.

Suppose you ask a novice to make a calendar control, they usually think: "Oh, I'll write the best calendar controls in the world!" I want it to have a variety of calendar appearances. It has a display section, there's this, there's that ... "They put all these ideas into the controls and then spent two days writing a crappy calendar program." They thought: "In the next release of the program, I will do more and better." ”

But once they begin to think about how to make the most of the abstract ideas in their minds, they will find that their original design is completely wrong. Now, they are squatting in a corner of the pain terrified, they found that the original design must be completely abandoned. I haven't seen it twice in this situation. I am a minimalist. For problems that affect the overall situation, don't bring it into the framework until you have a real solution, or you won't know what the framework will look like in the future.

Bruce Eckel: Extreme Programming (Extreme Programmers) said: "The simplest way to complete the work." ”

Anders Hejlsberg: Yes, Einstein also said: "act as simple as possible." "For the checked excpetions feature, I'm most concerned about what it might do to programmers." Imagine how messy and verbose the program will become when programmers invoke some newly-written APIs that have their own specific exception-throwing syntax. At this point you will understand that checked exceptions is not helping programmers, but is in trouble. The right thing to do is that the designer of the API tells you how to handle an exception rather than letting yourself think about it.

?

2, Checked exceptions version correlation

?

Bill Venners: You mentioned the extensibility and versioning dependencies of checked exceptions. Can you give me a concrete explanation of what they mean now?

Anders Hejlsberg: Let me first talk about version correlation, which is easier to understand. Suppose I created a method foo and declared that it might throw a, B, c three exceptions. In the new version of Foo, I'm going to add some features that may require exception D to be thrown. This creates a very damaging change because it is almost impossible to handle a D exception when this method was invoked.

??? That is, the user's code is compromised when an exception is added to the new version. There are similar problems when using methods in an interface. An interface that implements a particular function, once released, is immutable, and new features can only be added to the newer version of the interface. In other words, only a new interface can be created. In the new version, you have only two options, either creating a new method Foo2,foo2 can throw more exceptions, or catching exception D in the new Foo, and converting to the original exception a, B, or C.

Bill Venners: But even in languages without checked exceptions features (adding new exceptions) is not the same cause of damage to the program? What if the new version of Foo throws out a fresh exception that needs to be handled by the user, just because the user doesn't want the exception to happen, he can just ignore it when he writes the code?

Anders Hejlsberg: No, because in many cases, the user simply does not care (the exception). They will not handle any exceptions. In fact, there is a final exception handler in the message loop, and it displays a dialog box that prompts you to run an error. Programmers can use try finally to protect their own code anywhere, even if an exception occurs at run time, the program still works correctly. In fact, programmers do not care about the handling of the exception itself.

The throws syntax of many languages (such as Java) does not necessarily force you to deal with exceptions, which is forcing you to figure out the source of each anomaly. They require you to either capture declared exceptions or put them into the throws statement. Programmers have done a lot of ridiculous things to meet this requirement. For example, they must add modifiers when declaring each method: "Throws Exception". This is entirely a slap in the face of this feature, it simply requires the programmer to do more red tape, which is no good for anyone. fanned

Bill Venners: So, do you think it would be more useful in reality to not require programmers to explicitly deal with every unusual practice?

Anders Hejlsberg: Why do People think (explicit) exception handling is important? This is ridiculous. It's not important at all. In my memory, a very well written program, the number of try-finally and try-catch statements is about 10:1. In C #, you can also use a using statement that resembles a try finally (to handle an exception).

What the hell is Bill venners:finally doing?

Anders hejlsberg:finally guarantees that you are not disturbed by exceptions, but it does not handle exceptions directly. Exception handling should be placed somewhere else. In fact, in any event-driven (such as a modern graphical interface) program, there is a default exception handling process in the main message loop, and programmers only need to deal with exceptions that are not handled by default. But you have to make sure that the resources that were allocated can be destroyed in any exceptional circumstances. As a result, your program is sustainable. You certainly do not want to write the program, in 100 places to handle the exception and pop-up dialog box it. In that case, you'll have to make a big bad change. Exceptions should be handled centrally, and your code will be protected at the point where the exception is coming.

?

3. Extensibility of Checked Exceptions

?

Bill Venners: So what about checked exceptions's extensibility?

Anders Hejlsberg: Extensibility is sometimes associated with versioning. In a small program, Checked exceptions seems quite fascinating. You can catch filenotfoundexception anomalies and show them, isn't it interesting? This is also nice to call a single API. But when it comes to developing large systems, disaster strikes. You plan to include 4, 5 subsystems, and each subsystem throws 4 to 10 exceptions. But (in practice), each time you climb a ladder on a system integration, the new exception that must be handled will grow exponentially. Finally, it is possible for each subsystem to throw 40 exceptions. When you integrate two subsystems, you will have to write 80 throw statements. Finally, you may be out of control.

Most of the time, Checked exceptions can irritate programmers, so programmers try to circumvent this feature. He's either writing "throws Exception" all over the place, either--I don't know how many times I've seen it--write "Try, Da da, Da da da," which means to write a piece of code fast, catch curly curly (translator Note: ' {} '), and said, "Oh, I'll go back and deal with these empty exception-handling statements." "In fact, no one is going to go back and do these things," he said. At this time, Checked exceptions has caused a great decline in the quality of the system.

So you may be paying attention to these issues, but it's a bit of a consideration when we decide whether to put some of the checked exceptions mechanisms into C #. Of course, knowing what exceptions might be thrown in a program is valuable, and there are tools that can be used to check this. I don't think we can set up a strict and rigorous set of rules (to complete the anomaly check), because the (exception) may also be caused by compiler errors. But I think it's possible to do some work on the Profiling Tools, check for suspicious code, catch an unhandled exception, and point out the hidden vulnerabilities.

?

?

Three

1, simplicity and simplexity

?

Bill venners:c# and Java Pass object events in a different way. Java uses a class (usually an inner class (inner classes) that implements a listener interface (listener interfaces). C # uses a delegate (delegates. Translator Note: vj++6.0 introduced delegates, which is somewhat analogous to a function pointer. Why should we adopt the Entrustment method?

Anders Hejlsberg: Let me begin by talking about simplicity in the general sense. No one doubts the simplicity of correctness, but it is very different in how to achieve simple problems. There is a simple, I want to call simplexity. You do a really complex thing, and when you wrap it up as a simple thing, it usually hides its complexity. So in fact, you're not designing a really simple system. Such a packaging process, from some point of view, the system may be more complicated by you, because users sometimes need to know what is hidden. This is what I mean by simplexity.

For me, simplicity has to be really simple, that is to say, when you need to delve into the inner structure of the system at some point in the future, it should be simpler, not more complicated than the way it appears.

?

2. Delegates and Interfaces

?

Anders Hejlsberg: Delegates provide implementations that are not related to classes and interfaces, which is what I think is the most important place. Many of the past programming languages have recognized the importance of this approach. This approach has many names, such as function pointers, member function pointers, which are very useful in Lisp, called closures.

Bill Venners: So how did this happen?

Anders Hejlsberg: Using interfaces does accomplish all the functions that a delegate has, but you will be forced to face the tumultuous "housekeeping." We can compare the process of Java and. NET handling events. Because there are no delegates in Java, interfaces must eventually be used.

interfaces correspond to events, and an interface can define 1, 2, 3, 4, or even more methods. This has created a problem because there is no clear specification for this "counterpart". How many interfaces should be defined to handle the event? is each event corresponding to an interface or all events using an interface? Makes you hard to choose. OK, let's start by randomly selecting the event to process the component. Next, you have to implement these interfaces. Of course, if you deal with the same event for two components, you have to implement the interface two times-you don't want to do that, so in this case, you also need to create an adapter. In this way, tumultuous's "housekeeping" came to you.

Internal classes can be a little helpful in dealing with chores, but in the end, there are some problems you can't escape-the event receiver must know when it will receive the event. This way you must explicitly implement a listener interface. Conversely, if you use a delegate, you can put all the events together as long as the information is compatible. This guy doesn't care how he gets called, it's just a way of dealing with the event.

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

Anders Hejlsberg: Yes, that's true.

Bruce Eckel: It's also more flexible.

Anders Hejlsberg: That's true. It depends only on the compatibility of the information, such as whether the parameters are consistent. If it's compatible, you can put multiple events together. Conceptually, this also fully satisfies the user's expectation of a callback, right? Just give me some parameters and I can write a program. Sounds like a method, then I give a reference to the method, and that reference is what I call a delegate.

Bruce Eckel: In the end you won't lose type checking. is type checking done at run time?

Anders Hejlsberg: No, most of them are at compile time. Once you create an instance of a delegate, it is almost the same as the member function pointer that the programmer uses in C + +. A delegate points to a method of an object. If it is a virtual method, you can also accurately judge the direction of the delegate. So in a sense, you can solve a virtual problem when instantiating a delegate. A delegate-implemented invocation can be viewed as an indirect (method) invocation instruction.

Bruce Eckel: Beyond that, there is no need for other indirect support.

Anders Hejlsberg: Yes, when you construct a delegate, you can resolve the point of the virtual function table (VTBL) and the delegate at once, and you can get the corresponding method directly and accurately by the invocation of the delegate implementation. Therefore, the delegate is more efficient than the interface dispatch, even if compared with the standard method dispatch, it is more efficient.

Bruce eckel:c# also has multicast type of delegate (Translator Note: multicast is multicast. Refers to a delegate that can correspond to multiple methods, and when a delegate is invoked, it can cause calls to multiple methods. More detailed instructions can refer to: http://msdn.microsoft.com/vjsharp/productinfo/

visualj/visualj6/technical/articles/general/delegates/), which enables multiple functions to be invoked. Is this a orthogonal feature?

Anders Hejlsberg:multicast is a downright orthogonal trait. Frankly speaking, I have reservations about whether it is important to multicast the issue. I admit that it has its uses, but conservatively speaking, I think all the delegates are single cast. Some people think that multicast is very important and there are many advantages to using it, but in most cases the delegates are just single cast. In fact, we construct a (C #) system that uses single cast, and as long as you don't use multicast in this system, you don't pay for it.

Bill Venners: How does a delegate represent the simplicity and simplexity you mentioned earlier? Where do they all show up?

Anders Hejlsberg: If you follow an interface to implement a delegate, you will inevitably face "housekeeping" and adapter problems. In fact, we can look at any development tool bundled with JavaBeans that will generate some adapters and tell you: "You don't want to change the following code, I'll distribute some very skinny help to you." "It's too complicated for me," he said. It's not really a simple system, it's actually very complex, but seemingly simple.

?

3, the component concept in C # high position

?

The Bill Venners:o ' Reilly website posted an interview for you, when you rated C # for attributes and events: "Now, programmers are developing a lot of software components every day." They are not developing isolated applications and class libraries. Everyone is developing new components that inherit from the components provided by the environment. These new components override some of the parent component's methods, properties, handle some events, and then put the new components back (to the component library). This is the first concept to be established. ”

I hope to understand your conversational spirit better because I have always thought I was developing a class rather than a component. Are you saying that a lot of people are developing components used in Delphi, VB and Java for others? What exactly do you mean by "component"?

Anders Hejlsberg: The most important meaning of the word "component" is that components can be ported well. It sounds wonderful, but we may have a different understanding of it. In one of the simplest form, a component may be equivalent to a class with some data attached. A component is a stand-alone software component that contains more than just code and data. It is a class that exposes itself through attributes, methods, and events, and is a class that contains many additional features, such as metadata, naming patterns, and so on. These features provide dynamic information to specific development environments, such as how components are used and how components persist their data. The development environment uses the component's metadata to realize the intelligent interpretation of component functions and gives the corresponding explanatory documents. "Component" contains all (content) as described above.

Bill Venners: When I was using Java for development, I thought I was developing a class library instead of a component library, probably because I thought get/set was too unwieldy. I also use get/set when it comes to motivating events, but I'm not going to take these classes to the integrated development environment, and I've always imagined these classes to be used by people who are purely coded. So I'd like to know how many people are developing components like JavaBean, and whether component development is a future trend, because I've had too few dealings with components in my career.

Anders Hejlsberg: Today, the mainstream object-oriented programming language is actually mixed-race. There is a lot of structured programming, and objects are basically just a structure that contains a series of methods and a this pointer. When you think of an object or component, I think, conceptually, you should realize that it has attributes and events. If the programming language can give these concepts first class treatment, it will be easier to understand it.

Some might say that C # 's support for attributes and events is just a "sweet fruit" (Translator Note: The original is syntactic sugar. Peter Landin invented a term that means "add to the language and make people feel more comfortable". It really is a sweet fruit, isn't it? Well, the object is a sweet fruit. We're just spinning around in those virtual function tables (VTBL), and you can do it with a C-language macro, right? Really, you can use the C language for object-oriented programming, but it's complicated enough to 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 place. It also has to be explained that attributes are not really a property, but Getbla and Setbla (two methods). In the property observer, you see BLA, but you should know that it maps internally to Get/set.

It is clear that component orientation is the general trend. We are using our classes through components, but in most languages, components are not the most important concepts. I want to emphasize that components should have a first class position. The talk of PME programming patterns--attributes, methods, events--has been going on for a long time, and we've all been using these things to program day in and year out, so why not give it the right treatment in a programming language?

?

?

Note: Anders Hejlsberg CV

??? Anders Hejlsberg is a Microsoft company's excellent software engineer, and led the design of C # (pronounced "C Sharp") programming language. Hejlsberg joined the software business in the early 80 and developed Pascal compilers for MS-dos and cp/m platforms. Shortly after the establishment of a small company,--borland--soon hired Hejlsberg and acquired his compiler, then renamed Turbo Pascal. Hejlsberg next led the development of the alternative product of Turbo Pascal: Delphi. Hejlsberg joined Microsoft in 1996 after 13 years of working for Borland (translator: Because of Borland's internal contradictions and Microsoft's hospitality).