Interview with Jeffrey Richter at Microsoft SWIT 2014
On March 27-28, the Microsoft SWIT 2014 conference was held in Kiev . Within two days, developers and IT managers could see and hear a large number of speeches from speakers from around the world.
The most important attention, of course, was attracted by the reports of Jeffrey Richter. Jeffrey is a great authority for many developers, an expert in .NET technology and the owner of Wintellect. I had an interview with him, some of the questions in which were asked by Habr’s readers . We talked for almost an hour, who are interested - welcome to Cat.
(If it seems to you that you have already seen this topic somewhere before, then no, then there was one interview, and this is another).
Hello, Jeffrey. We are big fans of your books and presentations, it is a great honor for us to be here now and speak with you.
Thanks.
My name is Vladimir, I write in C ++, and this is my colleague Alexander, a .NET developer. We also have a blog on habrahabr.ru, maybe you have not heard about this community, but it is quite popular with us: about a million IT specialists from Russia, Ukraine and other countries. A week ago, we announced your arrival at the Microsoft SWIT conference and invited people to ask questions. With your permission, I will ask the most popular questions of readers, as well as a few questions from myself.
OK.
Let's imagine that no C # language and .NET platform exist and you, with all your current knowledge and experience, have the task to develop them from scratch. Would you create them exactly as they are now? Perhaps something in them was initially done poorly? Perhaps you would like to add something important?
Of course, in .NET and C # today there are things that both Microsoft and I personally would like to implement differently. 13 years ago, the world was different. We are now focused on mobile development, 13 years ago the focus was on web services. Thus, what would be worth doing is to make .NET more “clean”, minimalistic, so that it does not use as much memory as it is now, is not so “heavy”.
After all, the .NET Micro Framework exists - is it not for this?
There are several ways to look at the .NET platform. First of all, it is a set of standards that any company can adopt and implement, and these implementations will be compatible as long as they adhere to the standards. Microsoft itself supports several .NET implementations:
1. The classic version, which runs all desktop programs, servers with ASP.NET, Silverlight, etc.
2. .NET Compact Framework
3. .NET Micro Framework
The first and most important implementation, of course, was ordinary .NET, but then we thought: “what about phones or watches - devices that do not have much memory and not such powerful processors?” There was no way to get .NET to work well enough for them, which is why “stripped down” versions appeared. If today all this could be written “from scratch”, I think it would be worth highlighting the small core of the entire platform - the CLR-type system and the garbage collector. It should be the basis, but everything else could already be connected to the platform with something like “plugins”. For example, Reflection is a fairly resource-demanding and slow technology, while not many programs really use it actively. We could, for example, leave Reflection in the desktop version of .NET and remove from the Micro and Compact versions. Thus, the same core would work in all versions of the platform, which would give greater flexibility. And already the development teams of a particular platform could add the rest of the functionality, according to the plug-and-play model. Do you need any specific functionality? Ok, take it and add it. But .NET has never been designed this way. It was originally created as a solid, monolithic platform.
But with a monolithic approach, we can write an application - and be sure that it will work everywhere. But what about the “modular” approach you propose?
An application can itself state which “modules” it needs to work. In the end, even today we cannot write one application that would really work on .NET, the .NET Micro Framework, and the .NET Compact Framework. What I propose actually increases the flexibility of the platform.
Do you think this was the right decision by Microsoft - to release and support .NET only under Windows? What do you think of Mono, Xamarin and the future of .NET in general on platforms other than Windows?
This is a good question. This was definitely a political decision by Microsoft. 13 years ago, Bill Gates, Stephen Ballmer and others, who were at the forefront of the company, decided that Microsoft makes a lot of money selling the Windows operating system and it is very important to strengthen and support it by all means. The release of .NET exclusively under Windows was a strong move for this purpose. As of today, Microsoft has definitely realized that Windows has strong competitors (at least Android and iOS) and they are not represented on these platforms. In addition, both Bill Gates and Steve Ballmer have already left the company, and I think that modern Microsoft will be a more open company. Do I believe in Xamarin? Undoubtedly. People can finally write programs (well, at least their business logic) once for all platforms. Yes, each platform will require refinement of the visual part of the application, but this is not so scary. In general, I think Xamarin is very good at pushing the .NET platform forward.
Speaking about different platforms, some people ask: “Why should I write .NET code, getting an application that can only work under Windows, when I can take Qt or Java and create a product that will work everywhere?” What can you answer these people?
Each operating system has its own characteristics. One of the important features of the operating system is its approach to interfaces, user interaction, intuitiveness and ease of use. Windows in its latest versions offers its own vision of these things - for example, a tiled interface that conveniently displays "live" application icons. It is enough for me to open the start screen - and I already see on the tiles my tasks in the calendar, the presence of letters in the mail, messages from my friends. The use of these elements unique to the operating system makes the application user-friendly, and this is what we should strive for. Using .NET and Windows Runtime it is easier to build such interfaces than using universal libraries, so Microsoft makes the developer’s life more enjoyable. In addition, if, for example, the user will open the Windows 8 start screen and notice that the tile of your application has been updated - this may make him want to open the application and check what has changed, and in this place you can offer him a paid service or show an advertisement. And now we can see how support for the features of the Windows platform influenced the monetization of the application.
In terms of supporting the new features of Windows, I really like Windows Runtime. This is the most modern, "clean" and simplest API you can imagine. Writing on it is much easier than, for example, on Objective-C under iOS. You may argue that programming for iOS can bring more profit today, but Microsoft today is doing everything to conquer the mobile market. This is a big battle and it has just begun.
What do you think of the Windows Azure platform (which, incidentally, was recently renamed Microsoft Azure)? What do you think about the future of this platform? Are you planning to write a book about Azure?
Yes, I have already said that I will write a book about Azure. Rather, about Microsoft Azure Storage. When Azure came out, in truth, I didn't really believe in him. I thought that the time had not come yet when companies are ready to place their data and services in other people's data centers. In addition, Microsoft did not have much experience in public cloud products - yes, outlook.com, bing and some other products already existed at that time, but Microsoft did not have large-scale public clouds. But they did it. Since the advent of Azure, its reliability, functionality has seriously increased, prices have fallen - and people believed in this product. We hear all new success stories from companies using Azure. Even my company’s website today runs on Azure, eliminating the need to think about a ton of things we don’t want to think about. My favorite part of Azure is Azure Storage. In each application, the most important is its condition. What data we store, what we show the user. All this needs to be stored somewhere - and this task concerns each developer. And when I write a book - it will be about how Azure Storage allows you to work with data, queues, tables, how to do it efficiently, with minimal cost. This is a large amount of information, not everything can be found in the official documentation and recommendations of Microsoft, I think I can highlight important and interesting details. how Azure Storage allows you to work with data, queues, tables, how to do it efficiently, with minimal cost. This is a large amount of information, not everything can be found in the official documentation and recommendations of Microsoft, I think I can highlight important and interesting details. how Azure Storage allows you to work with data, queues, tables, how to do it efficiently, with minimal cost. This is a large amount of information, not everything can be found in the official documentation and recommendations of Microsoft, I think I can highlight important and interesting details.
Do you think a regular developer needs to understand how Microsoft Azure works internally? Working with local files and services, I can always understand why a particular operation took a long time or failed, I have debugging and profiling tools. When working with Microsoft Azure, if something went wrong or took too long, I can only guess about the reasons.
Well, Microsoft Azure services work over the Internet, and the Internet, in general, does not have standards for guaranteed speed of delivery and data processing. Performance problems may be related to your device, software, router, provider, server, or its software. I don’t think it’s so important to focus on the insides of Microsoft Azure. In the end, even in a locally running .NET application, there is a lot of hidden, implicit behavior, for example, the work of the same garbage collector. Nevertheless, many people use this garbage collector to get application speeds acceptable to them. The operating system itself is also a “black box” - even with a simple file reading operation dozens of functions are called up, the internal kernel code of the OS and drivers work - you don’t know the implementation details of these systems, but, while they work at a speed that suits you, you use them. It’s the same with Microsoft Azure: just try, if you are satisfied with the speed, use it, no, ok, look for something else. This approach seems normal to me. People are building more and more abstraction levels to solve more and more complex problems.
Are you familiar with the Roslyn project, which provides APIs for C # and VB.NET compilers? Do you think this project is just a toy, or a really powerful tool for expanding existing languages, creating important new products? Do you believe in the future of this project?
Yes, I know this project. Its creation took a very long time; it is still not included in the composition of Visual Studio, but it will become more and more significant in the coming years. The project performs several tasks at once. First, he made the C # compiler developers rewrite it to C #. Since the compiler can now be developed faster, the speed of introducing new features of the language will increase. Secondly, now the task of writing a refactoring tool for C # has become much easier. Microsoft expects the emergence of a large number of such products, competition between them and improve their quality. In addition, it became possible to write code translators from one language to another.
Do you think that in the future Roslyn will always support the latest version of compilers, with all the relevant features of the C # language?
Oh sure. When developing Roslyn, all the features of the current version of C # were implemented, then a new version was released - C # 6, the capabilities of which are also now added to Roslyn. In addition, the development of the C # language compiler has moved from native code to the code in C # itself, which will also facilitate easier integration of new features into Roslyn.
As a C ++ programmer, I'm interested in your opinion on C ++ / CLI and C ++ / CX. Do you think that these projects have a future, as separate, integral languages or their fate - to be just a bridge between new Microsoft technologies and old projects with native code?
C ++ / CLI - never had much success. Somehow I was offered to adapt my book on C # to C ++ / CLI. The project did not take place - we did not find anyone who would like and could do it. This language was Microsoft's weird undertaking for ... I don’t even know ... I have never met a single person using C ++ / CLI as their main programming language. As for C ++ / CX, its purpose is to simplify work with COM. COM is a technology created back in the 90s, you yourself know how terrible it is with all this reference counting, interface conversion, and so on. One of the reasons .NET came about was precisely the desire to get rid of this legacy. Components are good, but let the CLR, and not the programmer, deal with the issues of allocating and freeing memory. In Windows Runtime, Microsoft has reverted to native components, C ++ / CX is a way to make working with these components transparent, in the style of working with .NET components. The C ++ language itself remains the same, the Component Extensions extension only saves us from the horrors of working with COM.
There is an interesting situation - Microsoft itself is quite actively using C ++ for native development (the same Windows Runtime in recent versions of Windows is written not in .NET, but in the form of native components), while the company does not encourage third-party developers to use C ++, but promotes .NET and C #. Why?
Despite the large size of Microsoft, its resources are still limited. You cannot cover everything, you cannot support all technologies. For each thing, specific decisions are made: “How many people will use this? What is the development potential? How much money does the company ultimately earn? ” Obviously, Microsoft's top priority right now is on .NET and managed code. Of course, both C ++ / CLI and C ++ / CX will be supported, bugs will be fixed, but less resources will be allocated for the active development of these products.
What do you think about the future of the current stack of Microsoft technologies - .NET, C #, Windows Runtime? Can you tell how they will develop?
I definitely love .NET and C #. And I'm not alone in this. After the release of Windows 8, there was a moment when these technologies seemed ... I will not say abandoned, but somewhat lost their positions. First, remember the story of Silverlight. This crippled faith in the bright future of .NET. In addition, many presentations and examples indicated that Win8 programs would be written primarily in Javascript. .NET programmers felt cheated - would .NET really leave the scene? Fortunately, Microsoft thought better of it in time. Many people who promoted those solutions are no longer at the helm, and most of the applications in the Windows Store are written in C #. In addition, at a recent conference (I don’t remember exactly which one), Microsoft showed off a new version of the C # compiler, capable of directly generating native code, without being tied to the .NET virtual machine. exactly the code that is obtained at the output of the C ++ compiler. Those. Speech about the performance of C # no longer rests on the fact that this is not native code. This compiler will be released in the next 1-2 years. Thus, for me, C # remains the best development technology for the near future.
What do you think about functional languages and in particular about F #? Do you consider it appropriate to use these languages in real projects today?
Functional languages are generally not my profile. I wrote very little on F #, but I know that C # in recent versions got a lot of ideas from F # - lambda functions, extension methods. And these really borrowed features I really use in my work every day. F # definitely does not have the support, popularity, articles, and books like C #. The thought of its application can appear only when the entire wealth of other (non-functional) programming languages is already lacking. But personally, I rarely have to get into such situations, and when I have to, it's hard for me to assess how much this or that functionality will be easier to write and maintain in F #. Programmers, like people of other professions, try to put into practice those tools with which they are already familiar.
I would like to ask a question about your report today. You talked about the process model for applications from the Windows Store. You said that each application is in the sandbox, which isolates it from the influence of other applications and does not allow it to access user data or damage the system.
Yes it is.
At the same time, this sandbox is not as perfect as, for example, the application sandbox in iOS. In the Windows operating system, not only applications from the Windows Store can work, but also ordinary, desktop applications. And they can access application processes from the Windows Store - they can kill them, they can intercept their calls, they can even inject their code into them by stealing user data from them or faking information that is displayed to the user. Do you think such a model is unsafe?
Indeed, application processes from the Windows Store live in the sandbox, but desktop applications do not. This is one of the reasons why Microsoft released a special version of its OS - Windows RT, where regular applications cannot work. To date, there are a number of devices running on this OS and now they really provide an honest, completely isolated sandbox. This is very important - for the first time Microsoft can abandon the burden of support and compatibility with all its previous operating systems. This allows you to make the product truly reliable, safe and modern. What is bad in this product is a marketing error in the names. We have Win RT as an operating system, Win RT as a device on this OS, and there is also Windows Runtime, which is also reduced to Win RT. However, all these are completely different things,
