A Conversation with Anders Hejlsberg
THE C # Design Process
Http://msdn.microsoft.com/vcsharp/homepageheadlines/hejlsberg/
Designing with a Living Agenda
Bruce Eckel: I heard that C # is a group of people developed in a room
Anders Hejlsberg: Yes, four years have been in the same room, now every Monday, Wednesday, and Friday, we are still in that room.
Bruce Eckel: I am very concerned about the C # design process. I directly or indirectly involved in several different languages. For Python, Guido Van Rossum B is humorously called a philasers.
Anders Hejlsberg: It is like my current position.
Bruce Eckel: Are you a dictator of C #?
Anders Hejlsberg: In fact, I am a referee. If we walk around for a long time, it is time to decide, I will decide; in general, decision is obvious
Bruce Eckel: Is it as the design of Turbo Pascal with Delphi?
Anders Hejlsberg: Those are not quite formulated, Turbo Pascal is basically me. I and Chuck Jazdzewski, Gary Whizin designed Delphi, but the group is too small, and it does not seem to need a regular process. And C # is a regular process: every Monday, Wednesday, and Friday, we have to open a formal regular meeting. The problem took over the water and then resolved it. There is a list of questions on the Wiki in our internal network, one to solve them, and so on.
Bruce Eckel: How is the problem?
Anders Hejlsberg: Oh, this is what we do. Users can use many ways - design reviews, newsgroups, give us feedback on language. These feedback generate problems, errors, contradictions, and morbidity. We know what we have to do. We repeatedly study questions on the list, we see one, ask: "Is there a new idea for this? No, good, this thing has been lying here a few weeks, let us spend thirty minutes to handle it Let's see what extent can I deal with this time.
Bruce Eckel: So when this is very bad?
Anders Hejlsberg: or things look very good, in the next version you want to use it, then you continue to solve. I think this is a way to ensure that there is no omission. You put all things on the list, some things you may decide not to do it, so stay in the list, but eventually it will be noticed again; you may go to solve or not, but it will not be lost.
What is the Bill Venners: C # design group, what role do you have?
Anders Hejlsberg: The original design team has Scott Wiltamuth, Peter Golde, Peter Sollich, Eric Gunnerson, and I, C # 2.0 design teams include Peter Hallam, shon katzenberger, titd proebsting and me. In the end, I would like to thank the Microsoft Research Institute Don Syme and Andrew Kennedy.
Availability or aesthetic philosophy
Bill Venners: How much is based on availability research, how much is the market choice, how much is the aesthetic choice? Anders Hejlsberg: Undoubtedly, good language design is attributed to a combination of a joint taste. Attributed to programming aesthetics, like you said. A good taste is very subjective, it is difficult to define, but when you touch it, you will recognize it. I think a good taste will bring you many usability research institutes can't give you, because availability research is very high.
A survey may ask: "What do you think this feature?" But it is not good, "Do you think this language?" Where did you start, how do you solve it through two hours of availability research, this is impossible of.
Bruce Eckel: Some people want to understand the depth
Anders Hejlsberg: It is a gradual process with a language. Only after you have used it for a few months, you can truly understand this language. You can gradually realize "Oh, this is really comfortable", you can't realize soon. In other words, we have made a lot of availability research, but the results are still positioned in some feature.
Bill Venners: For example?
Anders Hejlsberg: Most of them are the availability of IDE. We may ask, "Can people understand what these and what are these and what?", We have done some applicability research on plain grammar, such as attributes and events, but it is really unnecessary. I think the availability study of language characteristics is not like the benefits of Ide. IDE is very interactive. You can observe the user right-click menu to get good feedback. For programming languages, the problem is deeper. "Is its concept easy to understand?" You can set up the user advisory committee, there is a echo board, put it in the place you can release, you said, "This is us About this new character, how do you see ", you want them to mention more, because you want to know more questions before submitting this feature. Therefore, unless a language feature has been fully tested, we have to use this echo board.
2.The Trouble with checked exceptions
Keep CHECKED EXCEPTIONS
Bruce Eckel: C # No Checked Exceptions, how do you decide whether to join Checked Exceptions?
Anders Hejlsberg: I see two big issues for Checked Exception: upgradeable and version control. I know that you also wrote some articles about Checked Exceptions, you and we think about it.
Bruce Eckel: I used to think what checked exceptions...
I have considered Checked Exceptions that CHECKED EXCEPTIONS.
Anders Hejlsberg: Frankly said that it is really not good when it came out, and there is no mistake on the concept. I fully agree that Checked Exceptions is an excellent thing, but it is a bit problem that is used. Take the Java implementation, there is an additional problem, in fact it doesn't make my life simpler, but only change Soup does not change the medicine.
Bruce Eckel: Is there no objection in the C # design team?
Anders Hejlsberg: No, agree
Basically C # is kept silent on checked exceptions. Once better solutions are found - I believe I have been thinking - we can return it, then add it. I am convinced that if you don't have a solid reason, you can't drive technological progress, it is best to keep silent and neutral, do not add it.
If you call a novice to write a calendar control, he will think, 'Oh, I want to write a world's best calendar control, which has a variety of forms, which have a display page, adjuster, this one. They put all the basic structures, then spend two days to write an app. They think, 'Next versions, I will do more' then they have begun to consider how to implement their abstract design, then find that their design is completely wrong, put them into the dilemma, have to give up. I don't know how many times I have seen. I am convinced that you should maintain the minimum requirement. Unless you really want to solve a general problem, don't change the framework for special problems. Because you don't know what the final appearance of the framework is.
Bruce Eckel: Extreme Programming, 'Be the simplest thing, as long as it works
Anders Hejlsberg: Yes, Einstein said, 'as the simplest thing as possible, but don't simply
My scruple for Checked Exceptions is that it has brought inconvenience to programmers. You got a cluster of Apis with the throws statement, your code will become very tuned; you will recognize that checked exception is no group. It seems that these dictatorship API designers will guide you how to capture abnormalities. They are not right.
Versioning with checked exceptions
Bill Venners: You mention your concerns about Checked Exceptions in upgraded and version control. Can you specifically tell these two questions?
Anders Hejlsberg: First, version issues, this is easy to see. For example, I have a method of foo declare throwing anomalies A, B and C. In the second edition of foo, I added some features, and now it has to throw an exception D. But this change is destructive because the existing calorker certainly did not capture this exception.
Add a new exception in the new version to destroy the customer code, just like adding a new way in the interface. Once you have released an interface, no matter what you can't change, because all programs that use it may have the same method in the next version. So you can only create a new interface instead. Similar to this, you have to rebuild a new way to throw more exceptions, or you have to capture exception D in the new foo, then convert to, A or B or C.
Bill Venners: But it seems to destroy code, even in a language without Checked Exceptions. If you throw the exception that the customer doesn't take into account in the new version of Foo, then it doesn't destroy their code because they write the code, but I don't expect this anomaly.
Anders Hejlsberg: Nothing, because in many cases, people don't mind. They don't capture these anomalies. There is usually an abnormal capture in their messy cycle. Here will pop up a dialog say something wrong and then continues. The programmer usually writes try..finally to protect their code, if an abnormality occurs, it will exit normally, indicating that he does not interested in these exceptions. Throws statement, at least Java implementation, unnecessarily stronger you to capture exceptions, even if you don't want to capture them, it will also want you to know what exception will be thrown. It requires you or captures them, or join your throw statement. For these, we have to do a lot of cumbersome things, for example, declare throws Exception in every method, this is fooling, making programmers write more eight shares, no use.
Bill Venners: So you think that the invigon usually does not significantly capture these exceptions, not to capture with catch chain.
Anders Hejlsberg: Weird is that people think that important things are to capture abnormalities, which is not the key to abnormal. In a good program written, my opinion, try..finally should be ten more than ten. In C #, the USING statement is a bit like try ... finally.
Bill Venners: What do you do in FINALLY?
Anders Hejlsberg: In the Finally clause, you have made your code continue to perform even anomalus, but you can't catch them. Error handling place elsewhere. The application-driven application that is like modern UI is typically placed in the main message loop; abnormality is captured here. In other places, you use try ... finally to ensure that you apply for the resources you apply, you have cleaned these things, you always keep a consistent state. You don't have to capture an exception in 100 places and pop up the error dialog box.
If you want to change the way you pop up the dialog, it is horrible. Abnormal processing should be concentrated. You only need to protect your code because an exception spreads to an exception processor.
CHECKED EXCEPTIONS upgradeability
Bill Venners: What is the upgradeability of Checked Exception?
Anders Hejlsberg: How much is a bit and version control of the upgradeability. Simply look, Checked Exceptions is attracted. For example, you can show that you have captured FilenotFoundException, this is not very good? Yes, this is fine, when you only call an API. But when you build a large system, you want to exchange 5 different subsystems, each subsystem throws 4 to 10 exceptions, now you integrate them into one, will have an exponential unusual you have to handle, you It is possible to declare that 40 exceptions you may thrown.
If you want to integrate with another subsystem, 80 exceptions you have to declare, it's just out of control.
In the big side, Checked Exceptions becomes unreasonable, so that people use throws Exception, and I can tell you how many times I saw this situation, they knocked into 'try da da da catch curly curly', said , 'Oh, I will come back to deal with these empty catch ", obviously, they will not do it at all.
This situation, Checked Exceptions clearly greatly reduces the quality of the system.
In addition, even if these problems are not, for me, putting Checked Exceptions such as C # simply means more things. On the other hand, knowing what exception will be thrown out, there are many tools that can be done. I think it is not necessary to define some hard rules to display compilation errors, and more. But we will definitely do some suspicious code analysis tools, including unwaped exceptions, pointing out these potential vulnerabilities.
3. Entrusted, component, and concise
Simplified and concise
Bill Venners: C # and Java, a different place to pass the event to the object, Java use class, often embedded, implement the listener interface; C # is delegated, a bit like a bit like a function pointer, why?
Anders Hejlsberg: I will talk about some topics about the conciseness. No one thinks simple, but understands each other. I like to call "Simple" is "simple". When you face a very complicated thing, you want to make it simple, you usually only wrap the complexity, don't actually construct a real simple system, saying that it is more complicated, because the user wants Know some things you ignore. And simple, for me, is an important thing, with the development of the project, the more clear it, and it will not become more complicated.
Entrusted and interface
Anders Hejlsberg: Entrusted a kind of expression ability that has nothing to interface, that is, I think it is important; the leading language has recognized its importance.
It has many called: function pointers, member function pointers. In Lisp, it is closed and is the true meaning of functional programming. It is very useful.
Bill Venners: Which aspect?
Anders Hejlsberg: You can do what you can do with the interface, but you have to do some cumbersome things. Look at how to handle events in Java, and compare it in .NET.
Because there is no entrustment in Java, you can only use the interface.
You can define an interface to represent all events, interfaces may define one, two, three, four more methods. This has a problem, how to organize them very vague, for those events, how many interfaces you define, is an event, or all events are shared. There is no clear criterion, and even both.
In order to deal with the event of the component, you must implement an event interface, if you want to handle the same events issued by two different components, you have to implement the interface interface, which is not allowed, in fact you need an agent.
Troubled things start.
Inner classes can help a bit with that housekeeping, but nonetheless, part of the problem with using interfaces is that the receiver of the event has to know that he is receiving the event. He has to explicitly implement the listener interface. With a delegate, .
Embedded categories have a little more help to this trouble, even if there is a problem is that the recipient of the event must know that it is receiving this event, it must explicitly implement the listening interface. With this comparison, delegate, as long as the function signature is compatible, you can put them in an event slot, people who handle events don't care how to call, it is just a way.
Bruce Eckel: a bit like type weaken
Anders Hejlsberg: Yes, it is indeed
Bruce Eckel: It is also more flexible.
Anders Hejlsberg: Yes. It is completely based on whether there is a compatible signature, such as a list of parameters. If so, you can bundle them together. It also fully meets the expectations of the end user's callback function, isn't it? Give me some parameters, then I will write some code. Very like a method, but I give you a reference to the method, this is the so-called delegate. Bruce Eckel: There is also no loss type check, the type checks when running?
Anders Hejlsberg: No, or is compiled. When you construct a commission, just like a C programmer calls a member function pointer. Entrusting a method of reference to an actual object. If that method is virtual, you can actually know which one will call (vTBL). So in a sense, you can decide the virtual method when you entrust constructs, and you are an indirect call instruction by commissioning.
Bruce Eckel: There is no other indirectness.
Anders Hejlsberg: Yes, you only need to go directly to the actual method for the delegate to call this delegate once a time for the CTBL. So not only delegate more efficient than the interface, even more efficient than a regular method.
Bruce Eckel: C # There is also a multi-way delegate, a commission can call multiple functions, is this a orthogonal feature?
Anders Hejlsberg: Multi-way delegate is a fully orthogonal feature. To be honest, I am not a very meaningful thing for multiple delegates. I think it has its use, some people find multi-way entrustment is very important, but also use it very well. But I also think that in many cases, the entrusted is a single way. In fact, you don't have to pay the overhead of multiple calls unless you use it.
Bill Venners: How is the delegation that meets the simple and concise statements of you before, where is it simple, where is it simple?
Anders Hejlsberg: If you use the interface to imitate the delegate, there will be a lot of trivial things such as proxy. In fact, see those tools that integrate javabean, produce a bunch of agents, then say, "Don't move the code, we hide these small help classes", which is simple to me. The system is not really easy, it is actually complicated, but you didn't look carefully.
Components are the first class
Bill Venners:
Published in an interview on O'Reilly Network, about why support properties and events, you said, "Developers are building software components, rather than building a single application or a single library. Everyone is Build components from the host environment. These components overload some methods and properties, capture some events, then hide these components. This concept is critical as the first class. "
I want to better understand what you mean, because I will think I am writing some classes, not a component, are you talking about those who use Delphi, VB, JavaBean used to interconnect? Is this what you understand?
Anders Hejlsberg: For components, the main thing is that you can use it; it sounds very good, but I usually not understand this. The simplest form is that the component is a class plus something else. Components are a self-contained software unit, not just code and data.
It is an attribute, method, and event revealing your own class. It is a class with additional properties such as metadata and name mode. These attributes provide dynamic information about how to use components in a host environment, how to last itself - all of these attached things related to metadata. Metadata allows the IDE smart sense component to display its documentation. Components are packaged together.
Bill Venners: When I use Java, I feel that I am in designing class libraries instead of a component library. Perhaps because GET and SET are too troublesome. I really use GET and SET, I really make an event, but I didn't think they used them to build beans. I think they are used by people who write code. So I still want to know how many people are actually writing JavaBean components, if this is a trend. Because it is not much in my experience. Anders Hejlsberg: Contemporary mainstream object-oriented languages are mixed. There are many structured programming ideas inside. Many of the objects are just some methods and a THIS pointer. Conceptually understand that when you imagine an object or component, they have attributes and events.
Taking these things with the first type of element will make things simple.
People argue that C # on attributes and events only make the syntax slide. But isn't it all the syntax slides? Is the object, let's play vtbls, that can also do it with C macro, you can also write object-oriented programs, just a bit complicated, the same, you can write components with C or Java, but because some core concepts are These languages are not the first one, you can only bend.
Or that sentence, attribute is not a real property, they make getBla and setbla, but in the properties viewer is Black, you only know this correspondence. It is clear that the components are trend. Because the concept of components is not the first, we use the components like classes in many languages. This should not be, they should change.
We have already discussed the PME programming model - attribute, method, incident for a long time, everyday we also use it, why not upgrade it to the first?
Version, virtual, and overload
Non-virtual is default
Bill Venners: In Java, the instance method is virtual by default, and can be overloaded by subclass, unless explicitly declared Final. In C #, the example method is the default non-virtual. Programmers should explicitly declare it for virtual. Why is C # default non-virtual?
Anders Hejlsberg: There are several reasons. One is performance. We noticed that when people write Java code, forget that the identity method is Final, it is virtual, so they have performance losses. A virtual method is a performance burden. This is a problem, more important issues are the version.
Regarding the virtual method, there are two school theories. The college party thinks "Everything should be virtual, because I want to overload it in the future", those practical people from the real world, "We really should be careful about virtualization"
When we make some things on a platform virtualization, we have made a terrible commitment to its future evolution. For non-virtual methods, when we promise to call it, X and Y will happen. And for the virtual method, not only this, we must promise, when you overload it, we will call it in a sequence of another method, and the status is unfained.
You make an API virtualization, in fact, you are building a callback hook. As designers of OS or frame API, you really need to care about these things. You don't want users to overload and hook this API anywhere because you can't make your commitment. People may not fully understand their commitment as they make some things virtualization
Introduction and lead
Bill Venners:
It sounds that you don't don't have your commitment to them correctly; how do you worry about how to make a proper commitment?
Anders Hejlsberg:
I am concerned about my two. In fact, there are two aspects of virtualization: introduction and lead. People usually only intend to introduce contracts, and ignore the leadership of the lead.
Bill Venners: What does it mean to introduce and introduce a contract?
Anders Hejlsberg: The introduced contract is what you have to do when you call a method. It indicates that when I call a method, I have to meet some requirements and methods to return. The contract is that when you overload a method, you have to do something; most of the APIs do not have a good document that provides the overloaded document, what is the invariant of the calling method? Those who are called are really true, and those methods you can't call. I think that each method must be introduced and introduced by default. It is very dangerous. I believe that everyone can write to how to overload documents and overloaded invariance is also very dangerous. I can give a real version question: We do see it from Java. Whenever we release a new version of a class library, it happens. As long as we introduce a new method in the base class, if there is a name in the derived class, it is overloaded, especially if there are different return types, the program cannot be compiled. The problem is that Java, C does not really understand the virtual actual meaning.
Virtual
Anders Hejlsberg:
When you declare that Virtual, there are two possibilities. If you don't override a method of identifying the same signature, it is a new virtual method. Or overload a method of inheritance.
From the version viewpoint, the programmer indicates that they make a virtual actual intent of a way. In C #, you must explicitly indicate your intentions. Define a new virtual method, you use virtual, if you overload an existing virtual method, you have to use Override
Therefore, C # does not have such a version problem. I have previously described an example of a method that has been derived in the base class. In the derived class, you have defined foo as virtual. Now we introduce a new virtual function foo, then we have two virtual foo (rather than being overloaded), there are two VTBL slots. Foo derived foo hides the foundation of Foo, this is no problem, and the foundation of the base class does not exist when the class definition foo is. Therefore, it is covered (just like a normal function), there is no problem, everything is safe.
Bruce Eckel:
You see this version of this version often happened so often, so do you decide to solve it?, I remember that you did something similar in delphi.
Anders Hejlsberg:
Yes it is.
Bruce eckel :.
You have a bit different from the attitude of the language and others I have talked, you are very practical.
Anders Hejlsberg: I am a pragmatic, very interesting, version control is already an important pillar of language design, just like C # is done in the overloaded virtual method. Also, important resolutions to C # are different from other languages, because of the version control, when we develop a new feature, we always have to repeat the version control. We will ask, "How do you change this, how to look at this question with version control?" This is an important transformation for most language design. They usually rarely take advantage of them.
Bruce Eckel: Do you care about version control mainly because of the death DLL problem?
Anders Hejlsberg: It is a bit, mainly due to my observation in these years. 10 to 15 years ago, returning to the age of 640K, you can only drop the code rewrite. Overrive spent a year, it consistent with the next issuance. So you don't have to worry about the reuse of the old code. Version control, what is we started every time?
That has passed. We can't catch up with the speed of Moore. The method we get more features is to balance the existing infrastructure and applications. The life cycle of the system is long, and the version control has become important.
3.Contracts and interoperability
Contract and cooperation
DLL's Hell and Contract Theory
Bill Venners: What is the problem of "DLL Hell" to interface to the interface? If everyone understands and insists on the contract in the DLL, and does not update the DLL does not destroy any code? Anders Hejlsberg: There is a lot of pain in hell. One aspect is that you didn't adhere to the semantic contract you promised. You have made some different things you have previously made, so I destroy the code. But this is not the biggest problem. The real problem is not allowing you to have multiple different versions of the DLL. You upgrade one will upgrade all. This is a big problem.
Bill Venners: But is it if all users use the latest DLL if all users use the contract?
Anders Hejlsberg: Theory, yes. But any change potential is a change in damage. Even a mistake correction can also destroy the code if someone relies on this error. Strictly said, once you release, you can't do anything.
Version control is to relax these restrictions in the correct way, bringing room for cyclone. Absolutely, in order not to destroy any code, don't change anything. Therefore, supporting multiple versions is important in parallel execution in a domain or process. So we choose parallel to perform in parallel to perform in .NET instead of the old DLL model.
Strong names in .net
Strong naming in .NET.
Bill Venners: I think you are using a strong name to identify the version of the library you want. How is a strong naming work?
Anders Hejlsberg: Strong naming two parts of logical and physics. The logical part consists of the namespace and class name. In fact, from the public language runtime library (CLR), the namespace does not exist. We can implement the namespace in the programming language, but in the CLR, the class name can be included "." This is the logical name of the class. The physical name is included in the name, version number, area of the assembly containing the code, and a named encryption key. You can reference a specific type through a particular program set with a specific version number or a hinge word button. You can get to ensure that you can just get the implementation you want. Or, you can relax the restrictions of strong names, you can say "I only have this version"
Force semantic contract
Bruce Eckel: Do you have any ideas for forced semantics?
Anders Hejlsberg:
I think the most promising thoughts already exist. The latest developments are as before and after, asserted, invariant, and so on. Microsoft Research Institute has several undergoing projects. We are constantly assessing. We have seen a few very beautiful specific proposals. Finally, we realize that - like all other important features - you cannot implement a mandatory contract from the pure language level. You have to put it in the infrastructure, CLR, and public language standards, so all other languages benefit. If the unregistered implementation is only optional, what is the meaning of the invariant? So put it in the type system level than placed in the program language level; but doesn't mean that we didn't pay attention to it. The next version we won't do, but it will definitely be the first class of C #.
interoperability
Bill Venners:
You have said that Java is to fight for the independence of the platform, and .NET is fighting for interaction. What does the interoperability mean?
Anders Hejlsberg:
The interoperability means a few things. First, it means that the interoperability of different languages in .NET. Our design goal is that .NET CLR will be independent of language, you can support multiple languages. Java, just a programming language. CLR supports only a few languages, such as pointers, C # in the c , but VB and JScript are not available. However, the basis of the pointer is supported by CLR.
The interoperability of the language is based on such awareness: we will not try to convince people to use a language. In fact, the birth of new languages will promote the advancement of the industry and the innovation of ideological, we will not block it opposite to we encourage it. Another aspect of interoperability is the interoperability of existing systems. When talking to Java, we recognize the interoperability so key, so it is considered that Java VM is in an urgentity and the interoperability of existing code. Therefore, in the CLR, we are extremely concerned about all the interoperability of the code written before .NET. This is the key to the top now. We want to find a way to balance the existing code for programmers. To achieve this goal means great interoperability because balance is so difficult. This is the opposite of "100% pure Java" claimed by Java. I think we do correct.
You compare the DLL in C # and call the DLL in Java, it is easy to understand what I mean. JNI is too complicated, and I think it is very shameful to let it do so, don't do more. What is the significance to enter or even more complicated Dark World with C or C or C , what is more complicated with C or C ? You have to run some tools to separate some header files, you have to remember calling this and that. If you have to release an object, you have to lock, when the GC is just awake, you can't copy it. Only do something unreasonable.
Bill Venners: I look at Microsoft and Sun as I apologically, I noticed that different cultures or philosophies affect .Net and Java design. From Microsoft I saw the mainstream point of view is that software is used for hardware - Computers, equipment, etc., I think it is also a whole reasonable view of how Microsoft makes money. As a contrast, although the "network is computer" is Sun's market slogan, I found that there is no such attitude in Sun's culture. Network provides services, rather than computers, Java is like object-oriented layers on top of the network protocol stack, and the target is abstracting a heterogeneous network connection.
Anders Hejlsberg: Interestingly the Java solution in the real world has some platform specific things inside. I didn't see a pure Java, or more or less dependent some other components. Any web is related to Apache or other web servers, databases, and other forms of interoperability with these systems. It is very ridiculous. In fact, the world is to integrate all the systems and make them work, that is, why there is a wonderful thing such as Web Services. Because it provides a good interoperability solution. Our interoperability comes from a lot of aspects. What we have to do is to make our system interoperability more easier.
Bill Venners: What you just described is what I did in Artima.com, I used Tomcat to run JSP, Tomcat and Apache communication.
Anders Hejlsberg: Maybe there is a background database
Bill Venners: Yes, Java application connects to the database, there are some platforms that are implemented with JNI. But in my application is Java, even Tomcat to Apache and database connectors are pure Java, because they use socket, not JNI
Bruce Eckel: One of the reasons for Python is that it claims that if you don't want the platform, if you want to communicate with the platform, you can also.
Anders Hejlsberg: Yes.
4.inappropriate abstractions
Inappropriate abstraction
Loosely-Coupled Distributed Systems
Loose distributed system
Bill Venners: In O'Reilly's interview, you said, "When we first consider the design of the .NET framework, we review what happened in the Web, found that it became a loose connection, Very distributed world. We tried to find out how it would affect our programming model. So our design begins to assume a distributed program is built in a loose connection, stateless form, bringing you very high adjustability, you As long as it is easy to deploy a bit more. Once this is made, everything has changed, "What changes? Anders Hejlsberg:
5 or 10 years ago, mainstream thinking about how to build a distributed system is CORBA, IIOP, object request agency. At that time, the point of view was to make the world becomes an objective, actually, build a bunch of infrastructure to block the distribution of objects. The ultimate ideal is that you only need to write object obj = createmeanObject () and then call Obj.Thismethod (), Obje. Thatmethod (), even if you don't know that object is in Thailand, next door, or in the same process.
The problem with this programming model is: It is very good in a single process, and the process is also good, it is OK in a small LAN, but there is a problem with the expansion.
If you hide the message through the Internet, and don't know when you cross, you die in a cumbersome handshake communication. All accidents, transmission speed is a problem. You can't intervene in a deployment of the object of the object of New York, you can't obj.letimegetx (), obj.letmeget (), obj.letmegetz (), you should say obj.letimegetxyandz (), then all things return; but you Don't do this, unless you really make people understand that they are building a distributed system. In other words, you should not try to pack remote objects with local objects because they are different. Web Services distinguishes them.
Also, Web Services runs in a base frame that already knows how to measure, Web Services is running on HTTP, which is the communication of machines to machines to machines every day. We are very clear to know how to measure it. Why don't you use it to balance? This is what Web Services is done. On the contrary, we have difficulty measuring the CORBA system, which has not accumulated it for it, I haven't heard of some people actually have successfully done this.
The Stateless Fashion
Bill Venners: You said, "Distributed application is built in a loose connection, there is no state." What does you mean by the stateless? "
Anders Hejlsberg: If you program your remote object, whenever you instantiate a new object, you will ultimately keep an agent of an object that instantiates an object that is instantiated in the memory of the same computer or the distribution system, as long as you keep this References, remote objects are also maintained. You will enter a long-term activity, this situation is problematic because such distribution systems are difficult. Once you withdraw the host, if there is also a call, you have to go back.
HTTP is different. You are forced to rely on the state of http, the system does not hold the channel, and the system you designed is forced to route each request to the corresponding CPU and then return the result. The next time you can do something else.
Bill Venners:
The server is not necessary because the status is saved.
Anders Hejlsberg: There is no state so that the distribution mechanism does not have to be operated.
Bill Venners: I don't understand what is different, both are stateful, what is the advantage of not status in the distribution system?
Anders Hejlsberg: Interest. In a sense, the web service helps you instantiate the object, keep it, call it. Web service is just an entry point, the status is you passed, and then the results state will be given to you, then there is no memory. It doesn't have a long-lasting object, it doesn't have a dialog, Bill Venners:
In this agreement, there is no dialog
Anders Hejlsberg:
Yes it is
Bill Venners:
But usually servers will generate a conversation
Anders Hejlsberg: Of course, but how to design a dialogue, we didn't tell you that you must be like achieving such a dialogue: a new object of the client instance, just keep it, the server must maintain its status. You'd better know how to make them work.
Object-translational mapings
Object Relationship Mapping
How is the Bruce Eckel: .NET framework supports the object lasting?
Anders Hejlsberg: There is no suitable method for any person's object. Sometimes, you have to send objects to other threads through the wire so you just serialize it without the need for a relationship. For which long storage, you might have to better consider the version. Read the object written in 2.0 at 2.0, this situation you have to write some representation of the conversion to resolve the version. Sometimes you need to store objects in the database to query it, this situation, you really need an object relationship map. We have an implementation in .NET, and continuous evolution.
Bruce Eckel: What is the main problem with object relationship mapping?
Anders Hejlsberg:
The problem of object relationship mapping life and death is whether the cache mechanism is flexible enough. Unfortunately, most are not. In .NET, we are very trying to make the caching mechanism fully controlled yourself, or more. In many cases, you make a query, then get the result returned by the object, but you don't want the frame to cache it so that you can get the same object again. Many systems can only do this. The result is a terrible performance burden, and you don't need this at all. In the middle layer, for example, you don't care because you just serve some HTTP requests that will soon end, why is it to cache?
Bruce Eckel: So the cache should be requested, not by default
Anders Hejlsberg: Yes, most of the object relationship mapping has a problem of cache and reference. If you ask a customer object, the next time you request to return the same object that has been saved. This requires a large hash table containing all you have already seen.
Bill Venners:
Why do I want to mind if it is the same object?
Anders Hejlsberg:
If you get the Custom's Custid is 100. In an object-oriented program, get that Customer in the query, if you ask, what do you want to get?
Bill Venners:
A object that is the same as the semantics I have obtained.
Anders Hejlsberg: Do you want to get the same object reference?
Bill Venners:
As long as the semantics are the same, I don't care about this.
Anders Hejlsberg: Really? Because this is deeply different from your program. You think Customer as an object, just one, or, just a copy of the database? Most object relationship mappings think that Customer is an object of a CustId 100. If you get a Customer, set some properties; if you only change this copy, not that, if two people update the object at the same time Who will update first? Bruce Eckel: It is best to maintain transparency for these confuses.
Anders Hejlsberg: Let me think of the early we are discussing about CORBA, trying to hide the distribution of an application. This is the same. You have to hide the data is the fact in the database. You can do but have a price.
Bruce Eckel: CORBA is an attempt to hide the network. JINI, they said, "No, the network is existing, we must know it at a medium level, unless the things become very complicated", the design is to make confirmation: This is the boundary we have to mind.
I think this problem is that it is in an object-related map, meaningful is that it is the right abstraction.
Eric Gunnerson:
The problem is: Do you really need abstraction? Usually you don't need it. In the implementation of current .NET remote call, there are some similar transparency, many people say, "Yes, I know that I am calling remotely, I know that the object is there, don't let it make it like local"
Bruce Eckel:
Sometimes you will find that if you try to do it like a local - remote transparent abstraction, suddenly become unreasonable. However, if you realize that 'I call it here, the network may fail, I must know ", this will be clear. For the object-type database, it seems to have a similar situation. I must have to accept the same Customer object. Many representations maybe I have to notify the object I have completed it, there may be a transaction.
Anders Hejlsberg: This is better, because when the user is in depth, as the designer, you have to give your user more comprehensive ability.
Bruce Eckel: So you have to abstract at the correct level, instead of bringing so many questions from the wrong abstraction.
Eric Gunnerson: The trouble abstract caused by it is to have no other way out. The designer of the class is difficult to make a reasonable speculation for the use of scenarios, not to mention the relevant usage frequency. You may think that users need transparency because they can make some cool things, so you have achieved transparency. But if 99% of users become no longer used, guess what happens, these people pay for these things that are not available.
Dan Fernandez: Another problem is that many developers want to use the same way to everything. People will say, "Well, there is an object relationship map, all things will be used in our program", which is useful, but other things like stock trading systems, you don't want to have one Fixed persistence layer. But you use it because it is a solution to the problem. Object Relationship Management may be a correct solution, but sometimes people are in general, think that it is correct, which is really harmful.
Bruce Eckel:
But you know why, is it? The reason is that now I just learn a lasting model, you can use it everywhere.
Dan fernandez: right.
Bruce Eckel: Possible answer is to build some interfaces, depending on how to use it, so I just learn an interface, then according to the call method you or by the system.
Eric Gunnerson: Of course, the interface is also an abstraction. 5.Generics in C #, Java, And C
Templates in C #, Java, and C
Generics in General
General template
Bruce Eckel: Can you briefly introduce the template?
Anders Hejlsberg :..
The template is essentially the ability to add parameters to the type. Also referred to as parameterization types or parameter polymorphism. The classic example is the List collection class .List is a very convenient increase array. It has a sorting method, you can search, and so on. If there is no parameterization type, you will hesitate to use the array or use List. If you use an array, you get a strong type because you can define an array of Customer, but you lose your growth and some available methods. If you use List, you get all these convenience, but you have lost a strong type. You can't say what List is List, List is the List of Object. The type is checked at runtime, and it is also not checked at compile time through the interface.
The compiler will allow a string from a List with Customer. You can only find it when you run an error. Also, if you put your simple type in List, you have to pack it. Because these troubles, you will have concerns, you usually make it difficult to determine which one is selected. The advantage of template is that you can really put things you want to install. Because you can define List
Generics in C #
Template in C #
How does the template in Bill Venners: C # work?
Anders Hejlsberg:
There is no template's C #, you can only define class list {....}, And template, you can define class list
In CLR, when you compile List
Bruce Eckel:
So it is instantiated at runtime
Anders Hejlsberg: It is in the runtime instance. It generates code when you need this type, literally, you define a list
Bruce Eckel:
Is the garbage collector collected there?
Anders Hejlsberg: Maybe it may be not, but this is an orthogonal issue. Classs are constructed in program domain, existed in the program field. If the program domain exits, the class also disappears, like other classes. Bruce Eckel:
If you use List
Anders Hejlsberg:
In that system, it will not instantiate List
Bruce Eckel: You only need to convert.
Anders Hejlsberg: No, actually no, we can share local images, but they have different vTables. I just show that we share the code in meaningful case, but we don't have it when you talk to performance. Typical types, we are very concerned about List
Bill Venners: In the case of reference, you don't actually have different classes, List
Anders Hejlsberg: Yes, as a detail of implementation, they actually share local code.
Comparing c # and java generics
Compare C # and Java templates
Bruce Eckel:
Compare the template of C # and Java?
Anders Hejlsberg: The template implementation of Java is based on a project called Pizza. It is done by Martin Odersky and some other people. Pizza has been named GJ, go to JSR, and finally join the Java language. Its key design goal is to implement templates without changing VM. Of course, this is very meaningful, but it has also brought a series of limitations. It is not obvious, but gradually, you will find "Oh, how so strange"
For example, in the Java template, you can't get any efficiency I have just mentioned, because when you compile a template class with Java, the compiler is just removed by the type parameters and replaces it with Object. So the final compilation result is the same as you originally used Object. Of course, if you use List
I think it may be a bigger problem, because Java's template implementation is just removed type parameters, when running, you cannot get and comply with compilation. When you reflect on the template of the List, you can't know what List is List, just knowing is a list. Because of the loss type information, any dynamic code is generated and the reflection is not working. For me, the more detail the type information. And in our implementation, all information is available. You can get the System.Type of List
Bruce Eckel:
Compare a template for C # and C ?
Anders Hejlsberg:
The best understanding of the difference between C # and C templates is: C # templates are very like class, except for a type of parameters. C template image macro, except like the same class. The biggest difference is when to check and instantiate. First, C # is instantiated at runtime, C is compiled or linked. In any case, C is instantiated before the program runs. This is the first difference. The second C # is stronger when compiling the template type. For unrestricted list
Conversely C . You can do anything about the variable of the parameter type. But when you instantiate it, you may not use it, there will be some hidden error messages. For example, there is a parameter type T, and the variables x, y, you add both. Then you have to define Operator , otherwise some hidden error messages will be obtained. Therefore, in a sense, the C template is actually unmatched or is loose type. And C # is a strong type.
Constraints in c # generics
Bruce Eckel:
How is the constraint of the C # template?
In the template of Anders Hejlsberg: C #, we can add constraints for type parameters. For example, List
Bruce Eckel:
In C , the constraint is impossible.
Anders Hejlsberg: Yes, we can certainly do the same thing in C #. If Dictionary
With constraints, you can upgrade dynamic check to compile or load it. When you say k must achieve some of the iComparable. For any K's value, you can directly call the interface method, because the syntax guarantees that it has implemented the interface, when you build a type of instance, the compiler will check if the IComparable, otherwise generate compilation errors, or if it is Reflection is abnormal. Bruce Eckel:
You said compilers and runtime
Anders Hejlsberg: The compiler performs a static check, but you can also check by reflection at runtime. As I said earlier, what I can do when I compile, can also be done by reflection at runtime.
Bruce Eckel: I can define a template function with unknown type parameters? C # can add a strong type check against the container, but can this type weaken as C ? For example, can I write a function added to A and B A? I actually as long as there is an operator Operator that can add to A and B without the actual type, because this is a type of weakening.
Anders Hejlsberg:
You really ask: How can you use constraints? Constraints, like other features, if you push to extremes, it will become extremely complicated. When you think that the constraint is a mode matching mechanism, you will say, 'This type of parameter has a constructor with two parameters, which implements Operator , has a static method, two instance methods, etc. ", the problem is Do you want this mode to match what extent?
From nothing to do full mode matching is continuous, we think why don't do too little, but it is too complicated, so we make a fortune. We allow you to specify constraints for separate classes, one or more interfaces, and a so-called constructor constraint. You can say that 'type must implement ifoo and ibar' or 'type must be inherited from X'; for this, we will check when compiling and runtime. The approach of the constraint is directly available for the type. The C # operator is a static member, so it cannot be a member of the interface, so the interface constraint cannot be applied to the Operator . The only way is to indicate that the necessary Number is inherited from an Operator . But you can't say it directly, "Be sure to have an Operator ." So in the end, we still resolved this problem.
Bill Venners:
The constraint is the type instead of signature.
Anders Hejlsberg:
Yes it is
Bill Venners:
So the type must or inherit a type or implement the interface.
Anders Hejlsberg: Yes, we can do more, but it becomes complicated. Increased complexity has no income. If there is a constraint system can't do it directly, you can do it in plant mode. For example, you can define a Matrix
Bruce Eckel: Calculator is also a parameter type
Anders Hejlsberg:
Yes, this is a factory model, there are many ways to achieve these things. Maybe not what you think is best, but it is quite simple.
Bruce Eckel:
I start to realize that the Template for C is a type of weakened mechanism. If you add constraints on this, you will change from weak types of stronger types. Strong types often bring more complexity. This is really a double-sided blade. Anders Hejlsberg: You realize that the type is a turn, the higher it, the more painful of programmers, but the program becomes safer, and it is also true.
6.Clr Design Choices
CLR design
Interpreting and Adaptive Optimizations
Interpretation and adaptive optimization
Bill Venners:
A different point of Java bytecode and IL (intermediate language) is a type information in the Java bytecode instruction, and IL is not. For example, Java has several addition instructions: IADD, LADD, FADD, DADD adds INT, long, float, double, respectively; and IL's add directly adds two numbers, add.ovf plus two numbers, and spill has symbols Abnormal, add.ovf.un plus two numbers, and unsigned abnormalities. All of these instructions pop up two numbers from the stack, add, then return the result. Java uses different instructions based on the types in the stack. As a contrast, the CLR's ADD instruction seems to be a polymorphic: it adds two numbers on the stack, regardless of their type, although there are different abnormalities for the unsigned. Basically run the IL engine to track the type of the value on the stack, so that you know how to do it when you encounter add. I heard that Microsoft decides that IL will always be compiled, not explained. How to embed type information help group interpreter in the instructions more efficiently?
Anders Hejlsberg: If the interpreter does not need to track the stack, it will be able to execute the instruction directly. For example, IADD, the interpreter does not need to calculate what is to be added, it knows an integer. If the stack has passed verification, it is safe to save some time, and these interpreters are critical. And our situation, we have not planned to let CLR explain. We intend to compile JIT, and JIT is to track these types of information, because we already have these types of information, so we don't have to join type information in the instruction.
