Page 2 of 3   « previous page   next page »

Carl Franklin: So, Scott, the next question that comes to my mind is, are these features that Microsoft if they were listening, could say, "Hey that's a good feature we will add that in the next ASP.NET", or is it more indicative of the dynamic nature of Ruby that these features become possible?

Scott Hanselman: I think you have absolutely nailed it right there. You have asked both the right questions. Is Microsoft going to move towards this, and definitely I think that this is a computer science thing that's happening, not necessarily a Microsoft thing. Everyone's headed in this direction where we are -- we have had this schizophrenia, right? Thirty years ago, you have your Smalltalk folks that have got this very dynamic world and then C++ and C start getting more static typing. C++ starts making decisions about how inheritance works. C# says "all right, we don't allow multiple inheritance." Things get stronger and stronger typed. So, in the Windows world we are kind of having the screws tightened on us. So, over the last kind of 15-20 years, the screws have been tightened and the developers are dealing with it, right? To mix my metaphors, right? You know how to boil a frog, right?

Carl Franklin: Yeah you put him in cold water and turn up the heat slowly, right?

Scott Hanselman: So, why do you think that people are so excited about JavaScript and AJAX and about PowerShell, because suddenly there's all the power of .NET, and all the freedom of a dynamic language is kind of coming out. So, I think that, yes, part of it is that Ruby is such a dynamic language, but I think if you take a look at C# 3.0 like at shrinkster.com/hei you are going to see that Anders and a few folks that are designing C# are adding this dynamicism ?

Carl Franklin: Dynamism...

Scott Hanselman: That too (laughs). They are adding that to C# 3.0 and they are making that happen. And its technologies like LINQ at shrinkster.com/heh and that are making that possible, right? Where you can have all of the benefits of a compiler, but also some of that dynamic behavior that you see in an interpreted language. And this is a really interesting question, what is limiting this technology in the Microsoft world right now? And I think it's the fact that underneath VB, and underneath C# there is that IL, right?

Carl Franklin: Right.

Scott Hanselman: There is that compiler. What do we lean on? What do we count on? Well, C++ programmers, they really count on the compiler. I don't have a lot of bugs, or I know that nothing horrible is going to happen, because the really, really strict compiler told me it was cool. Right? They know that something horrible is wrong before they run because the compiler catches it. But there were some dynamic language aspects that VB 6.0 had (variants) that you really didn't know the behavior until you actually run it. So, they moved that responsibility out of the compiler a bit, but where'd the responsibility go? They took 20% of the responsibility out of the compiler. There weren't a lot of unit tests, I didn't want to use a lot of unit tests in VB 6.0, did you?

Carl Franklin: No, there wasn't even such a thing really.

Scott Hanselman: Exactly. So, then about 20% of the "responsibility" -- this theoretical responsibility, of who is going to check stuff - kind of fell on the floor. That got picked up when we moved into the .NET world, where we had really strong compilers, but also some dynamic aspects of things with Reflection and with Late Binding that allowed us to do things that could get us in trouble, but we picked that ball up with Test-Driven Development. So now we lean on the compiler half-way and on the tests half-way.

Carl Franklin: So, you are saying with test driven development, or even just you are running nUnit, for crying out loud, we are, we can now -- variants aren't evil anymore, is this what you are saying?

Scott Hanselman: That's a good way to put it sort of like an inflammatory way to put it, but you are right.

Carl Franklin: I am trying to eek out the truth here...

Scott Hanselman: No, you are right, because what I am saying is that, dynamic languages are less evil if you have a parachute, right?

Carl Franklin: Okay.

Scott Hanselman: So, our parachute in C++ was a really hardcore compiler that wouldn't let us get away with anything.

Carl Franklin: Yeah.

Scott Hanselman: And we had a less of a parachute in VB 6.0, and this is why you get object reference not set.

Carl Franklin: Yeah.

Scott Hanselman: All the time, with all VB applications, right? This is because... what does that really mean, what does an exception mean? If you get an unhandled exception in your application it means, something happened that you weren't ready for, something exceptional happened, something you didn't expect occurred. Now, in a dynamic language I can write a Ruby application and I can hit save, and no one is going to do anything, no one cares that I have syntax errors all through it. So, it's on me to then fill it up with better testing. So, what I am saying is that, really awesome tests within an interpreted dynamic environment can actually take the place of the compiler because all the compiler does is syntax checks, your intent.

Carl Franklin: Right.

Scott Hanselman: But a test is a really great way of expressing your intent.

Carl Franklin: And it goes beyond the compiling stage, it actually looks for results.

Scott Hanselman: Exactly.

Carl Franklin: Yeah.

Scott Hanselman: So, then someone could really get some real good work done. If they had a language they had a really great compiler, but also a flexible enough syntax that would let them do the kinds of things like ActiveRecord that one would want to do, in a per format way and then they could built tests around it, and they have the best of both worlds and I think that five years from now, we are going to see a very Ruby-esque C Sharp and a very Ruby-esque VB, as people start to realize that Smalltalk has had these kinds of features for 30 years, and we have been kind of off in the desert, in our strongly typed hardcore compiler languages. We are going to find a very dynamic middle ground that's going to involve very few lines of code. So, what are some examples of ActiveRecord and/or Rails in the Microsoft world?

Carl Franklin: Well before you answer that question, let me ask this, which maybe on the listeners' mind also: What if you are not embracing Test-Driven Development?

Scott Hanselman: Wow, be afraid...

Carl Franklin: And not everybody does.

Scott Hanselman: Well everybody should!

Carl Franklin: But they won't!

Scott Hanselman: And that will mean more work for you and me. Let me give you an example. I had an intern this summer - I wanted to actually get him on the show but it didn't work out- and we gave our presentation to everybody, and he worked on an ASP.NET application. They did some online Banking stuff for some things that I am working on which I can't talk about. This is a sixteen-year-old sophomore in High School, okay? The guy's never coded C# before, he has had a little bit of Java in High School, he did a little VB 6.0, and he played with Ruby once, or twice. In 30 working days, he put together a nice clean online banking site, where someone could log in and pay their bills. Now how did he accomplish this? We used test-driven development; we used Watir; we used the Web application testing in Ruby for all of our tests; and we used Test-Driven Development. He wrote 168 tests in Watir that would just beat on this thing, most of it with negative testing.

This is a guy who has no computer science background - he is a 16-year-old kid who just thought about, "What would someone evil do to try to break my application?" So, he had hundreds of tests that would put garbage in textboxes, try to transfer too much money, or just fight with the application. He pounded on it like only a 16-year-old could. And we ended up with more code in our tests than we did in our application because the goal was, for the application to do exactly what it needed to do, and no more, and allow the only correct input.

When he coded in this style, he ended up with a lot of work in the tests, but then that test became his parachute. Then we have to go and do some refactoring. After we gave the presentation he had a few hours before the end of his summer, and we had a bunch of requirements, they said "We need these things changed", he said, "Oh man I don't want to change this application, it's going to break everything." and I said "No, it's not, you've got a 168 tests that will make sure you know immediately if anything is broken." And we were right. That sense of confidence of, 'Wow I can refractor this,' we cut another 100 lines out of the application and the 168 tests passing were our confidence that this thing works, not just that it compiles because compiling just says the syntax is right, but the intent, the semantics, were correct.

Carl Franklin: Well, Scott that's a very good argument why people should use and embrace Test Driven Development. However, there are those people that won't simply because it's not required.

Scott Hanselman: Yeah I understand what you are saying. And they'll have buggy code.

Page 2 of 3   « previous page   next page »