Hi rick,

>Interesting discussion.

>>- It offers type checking at compile time, while that actually is too late. It should occur on editing.

>And how does that work in a loose language? In VFP there's nothing that can check and make sure your variable is declared as local. Intellisense is of no help here.

First of all. Note that I'm not talking about VFP or any specific 'weak typed' language. Just the difference between strong typed and weak typed languages. In fact the termonology is wrong though. VFP and .NET language are both strong typed. The difference is however that .NET is static typed and VFP is dynamically typed. But for the discussion lets still call it strong vs weak typed languages.

The key to my argument is, that you don't HAVE to make sure a variable is declared at forehand. If you did not declare it, you won't have intellisense and the editor could display a hint (like the read line under the misspelled word in MS word) that the variable has not been declared or that it has been use in a function that does not allow that type to be passed.

> You want background compilation - fine. VFP has it and does a pitiful job at it. VB.NET has it and it actually works pretty well. C# doesn't have it and I don't miss it.

This is not really the issue whether VFP has it or not. The fact it is not exclusive to strong typed languages. Whether it has to be background compilation or not, I cannot say. It depends on the implementation.

>Compiling code takes seconds with incremental compilation even for fairly large projects. I rather see a list of errors and not be interrupted while I'm typing my stream of conciousness.

I'm talking about modeless hints. You can type the whole thing without interuption.

>And you do get hints for variable declarations and bad syntax as you type in the C# editor even without background compilation. The fact is in C# I can very quickly tell that I have a problem even in the editor when I use Intellisense. Intellisense works against uncompiled code by the way in case you were wondering. So if I create a type variable the editor immediately know the type and provides intellisense. If it doesn't I know that the var is not defined properly or I've mistyped.

>But really these are editor issues. Some of this can be done by an untyped language as well, but not all of it and not as consistently (as evidenced by the VFP Intellisense shortcomings).

So how does this relate to strong typing? I guess it does not at all. All this can be implemented in weak typed languages as well. Hence my comments.

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

>I'll give you that COM interop is one place that is not as smooth. But then again there's a lot less need to use COM directly in .NET. For openeing a Word document you either a) import the type library and get strong typing for your COM object or b) you use the Office Tools for .NET which provide complete managed wrappers for all the office applications.

For a) we already concluded it has portability problems with other versions of the same product. and for b) it really is working arround issues that should not be there at all. A development language should be easy to learn and to work with and you should not care about issues that the language or IDE could determine itself. This is something that the developer of Python understood really well.

Personally I see the next step kind of the same step as from C++ to C# (Getting rid of pointers). Getting rid of all the trouble you'll have to do for keeping the compiler happy.

>There *are* messy things in .NET like returning dynamic objects thataren't defined in a type library ( like VFP SCATTER NAME Objects ), but there are other ways to accomplish that task that's arguably more up to date such as returning collections of fields. But again this applies to interop which if you are using .NET is something you don't have to do nearly as much as you have to in VFP generally.

Those messy things are directly related to the strong typed nature of the product and therefore to create a more simple language, you should try to get rid of it. IMO, microsoft has to make a fundemental step to create a development language that is simple to grasp without the developer having to deal with complex and messy solutions surrounding strong typing. Therefore the next step should be: Get rid of strong (static) typing. Sure it will be a challenge to get it al fleshed out.


SNIP

>You're repeating the same point again.

Yep, I am. Again it is about making the developper happy, not about making the compile happy.

>That's what Intellisense is for. In .NET you'd import the type library and get strongly typed wrapper around the COM object so you get the best of both worlds - strong typing and not having to figure out what's available.

Again here you are talking about early binding, which is not always the best choice, esspecilly with office package, but also some other tools like Crystal Reports.

Also, I'm not sure what you're trying to tell here. If you open word and store the reference into a variable, you'll have to declare it with the progid. Don't you ? Whether you then can use intellisense to drill into the comm object does not have anything to do with strong vs weak typing. VFP can do exactly the same.


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

>It'd be nice if that happened but it doesn't. I haven't seen an editor for an untyped language that does this, but you basically get that behavior today in any typed language.

Hence my feature request for VFP10. Of course it is available in any strong (static) typed language because it is an error to the compiler. Weak (dynamic) typed languages are checking the type at runtime so the compiler does not really care.

Technically it is possible in weak typed languages to do the same as strong typed languages (all we have to do is modify the compiler, not the compiled p-code) but we have an opening here to allow for dynamic typing in some way. This is taking the best of both worlds.


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

>It looks to me that you haven't used any recent tools that do this sort of thing for you almost automatically.

What tools, and what do they do? So why did you not answer that in the thread of the MS word problem? Take for example method overloading. In most cases you end up with as many procedures (methods) as there are parameter type combinations while the whole procedure probably does about the same. You and I might be smart enough to create a 3rd procedure to handle the meat in it, but whole tribes will repeat the same code in each overloaded method. Is this really an advantage?

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

>Is that the only argument you have? COM Interop? Because that's the only time where this matters. If you're using native types all the type info is available all of the time.

No there are various others. Again, I repeat method overloading (operator overloading has more or less the same problem but in practise is applied seldomly IMO). Of course there is the issue of algorithms of which you don't know which type you're receiving. Now I'm not experienced in .NET, so maybe I ask something that is easy to do in .NET but for example how would you do something like:

FUNCTION FindObjectWithMyPropertyInHierarchy(oParObject, cMyProperty)
LOCAL oObject, oRet
oRet = .NULL.

DO CASE
   CASE PEMSTATUS(oParObject, cMyProperty,5)
        oRes = oParObject

   CASE TYPE("oParObject.Objects[1].Name") = "C"
        FOR EACH oObject IN oParObject.Objects
            IF !ISNULL(FindObjectWithMyPropertyInHierarchy(oObject, cMyProperty))
               oRes = oObject
               EXIT
            ENDIF
        ENDIF
