OK. Now you’ve got my attention. So what were you using before?
Ok so get this…
My background is with “classic” ASP. I make Web sites. I don’t do any app programming that isn’t Web-based. I am not a Computer Scientist or even really a coder.
As I went through my happy little ASP life, connecting to Access and SQL databases, I learned more about what I could do with ASP and made more robust sites and web-based apps. I got to be a whiz at it - make a login, make a form, make some functions to validate the form, make a function to collect the form, make some functions to display data after input, functions functions functions.
When I first really started getting my hands dirty with .Net, it took me about a day to realize that what it meant to me was that the folks at MS took all of these functions that I wrote again and again and again, day in and day out, and put them into classes that I could reference.
Instead of writing my own huge function to validate, I use the validation code built into .net. Form collection code. Data listing code. Zip zip zip - all done.
Better yet, their Visual Studio tool gave me the ability to drag and drop all this stuff in. Want to make a login? Click here, here and here. Done.
Now, this sort of thing has gone on for a while with FrontPage and FrontPage extensions (purely in a Web sense, mind you) but those were shite. Lightweight. No access to the code behind and certainly not portable. Even if you had a higher understanding of the code you couldn’t do much with it.
With VS.net you can drag and drop and tweak to your heart’s content. Spend time making reliable stuff that runs server-side and use functions that are optimized as opposed to being written by you when you’re half asleep and don’t care anymore.
That is just ONE aspect of .Net - what you can do with it just on the Web. It doesn’t even touch on the deeper stuff that other posters are explaining.
Does that make sense tho?
You definitely want to learn the .NET framework if you want to program for windows. I program just about exclusively in .NET these days, and I just love it.
The latest .NET version, 3.0, contains an entire new user interface framework, called WPF (Windows Presentation Foundation). It’s the cat’s ass. You can write UI in a form of XML, or with various visual tools. User interfaces are rendered as vector objects, which means they can be scaled, rotated, or whatever. If you’ve seen the task switcher in Vista, you’ve seen it in action. You can put a video in a window, and scale it down to a thumnail, and you can still see the video playing. You can take a video, make it a ‘visual brush’, and paint a sphere with it, and the video will map around the sphere and continue playing. The rendering engine will uses your video card’s graphics accelerator, improving performance. But most importantly, it’s just really easy to build user interfaces. There are several types of layouts, or you can make your own. You can take a control, data bind any property on it to any data you want, and it just works.
For example, I could write an Ebay auction watcher that binds the size property of a listview data item to the number of bids an auction gets (and easily get that information from the eBay API with .Net calls), and show a list of auctions I’m watching where the list elements grow and shrink in real time as bids come in.
I can build an SQL business app by drawing a schema in Visual studio with a drag-and-drop schema editor. .Net classes for my schema will be generated for me automatically. Then I can simply bind the table object to a grid control with one line of code, and see my table appear in the grid.
This just scratches the surface. The power of the new .NET 3.0 tools and APIs is incredible.
If you want to see a very cool program written in .NET and WPF, check out Family Show. It’s a WPF reference application commissioned by Microsoft, and you can install it from the web site with one click (one-click install also being part of the new .NET framework). Try, it, and play with it. Think of what it would take to build that application with traditional tools. Then dlownload the source (full source and tutorials are available for free as well), and be amazed at how little code it took to build that application.
Have you ever gotten to the end of a project, and thought to yourself, “If I only knew then what I know now, I’d have done this part differently. And this. And that…”
Well, once upon a time, object-oriented programming had firmly come into its own, at least in terms of how a program was written for itself. People were starting to get an inkling that there had to be more object-oriented ways for individual computer programs to talk to each other and share components. At the time, if two programs wanted to share data, the data had to be serialized (written to a text file, spit out through a COM port, etc) in an agreed-upon format, and both programs had to contain the code that gave those formats meaning. Surely, there had to be a way to reuse the components in other programs from within your own program?
The first step (in a Microsoft-centric world), was the DLL - the dynamic link library. You could actually call some other program’s code from within your program - provided you could learn to speak their language. Speaking their language was actually quite a trick, as even different compilers of the same languages didn’t agree on what exactly the basic data types were. One thought a string was a contiguos section of memory with a null character to mark the end. Another thought it should be an integer, followed by a character array with a number of elements equal to that integer. And the next compiler thought something else entirely. The process of massaging your data to meet the format of the data required by the DLL you were calling (marshalling) was a gigantic PITA, and required some pretty in-depth knowledge of the language that the other guy wrote his components in. It also wasn’t very object-oriented; you were calling methods, not accessing other components’ object models.
Time went on, and the process improved. In Windows 3.1, we got a little more object-oriented with OLE. OLE begat ActiveX. We started registering component interfaces in the registry, and ActiveX begat COM, bringing with it the scourge of DLL-Hell, when your program went all to shit when a registered interface didn’t actually match the current DLL version. COM beget DCOM. DCOM led to, in the VB/VC++ 6.0 era, COM+. COM+ is very nice. If you’ve ever written a VB6 app that integrated with, say, Microsoft Excel, you probably had a very easy time instantiating and manipulating Excel objects. But that’s because COM+ is a whole lot of code that is hiding some very, very ugly stuff. Under that hood, it is still based on that old technology from the very first days Windows-based programs first started learning how to talk to each other.
And then Microsoft said, “If we knew then what we knew now…” , and “if computers had as much memory then as they do now…”, and “if processors were as fast then as they are now…” But the difference between Microsoft and Joe Programmer working on his little project is…bajillions of dollars. Microsoft actually took millions of dollars, rounded up a great collection of computer science’s best brains, and wrote a whole new component architecture from scratch, learning from the lessons of COM’s past, keeping and improving upon the best of the best, and throwing out or reworking what sucked. The result is the .NET Framework.
“So what?” you say, “I’m not doing integration work between a bunch of applications - I’m just writing simple, self-contained business apps.” Oh, but you are. Every window you bring up, every button and text box you put in that window, you are most certainly not writing from scratch - you’re accessing Windows services to create those elements for you. And it isn’t just how your program talks to outside components - the .NET Framework is a whole new framework built entirely on the best practices of object-oriented programming, without dragging along legacy code from dark days past - the way your objects work with each other is just…smoother…more elegant.
Keep in mind, we’re just now getting to the point where we can see .NET flex its muscles. The first working framework arrived in 2003, and gave us enough to do what we’ve always done, but do it in .NET. .NET 2.0 added some nice features and ways to do things better, and introduced a few new core features like generics (a very nice templating feature). .NET 3.0 brought some new important stuff like Windows Workflow Foundation (you won’t care about it, but big enterprise applications do) and the WPF, which really is the first “power-flex”, IMHO, of the .NET Framework. It is a very nice way of putting together a UI. 3.5, now in beta, really starts to bring stuff to the table that shows off .NET with things you weren’t able to do before (at least as well). Silverlight is impressive. LINQ is damned impressive, and will likely change the way people access their data sources, as well as work with enumerable data in general.
.NET, IMHO, is for real. Making the switch is definitely worthwhile, as it is just a nicer framework to work with and will feel very natural and smooth if you are a solid object-oriented developer. And as the new technology pieces like LINQ start to drop that a powerful framework like .NET enables, you’ll be right there in line to take advantage.
Well, I’ve downloaded some of the “Express” stuff as **ZipperJJ **suggested and I’ll start experimenting with that.
One of the reasons that my enthusiasm for .NET is tempered is because of previous experiences with so many new technologies that were over-hyped. This goes all the way back to 20 years ago when I was first working with databases and started hearing about this “new” relational model and its rules for normalization. The trade magazines could hardly contain themselves with their giddy accounts of how this would revolutionize the way we did databases. The more I read about it the more I found myself asking, “OK, so how is this different from what we’ve been doing all along?”
Finally I came upon an article that, after giving all the rules for normalization, said, “Now, anyone who has designed more than one or two databases has probably adopted these rules instinctively. It’s a fairly obvious way of going about your design.”
Finally it made sense to me. The rules of normalization were just a formalized way of doing what most of us had been doing all along.
Same thing with OO. When it first made it big splash there was all this talk about “reusable code” as though no one had ever managed to reuse code before. Not a word was mentioned about functions and subroutines and how they might differ from whatever OO had to offer. Don’t get me wrong - I’m a big fan of OO, but ultimately it has much more in common with traditional procedural programming than you would ever guess from the hype.
And don’t get me started on CSS…
Anyway, it’s been my experience that new technologies tend to be over-hyped. I don’t know enough about .NET yet to have an opinion of it, but it sure seems to be following the same pattern.
Still, I’ll start taking a hard look at it to see if it’s something that will benefit me considering the kind of work that I do.
I’m right with you, El Zagna. I’ve had the same exact experiences with new technology. You read all this hype, and once you figure it all out, it comes down to “oh, that’s just common sense” or “hmm, that’s a slightly different design but it’s no big deal.”
I always have fun with young coders when they get all excited about the latest DB library that promises to make storing and retrieving from code to tables seamless and easy. I’ve seen those libraries come and go for the last 20 years, and really, they’re never anything new, and 90% of the time they add more complexity then just coding it yourself. But the newbs always seem to get excited.
That said, .NET is worth it. Taken along with Visual Studio, it really does make life easier. Have fun with it!