This blog post started off on a comparison of weak and strong typed languages. However I found an article, while rather dated, but nonetheless really pissed me off.
The article, of course, was about strong typed languages, which is fine if you have an opinion that varies from mine. There is no right or wrong answer when it comes to this it is just a preference. But what pissed me off is the author, who I once respected and now could give a shit less about, was a very well known Visual Foxpro speaker and consultant.
I didn't really care for the fact he refused to sign the VFP petition, as we all were aware of the harsh reality it probably wouldn't carry much weight at Microsoft to the powers that be, but still IMHO it was simply a show of support for the Visual FoxPro community.
Anyway it is safe to assume the author made a very nice living off Visual Foxpro besides being his claim into the programing world, to the best of my knowledge. But now he is a freaking Microsoft Muppet, I had to create a new level higher then Cheerleader for shit like this where Microsoft, I assume, can just pull his strings. If Microsoft isn't influencing this writing then what the "f" is wrong with him?!
Look I am not a fan of Scott "THE DOT" GU and tend to disagree with Soma, I actually hold Soma in a bit higher regard then "THE DOT" due to the fact Soma will at least post comments on his blog that are critical of Visual Studio and let the community debate it out if necessary. But at least "THE DOT" and Soma only spin Visual Studio they don't blatantly invent bogus crap about legacy technology that worked!
This Muppet is not only spinning Visual Studio he is discussing highly questionable negative aspects of a tool that he was advocating using not long ago. His post have the potential to adversely affect VFP'S developers, if a client was considering building a VFP application and stumbled across his ramblings. These are the same developers that bought this muppet's tools and books. WTF is going on in the head of some people!
In his blog post he basically ripped on Visual Foxpro for being a weak typed language with general statements and total disregard for the truth while ignoring obvious problems in Visual Studio.
Of course I needed to set the record straight!
Let's pull out some excepts out of his post and see how right or full of shit he is!
After All Source Code Doesn't Lie
To give you some back ground, the premise is he had some old foxpro code that he wanted to refactor and move some proprieties and variables around. Which according to him was a pain in the ass to deal with the repercussions and ripple effect of an essentially minor change.
Ok so let's get into his post ...
In a strongly typed language, make a change to a property name, or remove and the compiler (he is referring to Visual Studio) will tell you where it's missing or mistyped or used incorrectly. It's that simple. The same is true if you're in full on heads down code mode and you write a large chunk of code at one time without immediately testing to keep the flow going. In Fox I have to write my code and test right away to make sure I didn't accidentally mistype or format something improperly. There are bound to be typos etc. again, in Fox the only way I will find any of these sort of problems is to run the code. In .NET the compiler catches all of that and it takes a few clicks to fix it because the compiler tells me a) that there is a problem, b) where it is and c) takes me there so I can change it. Compare that to VFP: Run the application to the code you changed, bomb, look at the code, make the change and re-run. And you better hope you excercise all the code paths.
I want to stop this right here. Factually what he said is related to properties and is inaccurate at best. In Visual Foxpro, if you removed a property or have a typo the Visual FoxPro compiler will "DEFINITELY" throw an exception.
Here is a small sample code to prove this point.
Sure looks to me like the FoxPro compiler is taking me exactly where the problem is at and yes VCX'S work the same way. WTF he is talking about!
Anyway let's proceed.
In a strongly typed language I can worry about logic errors and forget about syntax and typos - the compiler does that for me. Maybe I'm a sloppy coder, but I find that experience of writing code, having to run it and fail only to find that I left out a letter in a variable name very frustrating especially if that code is buried in the UI that often can be tested only within the application. Compare the time to fix this sort of a bug. ST: Compile see the error, click on the error, fix the code, recompile. Total time: Maybe 30 seconds. Fox: Start the application, click to the place you have to go, fail, pop up the editor, fix the code, shut down the application, clear memory etc. restart the app and try again. Time: 2-3 minutes at least. In my work (especially the last couple of days) that's a typical scenario...
This is another exaggeration of the truth. First off what programmer in their right mind doesn't worry about syntax when writing a piece of code. What the hell is he writing pseudo code and yes that is such a bastardized statement to even imply Visual FoxPro doesn't catch syntax errors. It is not even worth my time to put a print screen together of that case.
His other point, I think what he is referring to is variable name typos and scoping...
For example.
private pcTypo
pcTypo = ""
pcType = "some error"
pcType is a statement that will get through the compiler in VFP, no doubt about it and it will error in C#/Visual Studio.
But here is the kicker, he specifically mentioned UI in his comments. If you have ever used Visual Studio 2008 webforms or mvc, that thing is like swiss cheese, intellisense and even the compiler misses errors when it comes to javascript, html or jquery. That is "code and try" testing or in MVC you can use TDD. If he is right it takes 2 minutes to find a problem in FoxPro, which under most cases is not accurate, how long does it take to write a test script or debug a webform and mvc UI. Why in the hell isn't he blogging about that issue since this is such a big fing deal! And don't even tell me HTML is not compiled so Visual Studio doesn't have to catch anything, BULLSHIT! there could be a well implemented editor with error handling. This is one f'd up double standard being applied here.
I've worked this way for many years in FoxPro and I've never really thought much about it, but after having spent a significant amount of time in .NET, now when I go back to VFP code I sorely miss strong typing and the true Intellisense that VS.NET offers in the editor.
Sure he never thought about it much because the compiler and intellisense worked in Visual FoxPro for 99% of the cases. The typos in variables names happened so rare it was only an after thought. Most VFP programmers used Hungarian notion and knew the variable scope and type just by looking at the name without wasting time with all this strong typing crap. Apparently now he felt the urge to rant about FoxPro for no apparent reason other then a lame attempt to prove Visual Studio is more productive then VFP which it totally IS NOT!.
Ironically when he goes back to Visual Studio and leaves Visual FoxPro doesn't he miss not having to write plumbing code or having a class browser that functions or how about the command window to quickly and easily execute a command/function/query a table etc ... or being able to use the EVAL() statement instead of writing massive amount of reflection code. Give me a break!
Then he stated "true" intellisense: I Googled Visual Studio Intellisense Bugs, it produced 76,000 results. Move over there is limited intellisense in the UI layer of Visual Studio for web development and the Visual Studio intellisense, even in 2010 for C# has issues.
Look at this simple code...
iBroken is returning an error, fair enough, but the problem is gGuid is not where is the consistency?
Here is a UI snippet in Visual Studio 2010.
This snippet is an FING mess and not a single error being returned by Visual Studio 2010 intellisense. Leave me a comment if you can't see the problems and I will point them out.
I haven’t seen such an editor and I doubt that there will be one. It’s damn tough to parse untyped code and get meaningful metadata from just the source code alone especially if that source code doesn’t tell you type information. Without strong typing, how does the editor know what’s an object, what’s a property and whether it subobjects? How could it? It can take you some of the way as the Visual FoxPro editor does, but it will always stop short of providing a complete implementation.
The second problem with editor implementations is that it relies on an editor. The editor doesn’t compile the code. If you don’t use the fancy schmanzy editor that does this supposed syntax parsing then you’re back to having no type safety checking at all.
Sure he brings up FoxPro again, but where is even a simple case Visual FoxPro doesn't work? I honestly tried to break VFP and with the exception of some strange com stuff I couldn't. Again referring to my snippet above, there is the code editor in Visual Studio that didn't catch even obvious problems!
Let me skip to the end of his post to wrap this up.
In VS.NET 2.0 the new databinding features can bind directly to objects and the designers let you look at the objects and pick what to bind to by way of the meta data. You can drill into objects and pick properties several levels down etc. Without strong typing this would not be possible!
I am a bit confused as to what designers he is referring to in Visual Studio that indeed lets you do everything he states they can do?
Hmmm how about a class browser that let's you drill down into properties, methods and events isn't that a designer in FoxPro that Visual Studio lacks?
In FoxPro to do the same for a Fox class, we have to parse source code files ourselves and given the somewhat convoluted formats of the designer files. And even then there's not enough information in there. How do you figure out a return type in a VCX method for example? I’ve done this in Help Builder and the code to do this is a serious mess and what’s worse it doesn’t provide all the information that would be useful.
You may say that that this doesn't affect because you don't use features like this, but it does indirectly. In terms of what tools are provided for you and what functionalities are not available easily in Fox.
This is getting worse the farther we dig into it. Did the author really ask how do we figure out a return type for a method? Is he freaking serious? If you can't figure out a return type then you have more then intellisense problems with your code. Let me help him figure out a return type for a method.
Step 1: Here is how you create a class in the class browser with a return value
Step 2: We write some code that uses the class and WOW even intellisense works and we are able to find the method we created.
Step 3: Now the tricky part to figure out the return type. Lets use a couple lines of code and the command window for this complex task.
I am really glad I could help solve this mystery!
All the years I have been developing applications, return types has NEVER been a huge issue in the code I wrote. I would go into LINQ with the VAR return types or better yet the really screwed up anonymous return types in C#, but those came out after his article was posted and unlike the author I want to be "FAIR" in my analysis.
Functionality not available in FoxPro, damn why doesn't he mention core functionality not available in Visual Studio. Like a data centric language or a web form designer that freaking works or property sheets that function correctly. Shouldn't we be a bit more concerned about core features that are missing!
For example, lack of proper meta data is one reason there aren't any decent Web Service tools for VFP (and COM) because neither can generate type information on the fly just by looking at the objects. This is why it's so damn difficult to Interop with a Web service that exposes objects or even worse create one that publishes objects.
Meta Data in Visual Studio, this one I struggle with a bit, it is almost as bad as calling .NET a framework. When I think of meta-data, I can see how the compiler can extract type information and use it in C# fair enough. But in my mind a robust Meta-Data implementation is more along the lines of Visual FoxPro's VCX and SCX tables, where we have actual data that we can manipulate and extend prior to build time for some automation or designer functionality not only for intellisense. Yeah I know there is a layer we can hook into with Visual Studio to pull off some of the same things, but that is a bloated convoluted mess to work with making it not even worth the effort. Further like everything Microsoft does in Visual Studio that is a moving target as well. I believe they just released yet another RC or CTP called the MEF framework.
And you can get that same FULL information about an object instance, or type at RUNTIME. VFP sort of lets you do some of this, but it's very half hearted. The proof of this half-hearted design is Fox Intellisense which doesn't work properly most of the time because VFP doesn't have enough information to give you full information about a type.
Visual FoxPro is half hearted and doesn't work properly again but yet again not a single example of where this is occurring and Visual Studio is freaking perfect right! These Cheerleaders/Muppets will do or say anything won't they!
In closing:
This f'ing Visual Studio Muppet's post took bullshit to an entire new level. In his post he is praising more work caused by strong typing and Visual Studio while wrting about VFP'S half hearted implementation. WTF!!! On behalf of the Visual FoxPro Community, we want to thank you for dissing the tool that some developers are still making a living with!
Further what is wrong with making the compiler a bit more intelligent so we don't have to hand code the types as much or how about an opt-out option for strong data typing in C#. You are thinking, Mark that is not possible. Sure it is, VB.NET has an opt-out feature and let's consider the following example.
LOCAL pcTemp
pcTemp = ""
pcTemp1 = ""
We have a scope of local so the compiler can easily pickup on the fact it is a variable, further the first value assigned to the variable is set to a string so the compiler can also derive a type of string. pcTemp1 is not scoped so the compile could pick up on the fact there is an unscoped variable in the code. Does this have some holes, maybe, I gave it 30 seconds of thought. But the point is, there are ways to get around issues and make life a bit easier on programmers. Let the tool handle the majority of cases in an eloquent fashion and let us code out the exceptions NOT force us to code out everything because tool developers are too lazy to think!
Anyway.....
I hope everyone has a happy holiday...
Until Next Time...
.Mark
