Hi Rick,

Some reading at Strong vs weak typing Thread #996662 Message #996662
There are some links to a discussion about pythons weak typing. Very interesting reading and will counter argument about all arguments you make here.

>Finding all the places where this potentially breaks code without a strongly typed compiler is very difficult (you can use CodeReferences but it rarely finds every occasion especially if you use dynamic invokation of code in places). I ended up finding little places where these changes were causing RUNTIME bugs. The only way to truly know that you've fixed everything is to completely re-test the application in hopes you find all the spots where this changed codebase affects the application. Or truly remembering where all the code references exist - I don't know my Memory isn't that good on code that's nearly 10 years old <g>.

As I've been arguing in the thread above. Compile time is too late. You should be notified of possible mistakes when typing. There is also much to say about what is a strong typed language. In some definitions VFP is a strong typed language and in another C++ is a weak typed language.

One of the problems in strong type languages is that you'll HAVE too declare each and every variable and its type. If you remember Open Word document using VB.NET Thread #990971 Message #990971 you can see what kind of problems it might give, while this is so easy to do in VFP.

Because of strong typing you need additional mechanisms like method and operator overloading which are arguably not really time nor code savers, and generally do not help in readability. I've been programming in C/C++ a very long time ago (I never really was proficient in it, I admit), but I've spend more time in solving stupid typing problems than writing an algorithm. Not exactly my idea of fun. Do I really care whether a variable is int, long, unsigned int, dword, word etc ??? it is all numeric and I really have something better to do than worriying about casting incompatible types.

Strong typing is esspecially annoying in using COM objects such as (here it comes again) Microsoft Word.

When I do a

oWord = CREATEOBJECT("Word.Application")
oWord.OpenDocument(cMyDocument)
oDocument = oWord.ActiveDocument

Do I really want to know all progIDs about the objects in the COM object ?? Do I really care ?? Do I really want to bother using reflection (C#) or set stric off (VB.NET) in order to make it late binding ??

I guess most developers not. They just want to open a word document and do something with it without unnessary coding to do JUST IN SAKE OF THE COMPILER.


>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.

Again, I think compile time is too late and strong typing is too strict. I don't want to be forced to use strong typing. In the thread above I explained that optional strong typing is a much better idea.

That really means that in VFP if you want to use strong typing you can declare your variables at the top and as you type and you make a mistake in a type (which by the way you not make in most cases when using a type prefix in your naming convention), the editor (yes the editor) should give you a visual clue that something is or might be wrong. A seperate compile switch in VFP might compile the whole project and give you type WARNINGS in stead of errors back.

So in a sense I don't think the strong typing itself has much to do with it. I would call it type checking at compile time, without the compiler refusing to compile at all. If for example I want to write a method that can receive a number of parameters of which the type is not know, I don't have to use method overloading to solve the problem. If I want to include COM objects I don't want to bother declaring variables with the proper progID just because the compiler is not able to check whether the type matches ?? Give me a break.

>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. (I try to avoid that but yesterday at least it wasn't possible because of IDE dependencies).

I think you are wrong here. In a strong type language you always have to worry about issues that come with strong typing (see MS word example above, method overloading issues, etc). That is why you can be more productive in so called 'weakly typed languages like python and VFP.

>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...

I don't believe that many VFP developers do spend a lot of time on fixing bugs surrounding wrong types. I do believe that .NET, C/ C++ programmers do spend a lot of time to make sure that the compiler does not object and do spend a lot of time working arround issues that don't exist in weakly typed languages.

>I've worked this way for many years in Fox 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.

Well, in what case intellisense is really significantly better in .NET? I do understand that you can use intellisense on defined typed properties, but that is all I could imagine. In VFP I could declare all variables at the top of the procedure and intellisense into any com object as well. Really I don't see much of a difference, except that in VFP you have the freedom not to declare LOCAL oWord as Word.Application. That I don't have intellisense then is my own fault because I did not declare it, but I might choose not to. OTOH, there is nothing in VFP that forces me to use early binding, causing deployment problems when clients do use another Word version. In .NET I either have to set strict off (VB.NET) or jump through the hoops of reflection.


>It's a huge time saver, and while there are things that are bit more complicated because of strong typing (dealing with 'dynamic' typing like incoming generic COM objects) it's not the norm and there are ways around those situations by creating wrappers or using Interfaces. Or you can opt to use VB and turn off strong typing for those particular instances where it is difficult which is rare.

I really would not call interfacing with MS office rare. And if you deploy such solution to clients running different (but compatible) versions of office you're inmediately faced with this very same problem.

>In addition, strong typing in this respect has the distinct advantage of providing meta data information which is another big advantage of .NET that is often ignored. It provides information at designtime (Intellisense that actually works), and for tools that can look at a DLL and tell exactly what types live within it and what functionality is available for it.

I'm not sure what you're telling here. Can you give a .NET vs VFP example here ??

>You may say that that this doesn't affect because you don't use features like this in your everyday work - but it does indirectly. In terms of what tools are provided for you and what functionalities are not available easily in Fox. 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 from your VFP code. It can be done but it ain't pretty and most of this is lots of manual work.

I'm curious about you definition of meta data because meta data to me is data about data in any form, and I really don't see how this really affects intellisense here.

>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. That's why when you type "THIS." in a PRG file while in a class and you get no useful information about the current class.

This really does not have anything to do with strong typing IMO. The features like intellisense advantages CAN be implemented in weak typed languages as well, just by specifying its type, but withouth the compile time constraint. I'm not saying VFP is a perfect example, but it is certainly an example that shows that intellisense can work reasonable (for most developpers anyways) without beeing strong typed. It is not hard to come up with enhancement requests for VFP10 to make it even better. Good enough to make the it irrelevant in the intellisense discussion.

>Personally I'm not looking at another untyped language unless it is for scripting and there is no other choice. The gains in productivity are too major...

I strongly disagree and really have the opposite standpoint. My time is too precious to waste with the utterly stupid things I have to deal with because the compiler objects.

Lets take a little history:
My C teacher at university had to learn programming in a time that you had to write your C code into a dumb text editor (VI, ouch), and then had to compile it onto a server a few miles away and then had to wait a few hours to get a report that some things were wrong. In that case it really is beneficial to have as much error information as possible, because then only one compile would show as many errors as possible.

Today times have changed. We use intelligent editors and a VFP executable compiles in a few seconds. Because of that we really have to re-examine why strong typing is so important.

The main reasons I object against the strong typing are:

- It offers type checking at compile time, while that actually is too late. It should occur on editing.
- It requires more work and typing before you've got something working, which is significant in prototyping. At that stage you realy don't care about strong typing at all.
- It forces you to go through hoops if you want to use variables of which you don't know the exact type at forehand (late binding COM, method overloading, type casting).

What I see for the future is that weak typed languages will provide features that are used as arguments in favour of strong typed languages, while strong typed language will always carry the burden of doing extra work in order to keep the compiler happy.

Future of weak typed languages:
- Optional declaring of variables (Already implemented in VFP).
- Optional type checking at compile time, not raising errors, but warnings.
- Smarter editors that can visually indicate that a variable has not been declared or is declared in another type as it is beeing used.


Walter,