We have Brian and Erik from MSR today to talk about TESLA. Brian, please provide a bit about your background.

B: Ok. My name is Brian Beckman, I am a physicist by training, but I have been at Microsoft for 15 years and have been working on improving the way people write programs for that amount of time. This is almost exactly what Erik has been spending his career doing and we bumped into each other somewhere along the way where he was doing LINQ and I was helping out with a predecessor of PDM and we realized that we had enough in common in our ambitions that we are to found a follow on project to those and we did and it’s called TESLA. And stated simply the ambition of TESLA is to democratize programming in the future and programming in the future means Web programming, it means data intensive programming, it means single applications over multiple data sources, it means all the messy stuff that drives people crazy today and we are going to make it good.

Erik could you give us a little background about yourself?

E: Yes, sure. In my previous live I was known as the "banana man" and so I was doing functional programming and this is when Brian said how we met, I heard that there was another crazy guy in the SQL Server building that was using Haskell to write a formal semantics of the CDM. Then I said: "That’s a person that I need to meet." and, yes, there he was using EMACS and Haskell to write formal specifications and that's the guy that we need to really change the world of programming so that's how we got started.

Where will we see a first iteration of TESLA in Visual Studio?

B: Probably the first thing you are going to see is the XML literal work in VB9. This is just the tip of the iceberg but it typifies the kind of thing that we want to do.

Where would you use TESLA and what are the goals for TESLA?

B: The overall goal, the overall sweeping ambition of TESLA is to make programming the web and multiple distributing resources easy. It’s too hard. Programming in general is too hard. My background as a physicist probably was too hard, way too hard. They hate programming and justifiably so. I’ve spent my career trying to make programming easier for physicists and I stumbled into many of the same kind of things that were behind LINQ, for example, monoids and monads. Physicists work with collections of things all the time. Those are the appropriate generalizations. Eric turned monoids and monads into LINQ so that is one of the touch points that we had in common. But it goes far beyond that, it goes toward distributing programs, toward cutting back on the DLL hell that people have. .NET did some of that, and it didn’t go far enough. There is no end of problems. How do we approach these problems? We need to make it easier to do transactional programming. We need to make the tools much better and support multi language programming. Today you want to put a little square on a web page that collects a name and sends it to a server; you have to write 4 different programming languages at least HTML, JAVASCRIPT, PHP, ASP.NET. This is way too complicated. What do you do you’re taking a string in a textbox and sending it to another machine? Much much too hard. We need to rationalize these things, we need to improve these things. Erik’s background in starting with the mathematics of computing and turning it into elegant programming constructs, my background in taking applications and finding these elegant constructs and turning them into ways to make applications better, it’s the perfect fit. This is why we decided to found the Tesla project.

So do I here you talking about injecting engineering process or scientific method?

B: It's hardly process but it's also from my point of view it's design elegance. That’s my emphasis anyway. One of the ways to make programs easier to write is just to make them smaller. The only way to make them smaller is to make them more elegant. Functional programming goes a long way to doing that. Of course functional programming is and always will be an ISH technology, it's for the extreme geeks only, on the other hand you don't have to scratch link very hard before you find functional programming. There is a monad under there. So what we want to do is take these elegant ideas that are computer science and turn them into something that mort will love and will want to use and we'll make mort's life easier. I characterize myself as the father of all morts. I’m a physicist, I have to write programs, I hate writing programs, I just want to get the programs done, the less code I have to write, the better.

E: So also at a different level, the way we run our projects we also want to kind of be lean. So we are an incubation project and one of the things that we don't want to do is to create waste. What you see often is that there are projects where people create lots of code and then it doesn’t ship so it gets wasted. What we are trying to do is we are trying to really have a short cycle from research of crazy ideas intro products. So we're trying to minimize the amount of waste so we're trying to be really close to the product teams and work with them to do the technology transfer and then once the technology is transferred into the products then we can move on and then we work with the next product team so we are trying to be very close.

E: That's right. TESLA is an experiment in extremely aggressive technology transfer. Usually technology transfer takes between 10-20 years. We want to cut this back down to 5 years or less. So ideas that were on the research docket 5 years ago, we want to put in shipping products now, and the XML Literals is the perfect example. We cracked open the VB compiler and we shoe horned XML Literals in. Not in an undisciplined or stupid way but by learning exactly how that compiler works and having a quality standard that was equal or even better than the VB team itself. So they welcomed the technology and now we are actually going to ship it.

So let’s step back for a second and let’s talk about a little more about what TESLA really is.

E: One of the things currently if you look at what happened over time, if you look at the older days when people were programming like in Access you programmed an application as a one tier application. You had a gooey on top of your database, there was no treat year, there was nothing. Normal people can understand that. Today when you write and application you have to architecture, design, patterns, treat year, you have to think about distribution and so on, but in some sense you force people to do the kind of design in their heads instead of doing it in code. So what we are trying to do is to go back to the old days when you would write your application in an easy way and then refactor or evolve your application into a form that is suitable for distribution and so on. So that’s our goal. You start with a program that people wouldn’t consider to be a professional program, but we are going for the normal program or something that normal programs can understand and then have tool support to refactor your program such that it's kind of now it's a program that satisfies the right architectural constraints, instead of saying forcing people to start thinking about: "Oh, I have to put this on the server, that on the client, etc." So this is when we talk about democratizing web programming, except we want to make it really simple by saying: "I start programming without taking these things into account and then adding these kind of aspects later by refactoring the code.

