Walter:
>.NET is a step forward in some areas because it is a OS independed platform with a common runtime where several vendors could deliver their products. However, if you look at VB.NET and C# you can see the drawbacks in productivity as well. It is not an uncommon remark up here, that you can be more productive in VFP. Things like datahandling, runtime compilation are certainly not up to VFPs standard. So how could we honestly say without a doubt that this is a big step forward ?? I'm personally stunned that anno 2007 we still have to declare our variables in strict types like integer, long, smallints etc... what is this? Is this called progress ?? I don't care about the internal types. numeric is numeric, string is string and date is date. Are we really going that backward HAVING to tell (as oposed to optional) the compiler what to expect ?? This is backward.. not forwards.
...
>OTOH, there is good news. Other languages will jump .NET and in time will develop a more sensible approach of modern programming.
Well said! At least we should have the OPTION to use strong typing or not, as both have their advantages. The budding ETecnologia VFP .NET compiler is doing just this -- use strong typing and overloading if you'd like, or use dynamic typing if that's your preference, the compiler works with both approaches. With strong typing you get a speed boost, with dynamic typing you get a productivity (and flexibility) boost. Take your pick.
As for metadata driven language like VFP, this is a huge architectural difference compared to .NET (in its current incarnation at least), and, IMO, this is one area where VFP is far superior to .NET. Ditto for the interpreted nature of the language, which makes run-time compilation and other neat (and dangerous 8-[
) stuff possible.
When it comes to data handling specifics, such as data dictionaries and metadata driven control and table properties, many .NET users have no idea what we are talking about. For example, I recentely suggested to a prominent .NET framework maker that they include a "data metadata dictionary" into their framework. To put this in common language, I explained that this way we could define things like default input masks, value domains, captions, display lengths, tooltips, display classes, error messages, read-only and visible properties, etc. etc. etc. only ONCE in ONE PLACE. This way we wouldn't have to do the same thing over and over and over again for the same piece of data in different forms and reports and web services and what have you. (And if we needed to deviate from the datadictionary defaults, we could simply overwrite them on the form level.) Their answer to this was pretty much a "blank look", as if I was speaking in tongues. Because of the mindset difference between static and dynamic languages, this didn't seem to compute only on the language side, but it didn't seem to make sense to them on the data side, either.
So, it is a "culture" difference, which in turn gets in the way of getting things done quickly, efficiently, consistently and with as few errors as possible. Having access to "data metadata" is very much an OOP -like concept. Let's take an example:
1. The phone company runs out of digits and changes their phone numbering system by adding one more digit to the end of the phone number
Now you have two options:
2a) You go through your data dictionaries in a batch mode and, for exampleREPLACE ALL INPUTMASK WITH "(999) 999-99999" FOR DATA_DOMAIN_NAME = "PHONE NUMBER"
.
2b) You go through ALL of your .NET forms and change input masks on every phone number entry by hand
I would personally take option 2a), thank you very much, how about you?
And I CAN take that option whenever I work on my VFP apps, because VFP's metadata driven, interpreted design allows me to do it very, very easily.
Pertti
