 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
Well, that was a broad question. I work for Magenic Technologies, which is a consulting company, and we focus entirely on software development and business intelligence with Microsoft products. I am a technology evangelist for them, which what that primarily means is that I do all the speaking at conferences, writing books and articles and do some high level architectural consulting for our costumers, technical sales support and that sort of thing. About a year ago I came out with the "VB.NET Business Objects" book. This is a pretty big change, going from the whole COM world into the .NET world is non-trivial, and about a month from now I will be coming out with a C# version of that same book. I got a maybe interesting perspective in that I think that it is important that there are multiple languages. I think one of the scariest things, for instance, about the rise of Java, originally, was the prospect that there would literally would be one language in the entire world, and certainly there are a lot of people who thought that would be a good idea. Then, likewise, there are a fair number of people now, who think, C# should be it. I've worked in Pascal, and FORTRAN and various flavors of Basic, and dabbled in C++, and the reality is that there is a role for different languages. I think that is important to keep that in mind. No, I don't think the entire world should do VB. I think that business developers, in many cases, can be more productive using VB than they can using languages that really have their roots in the creation of operating systems. Java and C#, I look at those and they have not shaken those roots, that inheritance, that, hey we want to be able to get at the metal if we need to. They have gotten better, certainly, over the years and now having written this C# edition of the book I have got a pretty decent familiarity with C#. It is not like you can do more in C# than VB, or more in VB than you can in C#, but you approach them differently. Their focus is different. VB is all about making business developers write less code to do what they are doing around the business space. It might be awkward to do some advanced things, possible but awkward. Likewise, in the C# space, some advanced things, some complicated low level things become pretty easy, as easy as advanced things get, but often you write more C# code to do things in the UI or even to create business objects. I think it is inherent in the culture. I think it comes because the primary users of VB were, and always have been, from its inception, business users; people that wanted or needed to program Windows. You got to remember, this all started in the early 90s when programming in Windows was a multi-page exercise to write "Hello world". There were a lot of us coming from various backgrounds, be it the DOS people that came from Clipper and FoxPro, or people like me that came from VAX, DEC or AS400 background, wherever people were coming from, they were used to getting work done and writing many, many, pages of code, that's pure plumbing, it made no sense to me. I would have never switched to Windows without VB. So I think that is where it really comes from, it drew to Windows, the business developer. I think it might, but I am not sure it is a good thing. I should rephrase that. I am reasonably certain that is what is going to happen. Already, if you look what is going on, most .NET developers speak both languages to one degree or another. There are a lot of C# developers that were VB developers that switched to C# for whatever reasons. Presumably they were good but some of them just were tired of being trodden on because they were the low VB developer, they want some respect and semicolons are the way to get that. The interesting thing is that most of those people are still writing VB code, they are just doing it in C#. Because it is a cultural thing. This is not a language thing. I really don't think so. We are trying to solve business problems. Do we need really fancy, elegant algorithms or beautiful object models? Not always. In many cases, we have got a deadline on Friday and whatever it takes to get there, that's what we are gonna do so that we can get our work done and make the business productive. I think that the risk that we run at this point in time is that--again, I really do think there is value in having multiple languages that are focused on different things--and if too many VB developers, and I do not say that from a language, but just the culture perspective, too many business developers shift into C#, Microsoft has to make these languages, and the surrounding environment; the libraries, the tools and everything else, service the needs of the constituency. If the largest constituency for C# is business developers, then what happens when we need to write low-level stuff? C# will no longer be able to have those as its priority features. We get interesting things today, anonymous delegates. Essentially useless to any business developer in the world. I am not entirely sure what it is useful for, but I am sure it is useful for somebody, some fancy algorithm somewhere needed that, probably buried deep in the base class libraries of the CLR and .NET. It is my guess right. Somebody deep down needed it. That's great. But say two or five years from now, all of the business developers in the world have shifted to C#, that would never be a priority. It couldn't be. We have got to be focusing on making business developers more productive and I think it could ultimately drive the really the low level, hardcore developer types that were C, C++, Java, C#. They are going to have to go find a new language, and I don't think that is good. This is my point. I think that is a bad thing and I don't think that anybody probably wants that outcome. It is probably better in the long run if there is a language geared toward business productivity and another language that is geared toward lower-level, algorithmic, type work so that these two constituencies can actually shape the language and tools the way they need to. That's exactly what I am saying. Certainly, edit and continue, and actually having a working immediate window, which go hand in hand, I think were top of my list and they're being fixed, and that is good, but I think one of the things that is really important in this discussion is to recognize that VB has never been about the language. VB is about the whole experience. It is about the language, it is about the IDE, it is about the runtime library and other helper functions, all of the different objects that have been available to VB developers throughout the years. I think that's what got lost, when we went from VB6 into VB.NET. Well, everybody says, Oh, the languages are so much different. The language is not actually that much different. It got bigger; we got objects, better syntax and a whole bunch of other things that we did not really have, and that's all good, and I think people get that. But what we lost was some of the VB runtime features, some of the IDE features, some of the helpers; things that made us able to write less code and do more work. Those are the things that we need back. You look at .NET 2.0, the next version of VB gets the My namespace. That's totally a step in the right direction. Take a lot of the complexity of the .NET framework, and if I need to get the complexity I still can, which I usually don't. Usually when I am creating a business application I don't need to get at the low-level stuff. I can get at it through a high level interface and if I have to give up some features through that interface, or even a little bit of performance, not a problem. If the features of performance really are an issue, I can always go back to the actual framework. So I think it is that kind of thing. I have also got another answer, and just kind of a different spin on this. I have come to the conclusion, of late, that most of the code--when you look at an application, the number of lines that you write--most of that code has no business value. So what is the business value of opening a connection to a database? Nothing. The value is actually when I am implementing a business rule, when I am implementing some calculation code or validation code, and even authorization code. That is business value, because I am doing something that makes my application perform based on my business requirements. But in VB or C# when you declare a property, you write maybe six or eight lines of code that have no business value. You do all of that, you declare the property, you do your GET, SET, your NGET, your NSET or your brackets, whatever language that you are using, and all of that is a nest, in which you get to put your one or two lines of business code. So for me to write one or two lines of business code, I just wrote eight or ten lines of plumbing. What a waste. And so there are two, if Bill Gates were to come down and say Hey, fix--my argument is that all of this code, when you look at a typical application, the percentage of code that is actual business code, is quite small, and all of the rest of the code should be handled for me. Okay, this is a pretty idealistic view maybe, but it is a goal to shoot for. Are there features that we desperately need from a VB prospective, and I think generally, the answer is no. There are certain specific cases, where today, you end up using P/Invoke, in order to accomplish a lot of things. Windows forms dealing with grids or list boxes and trying to do some things that just aren't exposed through Windows forms, for instances, or the logon user, if you are doing a web application you need to impersonate. Those are just holes that I think Microsoft is aware of and is constantly collecting feedback about where there are holes. Maybe, what you are getting at is something more holistic in nature, and I am not convinced there is something that is more holistic. VB, essentially, is a wrapper on top of Windows to make it accessible, and so is .NET when you really get down to it. Billy Hollis talks about this, and maybe he did in your interview with Billy for TheServerSide too. He talks about the fact that .NET represents the victory of the VB mindset. Ted: He did make a few comments about that. There is a lot of truth to that because when you start to think about it, VB has always been a managed environment and has always had this relatively abstract, somewhat object oriented, interface layer that you use to get at Windows without having to go to all of the complexity. That is what .NET is, that is what the base class library is and so forth. To a large degree, VB guys already have what they need, it's just I think that we lost something in translation, in terms of the tools and some the other productivity features. I have got a computer science degree, a lot of people don't. Especially since it's an in fact its a dying breed to be a computer scientist anymore, and I spent a lot of time programming on the VAX at a fairly low level, and doing a lot of interesting things. Most of my personal interest in Windows, and now in .NET programming, tends to be around frameworks and in the creation of reusable components, and that sort of thing. When you live in that world, whether you call it patterns, or best practices, or just reusable code, or whatever you want to call it, just experience in the end. That is compelling, that is really compelling. In fact, earlier today, here at TechEd, I got into a discussion with some people about the value of frameworks in .NET, and the comment was made that you could do frameworks before, it's not a feature of .NET. But it is a feature of .NET, because if I did a framework in SmallTalk, it could only be used by SmallTalk. If I did a framework in C++, it can only be used by C++ people, and if I do a framework in VB6, it was only useful for VB6 people. But now I can create a framework, I can apply patterns and best practices, pull some things together, and I can create something, and it doesn't matter what language I created it in, we can all use it. We are seeing an explosion of that on the Internet with a lot of different downloadable tools and components and there is an ever increasing amount of stuff, and some of it from Microsoft. I think that this is where this whole guidance around patterns and practices thing comes in. It is really when you tie it back in with the stuff Microsoft is doing, which is all generally good stuff, but they are engineering the heck out of this stuff. If you are a purist, if you are one of these low level guys, it is great, because they are really doing a good job. But if you are more of the business developer, productivity person, and you just want to get some work done, trying to sift through this, is really hard. Even the simpler building blocks that Microsoft has produced, you could spend days, or maybe even weeks, trying to decipher how to use them. I think that is maybe where we can start to fill in as a group. It is to provide that bridge between, hey, all these pure patterns stuff is great, but there is also this large group of people that need to get work done, and how can we marry those two. Well you know, in 1995, 1996, when COM first became truly viable, I caught the bug, totally, that's where the whole Business Objects book started. It was COM, and that was an attempt to do some of this, and it seemed so compelling at the beginning, and then you start to realize that COM, in and of itself, is not object oriented, and that starts to impose all sorts of limitations. Then we start playing with IDL, and we start playing with different kinds of interesting ways to use interfaces in ways they were probably never intended. You start to really run up against all these walls of limitations. Then, I get on a project, probably in 1997, I think it was, with, that was mixed C++-VB, and then you really start to realize how not true some of the promises of COM were, in that it is so easy for a C++ persons to do something to a component then make it totally useless to VB, and conversely, although VB could never do anything that could not be consumed by C++, things that we would do in the VB side, that we thought were trivial, like VB collections, just Holy Cow. Then you go to the C++ side and it's almost impossible, or at least, it's a huge amount of work to interact with them, and so that lack of coordination, and the fact that it did not have object oriented--we wanted that, so we are trying to graft object orientation on through all sorts of interfaces, and then people were doing aggregation, what a mess! So, in the end, what looked so promising turned out to be not anywhere near as good as, at least, I thought it was going to be. I think that .NET, because of the platform itself, really is object oriented. I think it brings a whole different aspect to what is going on. I just learned something really interesting the other day. Actually, here at this show. It turns out, that by default, C# does not create projects that enforce CLS compliance, and that boggles my mind. Basically Microsoft saying, hey, go create bad code, we won't stop you. Unless you are smart and disciplined enough to turn this switch on. The reason I found this out is because there was a C# guy that came up and was asking some questions about some things around unsigned ints, and other things, some calling conventions, the way that you can overload methods in C#. They're illegal, they are not CLS compliant. Ted: Which is different then to say the are illegal. Well, okay, but they are legal in the same way that COBOL .Net, for instance, still supports all of the old COBOL types; packed integers, packed and unpacked arrays, and all sorts of totally, today, off the wall types which are all perfectly valid inside of the COBOL .Net Program. So, my contention actually, is that any body that is not writing CLS compliant code, as a general rule, is writing bad code. So, C# by default creates bad code, by this definition. You can make this argument on the VB side too, because VB, by default, there is an option strict, should it be strict type checking or not. That is turned off by default. Likewise, that should be turned on. So I am just being collectively critical. But things like unsigned integers are not CLS compliant. The use of them in any external interface is a bad thing, and the danger is that the C# guys will just ignore this, won't turn CLS compliance on, and will go out and create a bunch of code that locks them and everybody around them into C#. Certainly, it only matters at the public boundaries, which you do inside of your component, is up to you, but it is my contention, that the default should be safe, and if you choose internally to go do things that are noncompliant, then you should choose to flip that switch. Not the other way around. I think that the thing with SOA, that you got to recognize right up front, is that it is not object oriented. In fact, SOA Service Oriented Architecture concept is intrinsically procedure based, or you could say message based. It depends on how you want to view it at the end of the semantic games. I am passing a message by calling a method, and a method is nothing more than a procedure. In reality, when we start looking at how you are going to design service oriented systems, you are going to do it using flowcharts, because ultimately, it is one procedure doing some work, calling other procedures, and walking through some sort of linear step, but you can already see this in this in BizTalk, for instance. The other designer tools that Microsoft and presumably other vendors are going to come out with are high level flowchart tools that helps orchestrate this stuff. So, yes, the question is where did my objects go? And the objects are still there. The thing is we still have to write the service, and what is the service? Especially when we look at it from a Web service perspective, all it is is an XML interface into an application, just like there is an HTML interface into an application, now we have got an XML interface into an application. Well, how did you build that application? I would recommend that you built it with objects. Sure, you can build it with data sets, or whatever coding style you want, but objects, at least for me, are a natural choice there. So I feel perfectly comfortable treating the service boundary, essentially as an interface, you can't say a user interface, because there is no user, but that is what it is. It is an interface layer, no different than a web page, or a Windows form, and then behind that is where you have got all your business objects, your persistence layers, and whatever else you have got. There is no doubt that mapping must occur. The question then is, is it practical, or even desirable, to have a tool that does all of the mapping for you? In certain cases, the answer might be yes. If I've got a relatively simple database, or at least a well designed one, and it is probably one database that has all of my data, I really might be able to use some sort of an ORM tool to do the mapping for me; construct the metadata and pump the values back and forth. I talk about this at lot at conferences all over the world, and I ask people, how many of you have your data in a relational form? And you get a lot of people raise their hand. And I say, be honest, how many people have a 3GL, or a third normal formula? A lot of hands go down. Then you say, how many people have customer or product data, that is both in Oracle, SQL Server, and AS400, then, of course, lots of hands go up. Well, their data is not relational either is it? Bam! It is no longer relational. So any ORM tool that assumes relational instantly becomes useless to these people. So what I am suggesting is not that these obstacles could not be surmounted, but the complexity of an ORM that can simultaneously and transactionally map from SQL Server, Oracle, AS400 and XML file and some ECP string from a mainframe, you show me that and the configuration tool for it and I will just write code and be done in a fraction of the time that will take you to decipher how to make this ORM tool work. On top of which, most of the ORM tools are being made--at least in the .NET space, I can't speak on the Java side--by a lot of startup companies, ambitious people, smart people, but we went through this in the Window s DNA space too, where there were a lot of startup, ambitious, smart people, created some really cool DNA frameworks that lasted about six months. I had a client who bought totally into this DNA framework, and spent a massive amount of money, and more importantly, they put it at the center of their entire development process, the whole thing, then the company went out of business. No support, no source code, nothing. So here our client, it was devastating, totally devastating for them, and that is the risk you run, because an ORM, this mapping software is the heart of your application. It is not something you just swap out casually. So it is a big deal. Thank you very much. |
