Septic Tank Trucks VS The Benz

I wonder don't most people buy cars that are the most reliable, get the best gas milage and have the most features they need for their dollar if so why doesn't that thought pattern carry over into the development tool arena? To drive the point home: Microsoft gives the development community a septic tank truck (visual studio) full of shit (.net) that stinks, to drive from point a to point b and people are happy they are not walking, having never driven a Benz (vb or vfp). Then ironically these septic tank people (also known as Visual Studio cheerleaders) try to convince their neighbors (people like me that owns a benz), that a benz is really a bad idea and I need to drive a septic tank truck! After all a septic tank truck forces you to manually shift gears, trades in the bose stereo for a shit hauler tank on the back, gets rid of the unneeded leather interior for a vinyl bench seat while slows you down in getting from point a to point b since the shit hauler doesn't have the performance of the Benz. To top it all off, the shit hauler costs more then the Benz to buy and operate. The shit haulers rationalize this decision in some cases by stating: by driving a shit hauler truck we can truely enjoy each mile we spend in the shit hauler since it doesn't go as fast as the Benz (for those of you a bit slow this translates to enjoy every extra line of code we have to write in Visual Studio that we didn't have to write in VB and VFP). Don't they get it the shit hauler only works in the septic tank industry not for driving to chuch with the family on Sunday! Simply because the septic tank truck can get you to church Microsoft says drive it and the cheerleading staff agrees with them of course. That is exactly what is occuring in the VS community and the direction Microsoft is taking with VS and DOT BLOAT.

Visual Studio is not the - end all be all - that the cheerleading squad would like for us to believe. Granted VS is sorta new (better said, Microsoft finally has a release with enough work arounds in place to make it sorta stable enough to use) and excitement exists surrounding the product. However if you look at this from a customer and development standpoint WHO CARES if it is new or not! The important question is where is the benefit in all the shit and is the the right tool for the job.

What my clients want, is to use software to get their work done in the least intrusive manner, most of them are clueless what technology is behind the UI. If you are writing a straight forward desktop application with CRUD operations and reporting why would Visual Studio be the right choice over Visual Basic or Visual FoxPro? My friends Visual Studio isn't the right choice, ANYONE who tells you different is bullshitting you. This notion that visual studio is better for small and medium size businesses, in most cases, amount to nothing more then marketing smoke and mirrors!

Here are the basic facts:

1) Cost Of Ownership: Visual Basic and Visual FoxPro both could be distributed royality free and the hardware necessary to run these applications is less then a Visual Studio/SQL Server solution so a lower cost of ownership exists with a VB/VFP based solution.

2) Data Access: Visual FoxPro can access data natively and was a great choice for developing middle tier components. Because of VFP's robust data centric language, it blows away any Microsoft data access technology out there including LINQ. Visual Studio provide zero benefit and 100% overhead in this category. There is not a single VS developer that can produce a middle tier component in fewer lines of code then you could with VFP. If you think can post the code so I can mock it and prove you wrong.

3) N-TIER Support: Visual Basic and Visual FoxPro when used in conjuction with each other had complete seperation between tiers for maximum code reuse. This is something that Visual Studio still can not do well. Even native VFP could pull this trick off. Webforms with code behind definately is not N-TIER. Linq should be an embarassment to Microsoft in that the data context violates N-TIER standards and a helper object is needed to work around linq's short comings in the middle tier. More over Linq to SQL from a purist standpoint is not N-TIER, basically linq code may reside in a middle tier however Linq is actually generating SQL scripts similar to stored procedures that is being excuted on the SQL Server machine. A puriest would consider Linq to SQL a hybrid-3 tier solution at best with most heavy lifting occuring on the SQL box not the middle N-tier. In VFP the middle tier components, when written correctly, could truely process on middle tier hardware and scaled better then VS/Linq.

4) The Exorcist Factor: In Visual Studio, Microsoft decided to take data and "posses" it, by infecting data with this this notion it can be treated like an object. The outcome looks very similar to Linda Blair in the exorcist after being possessed. The overhead related to the dataset object is enormous and almost laughable when you open a dataset in the object browser and the sql code linq generates is ridiculous. It is no wonder why numerous people and MVPS are reporting LINQ is not consistently returning correct results sets, I personally have not seen this occur. In general Microsoft's data access patterns are flawed and the sooner Microsoft realizes it the better. Microsoft has 6 or so data access technologies and each one contains varying degrees of suck!

As a sidebar: Microsoft here is a secret, VFP treated data like it should be treated as data and something amazing occured that idea worked well. The VFP community didn't need 6 different failed data access paradigms! I will let you in on something else, Microsoft you own the FoxPro source code just duplicate it in VS, that paradigm works well (much of the internals of sql server indexing is based on foxpro's rushmore technology) . You guys, in general, excel at stealing other people ideas, windows is a perfect example then with Vista you went off on your own and got in some trouble. Look you only SUCK at inventing new ideas therefore quit trying to reinvent the wheel when it comes to data and harness your strengths. Afterall that is the same direction you are taking with MVC isn't it? You waited until ruby refined MVC and you are duplicating the concept so I'm lost why are you not following the same paradigm with FoxPro and data access?

5) Learning Curve: Why do people insist on having to learn 70k classes and multiple frameworks when tools like VB and VFP accomplished the same task with 200 or 300 commands and functions. This logic defies reason.

Look, I'll give you the inside scoop, the well known cheerleaders are PAID to hype Visual Studio and/or work for Microsoft, that is their JOB, they are septic tank truck salesman! Their opinions are jaded at best, they are not looking out for your best interest and care even less about your customers. Their only concern is not to bite the hand that feeds them. Their goal is to create an artificial need then lead you to believe Visual Studio fills this need. I'm not knocking GU and the rest of the cheerleading squad for that either, we all need to make a living.

I do have a serious problem with the developers who do not work for or get paid by microsoft and still hype this nonsense. Do these people really enjoy tools that cause you more work and force you to use half implemented unstable frameworks every 6 months to keep up with the learning curve? The question I have is what the hell is wrong with you? Don't you get it, this paradigm is costing you MONEY!

As soon as more developers wake up, quit sucking up to Microsoft, stop listening to these paid spokespeople and get out of the septic tank trucks the better off all developers will be. When is enough going to be enough. Don't we deserve solutions that actually fit our needs instead of following paradigms geared towards shareholder revenues.

Wake up all, stand united with me, park your shit haulers and tell Microsoft we want to drive in a Benz again!

Thats all for now!

.Mark