>Hi Alexandre..
>
>Keep in mind that my response to Mark, with regard to the differences between C# and VB was in the context of Windows Forms. How you work with windows forms - whether you use C# or VB is essentially the same.
>
>With that said, your points about the differences that do exist between VB and C# are well taken. For instance, I can declare a read/write public property in VB with one line of code. In C#, I have to manually create the property get/set procedures. The case sensitivity is another important distinction.
>
>IMO, the curly braces, having to end lines with a ; and related items are archaic concepts. To me, a langauge should make your job easier, not more difficult. If and when I need to drop down to do low-level framework operations, it may very well be that C# is the ticket. First, I will give it a go with VB.
>
>Thanks for the input...

John,

A very, very good, if not excellent point. Whenever the language gets in the way of solving the problem, it becomes part of the problem. Years ago, when I was working in UCSD Pascal, it always annoyed me that I had to worry about the physical location of the procedure or function. If it had not already been declared, you, as you undoubtedly know, had to declare it as a forward reference. In my mind, this got in the way of solving the problem.

By way of comparison, when working in QuickBASIC, no such declaration was required. IOW, the language constructs didn't become part of the problem. In my mind, solving a problem is basically what programming is all about.

I don't mind the {} pair simply because, out of habit, when I create one, I automatically create the other. The semi-colon bothers me a bit more, but then again, in working with VB and VFP, it's a matter of not being use to doing it. The case sensitivity, though, drives me crazy, especially because I'm so used to using camel case, and have a tendency to forget whether or not a particular character was upper or lower case. Here the language gets in the way, and I spend far more time correcting such errors than I would in a language such as VB or VFP.

Slightly off-topic, but certainly within the realm of this thread, is the question of whether or not an application should be ported to a Internet/Intranet interface. Of all the threads I've read here, I've yet to see one raising this question.

I've seen, within the company I work for, as well as some of the threads here, two distinct problems or questions. The first is, "Is the application a good candidate for a browser based interface?" The second, "What are the implications?"

Those who favor taking "everything" to a browser based interface cite, among other things, deployment issues with a Windows based application, and platform portability. This fails to take the user into account. From my view the real questions is, "How will the user be served by the this change?"

The answer is, in some cases, not very well. If the application requires a "heads-down" data entry interface or heavy data munging, then the application should probably reamin on the desktop.

The implications are probably not as well understood. What a browser based interface is like is more akin to the old "mainframe-dumb terminal" style than it is to modern computing. Further, it should be remembered that the reason that personal computing has risen to its current stature is that it puts the user in control. Seems to me that what's currently occurring might be in need of this quote:

"He who does not learn the lessons of history, is doomed to repeat them."

I've seen this attributed to everyone from George Bernard Shaw to Aristotle. That aside, it would seem to me that, unless one is prudent and researches the feasiability of a browser based interface within the above mentioned context, they'll end up taking a mis-deployed application back to the desktop.

The bottom line is that VFP is in an enviable position in that it can serve both on the client and server side. The savy developer will take advantage of this. VFP isn't the "Swiss Army Knife" of development tools. That particular distinction falls to VB. It is, however, a great tool for manipulating data, either client or server side. People need to learn the differences and their implications.

Regards,