Jim,
>
>To refresh your memory it was this quote of yours, and only this really, that prompted a reply by me. Here it is: "Is learning syntactical differences a PITA? Sure, but especially in the case of a VB like language, we're not so much different. Even within the various VB type languages (VBA, VBScript, etc.) there are subtle differences in syntax.".

Well, at least you seem to have quoted me correctly this time. You're really raading far too much into this than is there. That's my fault since I failed to fully describe the situation adequately. So I shall rectify that.

When I said, "Even within the various VB type languages (VBA, VBScript, etc.) there are subtle differences in syntax," I was particularly thinking of VBScript because I've been doing a lot of work lately in that environment. When I referenced "...learning syntactical differences a PITA," previously I was thinking about VBScript. Now the "PITA" comes in the form of the < whap! > Hit yourself in the forehead and go, "Did it again!" In my particular case this happens especially in the case of the IF/ELSE/ENDIF block. I have this tendency to forget to add the "Then" and to make it "EndIf" rather than "End If". Naturally, when I double click on the script file to run it, I get a compiler error, followed by my smack to the forehead.

In VBScript this is kind of understandable. Afterall, the design environment isn't exactly the best. It's Notepad. However, in VB proper, if I forget the "Then", I get prompted just as soon as I hit return with a dialog saying something like "Expected 'Then'". If I type "EndIf" the editor automagically makes it "End If".

The bottom line here is that this kind of stuff isn't really significant enough to cause a really long delay in the development process. You make a mistake like the above, try to learn from it and proceed.

>SNIP
>>
>>>>Types? I'm not sure I understand. VFP is an exception in that it is loosely typed. Most languages are not. Is it Microsoft's fault that this is the case?
>>>
>>>You confuse "different source 'types'" with 'loose/strict typing'??? I meant .bas, .cls, .frm, .vbd etc.
>>
>>And what does that have to do with programming, Jim? Zip, nada, nothing. The source code has nothing to do with it.
>
>Really? Could I do much at all in VB if I didn't know these things? As I see it, they have everything to do with programming in VB. I can't solve any problems if I don't know what they are, how the interrelate and how to make them. Do they have anything to do with syntax? Hardly. And that precisely makes my point. Unfortunately, there is more ((yes, my opinion) to programming than just syntax.

What the extensions are for the VB source files is an issue? It's the VB conventions. If you want to know what the relationship is with the extension, look in the Windows Explorer. It's project based. You open projects. If you create a form, it saves it with the proper extension.

What you're talking about here is the development environment. When it comes to writing code, the difference is syntax. Leaning a new development environment takes some time, but it's not like it an overwhelming, steep learning curve thing.

>>>
>>Since, however, you accuse me of changing the subject, let me talk about strictly programming. Programming is governed by a series of principles. To ascribe to your position, the principles are language dependent. In fact, they are not. They are language independent. You apply the same principles regardless of the language you're working in. Only the clueless would claim otherwise. That's fact, Jim, like it or not, fact.
>
>Sure it is, and that's exactly why I had said, long before I joined this issue with you, that I design in English and not any programming language. Again, the point under discussion is the allegation (do alligators make them?) that programming is nothing more than differences in syntax.
>Again using VB because I know a tad about it... First, as noted above, if I don't also learn what/when .bas, .cls, etc are and are applicable, I won't go far. Now let's look at VB's syntax. I want to use it to open a .dbf table with the index set on CustomerNumber and seek for the customers in a .TXT file to update their .dbf records with content from the .TXT. How does the syntax for VB let me do this? It doesn't.

Why should it? It's a general purpose language. That's the intent of it. VFP is a data manipulation language. That's its design and intent. Languages often serve very specific needs. It's unrealistic to expect VFP to do everything that VB does and vice versa.

>Another small VB example. I may know how to code a .cls module. But unless I also know how to use the tools that are integral to the VB IDE I will never evn be able to test that .cls.

I already dealt with the design environment. It isn't a big deal. I haven't dealt with VB Class Modules, but if you want to run something else in VB, press F5.

>To summarize, any programming language involves much more than syntax, and learning only the syntax will give you source code that may or may not solve the problem and likely won't do anything unless you also know several other things. And even with the syntax, languages have subtleties that syntax alone doesn't 'explain' and it most often takes more than just the syntax of any command to make that command do what you need it to do.

You RTFM then. The thing that strikes me here is this. During much of this post, you talk development environments or IDEs. IMV, it's basically the user interface and tools provided. You link this to "programming".

Now, I'm going to define what I mean by programming. Designing and implementing programs to do a particular task. I pointed out that the major difference is purely syntax. You've got to learn a new syntax. Now depending the language, the degree of difficult varies. I have pointed out that the main process of program implementation is language independent. Thus it would seem that the chief difference is in the language itself and how to accomplish necessary task(s) using it.

When I brought up an inextricably linked part of the process (design), you told me that I was changing the subject. You, bring up the IDE, and that's not changing the subject. OK.

If you think that learning how to use the IDE is more difficult than learning the language proper, you're entitled. I personally would think that the latter would be true, and even so, not a major hurdle.

You said to in another thread that you're an optimist. I am too. I think that folks if they just gave some effort into learning a new tool they'll find it easierr than they may think, learn something that helps them. OTOH, if Microsoft would do it for them by putting out two separate versions of VFP (as you espouse) one to run under the CLR, they'll still have to deal with the differences with the two versions, and won't be better of for the experience.