B: The bottom up view of TESLA is it's a broad variety of artifacts that we will be primarily integrated with the programming language and shipping in various cycles with Orcas and the next generations after that just to give you 3 off the cuff, XML Literals in VB9, the comprehension syntax that gets turned into the LINQ standard query optimizers. We have in mind improvements and extensions of that comprehension syntax. Those are the parts of TESLA. The dynamism features that Erik mentioned before such as lambda expressions and typing inference and so on. What’s the next step of those? We have lots of ideas in mind of where we can take these kinds of things. Some of them will be used directly by mort or me, some of them will be in service to higher level things such as LINQ or the refactoring scenarios that Erik was talking about. All in all when we look at the things where we need to do bottom up we have at least 45 features that we can add to the programming languages over the next few cycles.

So at 45 features where are gathering those features from and how are you prioritizing which to work on first?

B: That is the existential activity of Microsoft. This is constantly what we do. The way Erik and I work together is his top-down vision gets turned into bottom-up feature lists, we work with the developers, we work with our partners and programming languages and libraries and tools and we prioritize these things together and sometimes they come out exactly the way we want and sometimes we compromise and say: "We'll do this other thing first and that thing later." But we are not going away until this vision is realized and there may be 145 features until we’re done or there may be 4, we don't know.

What would be the timeline?

B: 15 years.

What would it look like if I’m a software developer and architect in 15 years?

B: I think Erik has sketched out the way it will work. You will write your application, using horse sense or intuition that you've developed as a program: console.readline(), get two numbers, add them, console.writeline(). Not: do PHP here and zope over there and XML this and JavaScript that just to add a couple of numbers. Are we going to automatically detect parallelism? No, probably not, that's a dead dream. Certainly what we'll do is allow you to be able to take that console.readline() and put it on the client and then console.writeline() and put that on the server somehow.

E: I think what we want is for there to be no need for architects, such that normal people can program. B: He thinks using just the normal intuition and horse sense one can write a program.

So Mort might be the housewife walking around?

E: Exactly. I want my mother-in-law to write programs without any help of people that have studied programming or something.

So it will be like Captain Pickard on Enterprise saying …?

E: Yes. Make it so.

B: But in a real sense my wife does a lot of E-BAY selling. What is she doing? She is actually programming things all the time. She doesn't write a line of code but she puts up her products and she sets up a process and says: "You sent me a paypal payment and I’ll give you 30 days to respond then if you don’t like it I'll refund you your money." She is setting up a business process. It's all verbal. We don't have any AI ambitions, I don’t want to give the wrong impression that we are going to verbal processes into programs but we are going to make it easy for people who do stuff like that to encode their business processes into actual applications.

What are some artifacts that we should expect coming out of TESLA in the near term and what will be the future?

B: In the near term you will see things shipped in Orcas and then shipped in the next versions of the Visual Studio programming languages; you will also see Erik go globetrotting and giving his justifiably famous talks, if you haven't seen one you really should go see one. It's a real treat. Coming out of me you will see demo's. I blog a lot, there you will see crazy programs. My short term ambition is to try to do some more physics programs using TESLA and LINQ ideas. If LINQ is great for transforming business data, why isn't it great for transforming physics data? Of course it is, so demos, talks and shipping product. You will see stuff coming from these features, but really there is a mad scientist cabal of all these features that ties them all together.

Brian, what are you reading lately, and what’s your favorite ice-cream?

B: My favorite ice-cream of any kind is probably coffee flavor ice-cream just because it makes me think I’m almost drinking coffee which is my favorite drink. My favorite technical book of all the time is called: "Vector Calculus, Linear Algebra and Differential Forms" by John Hubert and Barbara Burke Hubert and if you ever find yourself wishing you had learned calculus the right way that is the book to use. I also like "Calculus on Manifolds" by Michael Spivak. It only happens to have the word "calculus" in it by coincidence, there are related topics, but more seriously what I’m reading now is: "The Road to Reality" by Roger Penrose; that's a very interesting book, I'm not sure I believe it all but it's certainly a great book and anybody who cares about computing could benefit from reading the following books: "Structure and Interpretation of Computer Programs" by Abel Salinsasman, "Introduction to Functional Programming" by Burgan Wildler, if you can find it forget the second version, go for the first version; these are magical books that will change the way you think about computing for the better, not for the worse; and finally "Fineman lectures on physics". I just had to throw that in because "Fineman lectures on physics" are to physics what those 2 books are to computing.

Do you have any additions you have to add since the interview?

E: I'm trying to buy all the 1st editions of Burgan Wildler, so please don't go out and buy them because then I can't get them anymore. B: You have to come to Erik to get one.