Occasionally, I like to disturb the state of software engineering nirvana to force myself and those poor few who are listening to take a second look at the commonly accepted axiom or state of affairs. Today, I'd like to go out on a limb and suggest a multibillion dollar strategy shift for Microsoft, and I only want 0.1% of all the moneys saved as a result of adopting my strategic suggestion. So, here's my ambitious contribution to the world of software development this week:
Drop the VB.Net as a language and either build something that truly allows RAD of web and Windows-based apps, or put the savings into building a better Object-Relational Mapper, bringing functional languages to the masses, or donate them to a worthwhile cause. A worthwhile cause is, of course, in the eye of the beholder. Expanding Victoria's Secret fashion show is a very worthwhile cause, in my humble opinion.
There are three main reasons why I think that VB.Net should be going the way of the VHS tape: the language is too similar to C#, it is not even remotely "basic" anymore, and it has already served its purpose of giving VB6 developers perception that they weren't left behind during the migration to the .Net platform.
First, the abundant existence of web-based VB.Net to C# translators is a clear indication of extreme similarities between the languages. I've used those translators on multiple occasions, and I understand that they may not be perfect, but they are not bad. Because the languages have an almost identical set of features and are syntactically similar, I see no advantage in developing in one over the other. But I see a great pain and the expense of managing the two separate development environments, having all the samples written in both languages, etc.
Second, VB.Net did not do to web/smart client development landscape what Visual Basic 1.0 did to Windows development. If you had the painful pleasure of reading Charles Petzold's "Programming Windows, Fifth Edition" and if your mind works anything like mine, I bet on more than one occasion you thought "all these pages of C code just to display a window and process a few messages?" VB 1.0 abstracted much of the code needed for drawing windows and processing messages, and the market for business software exploded as a result. Unfortunately, VB.Net does not do the same for web development--you are still responsible for knowing quite a bit of (D)HTML, CSS syntax, and, of course SQL if you are working with the database.
Third, I believe that the reason VB.Net came into being was to offer what VB6 developers would have thought was a natural path towards building the next generation of applications. On the .Net platform, of course. With C# syntax being so Java-like, all the VB6 developers would have been hard-pressed to start using C# when you could potentially "write once, run everywhere." That reason for VB.Net existence is no longer valid--most developers have bitten the bullet and upgraded their applications by now (or in the process of doing so), and they have come to appreciate the power of the .Net framework itself with all the tools it provides rather than just the VB.Net language.
So, if in the near future you see Victoria's Secret fashion show tripling in size and all the models having the "Your Potential. Our Passion." tattooed on their back, please feel free to send me a "thank you" card. You will most likely find me in the islands, Lamborghini parked close by.
On the other hand, if you think that I have totally lost it after a recent head-bumping accident and I am totally missing the point with VB.Net, I welcome hate/constructive criticism mail as well. Direct it to "echuvyrov at msn dot com".
"Learning WCF" uses an unexciting approach to explain technology for technology sake
In an effort to stimulate discussion and perhaps occasionally give people a golden nugget of information at the user group meetings, we are continuing with the book reviews. This month I reviewed "Learning WCF" by Michele Bustamante. The motivation behind reading this book was to familiarize myself with the WCF technology and determine its applicability to the projects that I am working on currently and my future endeavors.
WCF is an amalgamation of previous technologies--ASMX, .Net Remoting, Enterprise Services--all encapsulated in a set of grandeur specifications with catchy names like "contracts, bindings, endpoints" that will certainly bring billions of dollars in consulting fees. Unfortunately, I was searching for ideas on how WCF can help me architect/develop distributed solutions that are better and more reliable than has been possible in the past. Sadly, Ms. Bustmante's book was not the place for answers to my questions.
Based on 6 reviews, Amazon.com had this book at a 5-star rating, which gave me a reasonable expectation that it must be a good place to start my WCF journey. My brain works best in a top-down decomposition manner, where I take the big picture, understand its place in the universe, and then break it down into smaller component parts. The author takes a different, more of a bottom-up, approach by throwing a lab at the reader, then explaining what happened during the lab and what technologies the reader has learned. I found this not to be very intuitive.
Main themes of the book are (please bear with me as I mainly recite the table of contents):
-Chapter 1: Definitions: Services, hosting, endpoints, bindings, metadata and behaviors
-Chapter 2: Contracts: Service Contracts, Data Contracts, Message Contracts
-Chapter 3: Bindings and types of bindings: BasicHttpBinding, WSHttpBinding, NetTcpBnging, etc.
-Chapter 4: Hosting Services: type of hosting (self, IIS, and WAS)
-Chapter 5: Instancing and Concurrency
-Chapter 6: Reliability and message queueing
-Chapter 7: Security
-Chapter 8: Handling exceptions and faults
On the positive side, the coverage of various topics is pretty in depth. The author clearly has put in a considerable amount of time writing the material and code for the labs included. Unfortunately, it is not written in a very exciting manner--no jokes about Microsoft, and, the biggest disappointment of all (!), Victoria's Secret fashion show is not mentioned even in passing.
Generally, I felt that my time was not very well spent reading this material page-by-page. Perhaps a better approach would have been to treat this book as a reference manual, working through the labs to solidify individual concepts on as needed basis.
Bottom line: "Learning WCF" is not bad as a "how to" reference on WCF, but definitely not a good source on "why WCF, when WCF, and what is most appropriate WCF configuration for a given business scenario." This is "technology for technology sake" type of material, so if you don't like this approach, you are probably better off looking somewhere else. 2.5 stars out of 4.
Next month, I will briefly review "My Job Went to India: 52 ways to save your job" since outsourcing and relevance of software development in the future is something that's among my primary concerns. I am extremely interested in the opinions of the audience regarding the book and the offshore trends in general. I hope to see you there.