George,

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

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.

>
>>
>>Sorry George, but it isn't. Programming is programming. Design is design. Programming uses a language that a computer program can discern and turn into actions inside the computer. Design is the process of describing a (new, sometimes) way to meet business objectives, often employing programmed applications and often employing procedural innovations of a manual nature.
>
>This is as an irrational statement as I can imagine. Design and programming are inextricably linked. In fact, I cannot recall any book, scholarly or otherwise, that I've read that didn't devote considerable space to design. "Business objectives" are just another way of saying "problems". "Design" is how those problems are addressed and partioned into segements that are solved on an individual basis.

Yes, I'll agree. This is generally known as "design" or "system design".
>
>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.
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.

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.

SNIP

Jim