Source Code Doesn't Lie

MSFT'S NEW CATCH PHRASE - VISUAL STUDIO: DEVELOPING AT LIGHT SPEED

Perhaps they confused the source code with FoxPro when they came up with this slogan as the code comparision is complete. To develop the same application between Visual FoxPro -vs- Visual Studio the results are:

VISUAL FOXPRO 26 LINES OF CODE - 8 MINUTES *from scratch

VISUAL STUDIO 2008 POWERED BY 70K+ CLASSES OF .NET BLOAT 300+ LINES OF CODE - 35 MINUTES! *using some of my prewrriten framework components!

------------------------------------------------------------------------------------

Background

If anyone has been following my friend Soma’s blog, Someone named Sam and I have been debating the pros and cons of using Microsoft's Latest and Greatest Rapid Application Development Toolkit otherwise known as Visual Studio/.NET compared to the outdated legacy Visual Basic and Visual FoxPro development tools. In the event you haven't been following this I will give you the short version of what has transpired so far:

Sam appears to be your typical VS cheerleader or Microsoft employee not sure which as he refuses to answer the question even thou I asked him multiple times. He is very pro Visual Studio to say the least and needless to say I have a difference of opinion. After several rounds of back and forth debating various points, I asked him to write a small N-TIER application using The Great Visual Studio 2008 and I will do the same using the outdated legacy application FoxPro 9.0..

Now here is the really cool part Sam would like nothing better then for me to quit posting on Soma's blog and furthermore he would be delighted if I quit telling the truth about Visual Studio, I'm sure Soma would like that as well. Therefore I stated if Sam could write this application in fewer lines of code using Visual Studio 2008 then I can in Visual FoxPro I will stop posting on Soma's blog. Seems fair enough. I will extend this offer to Soma and Scott Gu as well. Just post the code in the comments of my blog and use Visual Studio 2008 - I really don't care if they use VB.NET or C# just make it a simple N-TIER application hopefully using LINQ so I can mock the poorly implemented data context and helper objects that are required to use Linq in the middle tier.

Now common sense would lead us to believe a new great technology such as Visual Studio powered by all bloat in .NET should be the easy victor after all would Microsoft's marketing department and the cheerleaders try to misinform us? Especially since FoxPro is no longer worthy of even being produced anymore by Microsoft.

Specifications

The specs are simple, create a very small N-TIER application (user interface, data layer, database) that simply displays a form, connects to SQL Server that pulls some customer data from adventureworks or northwest sample database. Display the data in a grid formatted correctly (phone numbers etc) contained on the form and include a command button to save the data to excel. .

Actions speaks louder then words

Given I made this wager I wanted to keep up my end of the bargain. I wrote this little application. The application required 26 lines of FoxPro code and took 8 minutes to generate. There is some code that the form designer auto generated that I did not count. At the end of the blog I included all the code.

The WinForms C# version which I wrote tonight also, using my C# framework required 35 minutes. I do not have an exact line count as I had to allow for my framework code. Making a rough estimate excluding framework code, the application is around 3o0 lines of code.

Since I already had much of the functionality written into my "framework" it is hard to tell exactly how long this would take by hand to code out, I'm guessing a minimum of 2 hours assuming codeplex was used to steal some sample excel export logic since VS doesn't natively export to excel, as a sidebar can you freaking believe 70k classes of bloat in .NET and can't freaking export a dataset to excel WTF! - anyway- However, if you wrote everything from scratch including the excel export (which would be the fairest comparision given that is how I wrote the VFP application) I would bill this out at a minimum 6 hours using Visual Studio 2008 and .BLOAT.

Development Cost

Visual FoxPro: If I used VFP dbf files instead of SQL Server this application would cost about 50 bucks as that is the minimum I charge. Of course VFP has a royalty free distribution so no licensing is involved and yes it would support more then 20 users.

Visual Studio: The Rapid Application Development Tool Visual Studio Microsoft Latest and Greatest Development Environment required more then 10 times more code then Visual Foxpro to write the same application. YES THAT IS RIGHT MORE THEN 10 TIMES MORE CODE THEN FOXPRO. Being generous I will use the 2 hour estimate for the sake of argument. If we assume 125 a hour is the going rate for a Visual Studio Programmer the cost is 250 dollars. Then we still have to be concerned with data storage and hardware requirements to even get the application to run.

Even if you really want to remain in your fantasy Visual Studio World and think I don't know what I'm talking about, as misguided and flawed as that thought pattern is, below is a comment from a Microsoft MVP regarding the cost of a Visual Studio application.

...Les Pinter has a nice strategy for selling VFP apps.He first shows to his audience, most likely managers and budget-responsible people, the whole myriad of classes and possibilities of VB.Net of C# or whatever they can come up with.He is driving them crazy with all the things you can do in .NET to a point where they ask him for a price to develop that must-have application XYZ.He gives them the price and the time to deploy the app and tells them there is an alternative.... and then says, "nahhh, you probably won't be interested, it will cost you only 25% of the price I just mentioned but it won't be interesting of you". Well, those budget-responsible people ARE interested then, and then he shows them his "special framework, developed in C++, AKA VFP".He drives their minds to a boiling point with another show-off from VFP and compares that with the things he just showed to his audience. And shows that it is indeed, remarkably quicker, and, what's more, cheaper!!