ENDCASE
RETURN oRes

And if this is easy to do in .NET, how does intellisense handle this, because the return value can be any object type?

>And if you really need to you can use VB.NET with Strong typing Off in separate assembly for handling the 'nasty' COM interop stuff that can't be addressed easily.

And thus is a form of Weak typing and going into the direction of making my point.

>And even if you don't the code you write to use indirect referencing with Reflection is not that complicated especially with a wrapper function.
>
>object o = Activator.CreateInstance("Word.Application")
>
>wwUtils.SetProperty(o,"Top",10);
>int Top = (int) wwUtils.GetProperty(o."Top");
>
>wwUtils.CallMethod(o,"Open","d:\temp\test.doc");

And again is another proof of making my point. It is unneccary work and complexity and requires to developer to learn to jump through the hoops of strong typing. Let take the following.

int Top = (int) wwUtils.GetProperty(o."Top");

The (int) casting is purely to keep the compiler happy here, because you already defined it int. Now what happens if you casted it into char or another type ? Your compiler does not object, but your program crashes. A situation that does not exist in weakly (dynamic) typed languages.


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

>No because VFP doesn't have typing. Everything is a variant. They do spend a lot of time fixing Syntax and typing Errors. At least I do and I hate fixing those at runtime where there's a good chance I'll miss one in testing.

Most Syntax errors are caught when closing the method or program file as the compiler will error. Typing error indeed are a problem, but technically there is enough posible to reduce that to about 0. Again, that VFP lacks that currently has nothing to do with my statement about strong vs weak typing.

>I think you're supposing C++ which arguably is a very difficult language in terms of typing. But C++ is a much lower level interface than something like C#, Java or VB.NET all of which are strongly typed and provide you high level language features without excessive 'casting' and type coercion required by a low level language like C/C++.

Yep, indeed C/C++ is an extreme example to see why you want to get rid of strong typing.

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

>There are many problems with Intellisense in FoxPro in that it doesn't pick up type information properly. For example, the aforementioned THIS. in a PRG file shows you nothing useful about the current class except the base class info.

This issue itself has nothing to do with strong (static) vs weak (dynamic) typing.

>Intellisense doesn't work at all unless the class you're referencing is is loaded into memory and then only if you declare the type ('sort of Strong Typing'). So to get any benefit of Intellisense at all you have to use strong typing work style anyway, except you don't get real strong typing.

You hit the hammer on the nail. When you want to use the advantages of strong typing, you can. If you want to use the flexibility of weak typing. You can also. Taking the best of two worlds.
Now don't get me wrong. I admit that we are not there yet that weakly typed languages have accomplished this. But again there is nothing technically preventing this. OTOH side strong typing will always come with difficult issues to solve in regards to flexibility.

>Intellisense against a COM object going a couple levels deep, fails unless you reassign the reference.

No problem with that as long as there are no collections in there.

>Intellisense against array elements doesn't work unless you reassign the reference. Fox Intellisense gives you NO information about return types (because VFP doesn't have metadata nor a type system).

>And coming back to your point in order to get anything to show in Intellisense for local variables you need to actually declare them in Fox too. So you have a sort of attempt at strong typing, but not really. You do the work but only get partial benefit.

See my comments above. That is exactly the goal.

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

>Damn Walter - I'm sorry but if this is your only point it's a pretty weak one given the ways that this can be done in .NET.

Sorry Rick, but you called this situation rare. Not me. It is not my only point. See my comments about method overloading and the example above. It all is about flexibility. Googling on "Dynamic typing" "Static typing" will give you many more arguments on this topic than I can ever come up.

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

>Say you want to know what members class X has. How do you find that out without an instance in VFP?

LOCAL oObject as TaxTextbox OF h:\ids5\source\classes\taxbase2.vcx

or

LOCAL oObject as progid

>Or say you have a code generator (like I do in wwSOAP) that wants to create a WSDL definition for a Web Service, so it needs to know what methods are available on that Web Service? How do I do that in Fox? The answer is not very easily - you have to parse source code. There's no way to get type information about an object without running it (or compiling into a COM server and then reading the type library which is what I've done - and even that is very unreliable because unless you are strict you'll get only indescript variants for your types). Or you want to create an XML structure for your object so you can pass it to Web Service?

Well since I'm not doing web services or soap, I can't tell exactly what your arguments are about, but again, I don't think this would not be possible in weak typed languages.

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

>It has to do with being able to retrieve type information which is very useful if you're building tools and lower level components like frameworks.

Yep, but that in itself has nothing to do with strong vs weak typing.

>>>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.
>
>Like I said I think you're making your assumption based on something low level like C++. It's nothing like that in a high level language like C#, Java or VB.NET...

You might be right on that one. But of course C/C++ are perfect examples of strong typing.

>>- 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.
>
>This is a non feature. If you get a warning - what would you do? Just ignore it? Please...

For prototyping ?? Maybe you're right and erroring would be reasonable *if* the type checking is optional.

>>- Smarter editors that can visually indicate that a variable has not been declared or is declared in another type as it is beeing used.

>In the future we won't have to work, and food will be delivered by naked Bud babes on a beach. Oh and we can teleport anywhere and anytime we want... <g>

Your point is ?

>The technology to do this is here today, but such an editor or tool doesn't exist and I'd put my money on it that in the near future such an editor won't show up because the popular languages are strongly typed and the high end dev tools are being designed for that...

lets see. PHP, Python are popular languages that are strongly typed. BTW, that what you call popular languages are strongly typed has in itself no basis for the validity of weak typed languages nor its future at all. Please have a google and you'll find more objective information about this topic.

Walter,

>
>+++ Rick ---