Waiting for the cheerleaders to prove me wrong

I will give Sam or any other cheerleader for the matter that disagrees with my assessment sometime to respond perhaps a couple of weeks and we can see what the self proclaimed expert VS programmers can do. If I don't hear anything, which wouldn't surprise me, I will post my VS code.

I even took this one step further I offered to pay Sam to code the application in WPF and Winforms. The only catch is I get to post the code on my blog. So we will see if Sam takes me up on my offer.

Cheerleaders - No excuses for Visual Studio Please - Source Code Doesn't Lie

I know the arguments the cheerleaders will make:

1) This application is simple - Have you happen to see the examples GU uses to showcase new technology none of it is real world, cheerleaders get off and praise him for it! The size of the project shouldn't matter! The bottom line is new technology should be better then legacy technology even for simple tasks that is called progress. If new technology is not better then legacy technology it is called going backwards. If we have to pay more for new technology so we can move in a backward direction that is called getting screwed!

2) Visual Studio can do all this cool stuff Visual FoxPro and Visual Basic Can't - Some of this argument might be valid but guess what C++ can! And yes C++ DLL libraries can be consumed by FoxPro more over many small and medium size businesses only require a LAN based crud database application they don't need enterprise based features.

3) What about internet - I'm referring to lan based desktop application database development for small and medium size businesses. The market Microsoft can careless about!

4) What about data level security - Guess what FoxPro can access SQL Server so how is FoxPro to SQL Server different than Visual Studio to SQL Server. If it is written correctly!

I'm sure they will come up with other excuses and I will deal with those as they arise.

Why do this to the Great Visual Studio and expose the truth?

No I'm not pro-mac or unix over Microsoft. I develop for the Windows platform, I really wish they gave us the "right" tools for the job - that is what I want. What I am is totally pissed about is the amount of extra work VS requires to code out an application compared to other development tools that Microsoft has stopped producing (VB/VFP), the high cost of ownership related to Visual Studio for small and medium size businesses, all the cheerleadering/bullshit going on how great VS/.BLOAT are - this amounts to spin and wishful thinking.

Furthermore, VS lacks a complete implementation/integration between technologies such as WPF/ Winforms (Can you say blend) and MVC and ASP on the web side of things, everything floats out there in a half finished state of suck! Then there is all the bs plumbing/glue code to get everything working right which we should not have to worry about especially on the web side of development - want examples just view GU'S blog it is full of it.

Microsoft is also trying to redefine OOP and N-TIER standards by totally taking the focus off reuse and creating a cluster-f&*k in the UI layer - yes this includes WPF / XAML! Moreover Microsoft is spinning OS api wrappers as a framework and VS as being object oriented - then they goes as far as treating data like objects which has huge draw backs besides the bloat in the dataset object. In my opinion data should be treated as data but yet a UI control, which should be subclassed can not be in the class browser and requires jumping through hoops to code these classes out from scratch in c#!

Finally VFP has a great data centric language engine that should be part of Visual Studio which Microsoft owns the source to but they are too freaking arrogant to implement it, so instead we have 5 different miserable data access strategies in Visual Studio and we simply pick which one sucks less to implement in the application based on the requirements. Despite what you hear and read all of them have limitations in the middle tier that requires various ass backward workarounds and helper objects.

Look VS has a clear niche it is enterprise application development I will not aruge that, as a matter of fact that is exactly the technology I would use for enterprised based applications even with it's high suck factor! VS/.BLOAT are more productive to use then C++ to obtain certain functionality which exceed the capabilities of VB/VFP. However this is more the exception then the rule. For Microsoft to kill off VB/VFP and expect us to shoehorn VS and .Bloat in the small medium size business market is bullshit it doesn't fit!

This is why this blog exists and I waste my time with my friend, Soma!

Some other random thoughts

1) I want to give Soma credit, as least he posts my ramblings on his blog that is more then I will say for Scott Gu!

2) I also made the point on Soma's blog why wasn't WPF used in windows 7? Needless to say I'm not the only one raising this issue, despite what Sam would like for you to believe. Here is the link ... http://blogs.zdnet.com/carroll/?p=1890

FINALLY: The results and Foxpro code in detail

VFP Lines Of Code:
Form Init: 10 (Most of this code just sets properities which could have been done using the property sheet)
Button Click Code: 5
Middle Tier Code To Populate A Cursor: 4
Middle Tier Code To Generate an Excel File from a FoxPro Cursor: 7

Note: If you set the properites using the designer instead of coding it out, the amount of code required for this application is more then cut in half.

Total lines of code I had to write: 26
Time to build the application: 8 minutes

Below are the screen shots and code to evidence I actually did write it.

Using the class brower in Visual FoxPro, which works by the way, I exported the form and class code. The VFP class browser can also sub-class UI controls try that in Visual Studio!



















**************************************************
*-- Form: form1 (d:\sam\sample.scx)
*-- ParentClass: form
*-- BaseClass: form
*-- Time Stamp: 02/16/09 10:46:00 PM
*

* NOTE: THIS SECTION OF CODE VFP AUTO GENERATED FROM THE FORM DESIGNER

DEFINE CLASS form1 AS form

Top = 76
Left = 252
Height = 393
Width = 691
DoCreate = .T.
Caption = "Form1"
odatalayer = ""
cfilename = ""
Name = "Form1"

ADD OBJECT grid1 AS grid WITH ;
Height = 336, ;
Left = 0, ;
Top = 29, ;
Width = 696, ;
Name = "Grid1"

ADD OBJECT command1 AS commandbutton WITH ;
Top = 365, ;
Left = 312, ;
Height = 27, ;
Width = 127, ;
Caption = "Command1", ;
Name = "Command1"

ADD OBJECT command2 AS commandbutton WITH ;
Top = 365, ;
Left = 438, ;
Height = 27, ;
Width = 127, ;
Caption = "Command2", ;
Name = "Command2"

ADD OBJECT command3 AS commandbutton WITH ;
Top = 365, ;
Left = 564, ;
Height = 27, ;
Width = 127, ;
Caption = "Command3", ;
Name = "Command3"

ADD OBJECT label1 AS label WITH ;
Alignment = 1, ;
Caption = "Label1", ;
Height = 17, ;
Left = 8, ;
Top = 7, ;
Width = 121, ;
Name = "Label1"

ADD OBJECT text1 AS textbox WITH ;
Height = 23, ;
Left = 137, ;
Top = 3, ;
Width = 551, ;
Name = "Text1"

* END AUTO GENERATED VFP CODE

PROCEDURE Init
* Note I added two properties to the form cFileName and oDataLayer using the property manager
* Reference to tell VFP where the class library can be found
SET CLASSLIB TO datalayer.vcx
* Get rid of the word NULL in the grid
SET NULLDISPLAY TO ""
* Set a caption on the form
THISFORM.Caption = "VFP Example"
* Set the label caption for the filename to save and bind the textbox to the property
* Note this could have been set using the property sheet
THISFORM.Label1.Caption = "Selected Filename:"
THISFORM.Text1.ControlSource = "THISFORM.cFileName"
THISFORM.Text1.Alignment = 0 && Right Align

* Set the captions on the command buttons
* Note: This could have been done in the property sheet
* I split these into seperate buttons for the purpose of code examples
THISFORM.Command1.Caption = "Get Filename"
THISFORM.Command2.Caption = "Populate Grid"
THISFORM.Command3.Caption = "Export Grid"
* Get a reference to the middle tier SQL data layer
* Note: The class could have been dropped on the form
THISFORM.oDataLayer = CREATEOBJECT("cusSqlData")
ENDPROC

PROCEDURE command1.Click
* Use the built in VFP GetFile dialogue box
THISFORM.cFileName = GETFILE("XLS")
* Refresh the textbox
THISFORM.Text1.Refresh()
ENDPROC

PROCEDURE command2.Click
* Get a cursor from the adventurework person.contacts table for security I did not display the connection string
THISFORM.oDataLayer.PopulateCursor("Contacts", "MyConnectionString", "Select * from person.contact")
* Bind the dataset to the grid
THISFORM.Grid1.RecordSource = "Contacts"
ENDPROC

PROCEDURE command3.Click
* Export the sql contacts table to excel
THISFORM.oDataLayer.ExportCursor("Contacts", THISFORM.cFileName)
ENDPROC

ENDDEFINE
*
*-- EndDefine: form1
*************************************************


**************************************************
*-- Class Library: d:\sam\datalayer.vcx
**************************************************

**************************************************
*-- Class: cussqldata (d:\sam\datalayer.vcx)
*-- ParentClass: custom
*-- BaseClass: custom
*-- Time Stamp: 02/16/09 10:32:12 PM
*
DEFINE CLASS cussqldata AS custom

Name = "cussqldata"

PROCEDURE populatecursor
* tcCursorName name of the dataset to return
* tcConnString name of the connection string to use
* tcSelectStatement to execute against the sql database
LPARAMETERS tcCursorName, tcConnString, tcSelectStatement
* lnHandle holds a connection to sql server
LOCAL lnHandle
* Connect to sql
STORE SQLSTRINGCONNECT(tcConnString) TO lnHandle
* Create a dataset
SQLEXEC(lnHandle, tcSelectStatement, tcCursorname)
ENDPROC

PROCEDURE exportcursor
* tcData name of the cursor to export
* tcFileName name of the excel file to create
LPARAMETERS tcDataSet, tcFileName
* This code is not needed for this example but
* it is a good practice when changing workareas to save off the current one
LOCAL lnSelect
lnSelect = SELECT()
* Create the excel file
SELECT (tcDataSet)
COPY TO (tcFileName) TYPE XLS
* Return to the original workarea
SELECT (lnSelect)
RETURN .T.
ENDPROC

ENDDEFINE
*
*-- EndDefine: cussqldata
**************************************************

Until next time - Develop at bloat speed!

.Mark