Victor, I don't know why you took this so personally, but I'll try again.
My disagreement is not politically driven. I stated it's my personal choice. I'm the lead PM on the VB.NET team because I picked that position. In my prior job, I got to pick what languages we would use and selected .NET with VFP for some apps, VFP alone for some and .NET alone for some. As far as language choice, I chose VB - not C# - for personal reasons which I tried to elucidate.
That's why I also said what my position was - so that it would be clear where I stand.
None of the business reasons were in the original message - far be it from me to say "don't use .NET or .NET with VFP" All I said was make sure you have a reason. If you do, great.
VFP BizObj with C# is a valid choice - so is VFP BizObj with VB.NET <g>
>Under the hood VFP is not OO
I don't understand the meaning of this one. The first OO languages were OO under the hood either - it's what you can do with the language you're using...
>To add salt to the the wound, certain Microsoft VFP Team members are >not even advising people to stay with VFP but rather encouraging them >to move to VB.NET. <g> I wonder who gave them that idea?
I have no idea. I do know that I'm making sure that the VB team understands the cool stuff in VFP through meetings with that team, and vice verse. I wouldn't recommend that you move without a business reason - but I've always felt that way. Heck, we did VB6 work at Flash when it made sense.
>As far as which product to pick, I'll give you Microsoft's answer, then my answer. Microsoft's answer - pick whatever you'd like. Both languages give you the full power of the .NET framework.
>Once again, the writing is on the wall. Microsoft themselves are have plenty of articles saying that C# is the evolution of the C Programming language. C has been around for at least 2 decades longer than VB. It's a well structured language that will assist even a new developer learn proper programming. Sure VB is alot easier for creating "quick" utilities - but why? If I can create "quick" utilities in VFP.
>
Here we'll agree to disagree. VB.NET is a full OO, event driven, .NET language. It has some pros over C#, and C# has some pros over VB. I don't get emotional over it. It's just true.
>I disagree - C# is the better language. Why didn't Microsoft choose >VB.NET to submit to ECMA? Because C# would be easier to port to other >platforms.
Both languages implement the CLI - you can port anything to the CLI and therefore to other platforms. It's not a question of one being harder or not.
>Why create two languages that are equally powerful?
Because some people prefer one over the other. MS prefers to sell to the folks who are interested in both.
>Reality is that they are not equally powerful. .NET is very new and >not all power features have been discovered. For now, a well >structured language, closer IL relationship and the submition to ECMA >is reason enough to choose C#.
In your opinion. In my opinion, the background debugging, additional language constructs and lack of case-sensitivity are reason enough to choose VB.
That's just the way it is, Victor - the languages are close enough to each other that it is down to opinion.
>Case sensitivity drives me crazy - for instance, I type SQLConnection - which works fine in VB, but gives me a "CS1002: ; expected" error in C# because the class is SqlConnection.
>
>This is a weak example
Why? I'm an old database guy. I always (and I do mean *always* <g>) type SQL in allcaps. Been doing it for years. Other capitalization things catch me too, but this is the one I keep hitting. Again, this is why I chose VB.
>
>C# is closer to the IL, but VB compiles to the same IL (with OPTION STRICT ON) so I don't care. This means I have some higher level language constructs like WITH...ENDWITH and the HANDLES clause of methods that makes event binding really easy for me - but I get the same speed as C#. I'd rather have the language constructs.
>
>Sad to see a Microsoft representative mislead the community. C# and >VB.NET DO NOT (I repeat - DO NOT) compile to the same IL. They compile >to similar IL - NOT the same.
You're right here - in many cases they compile to the same IL, in many cases to similar IL. I plead length of message.
>
>Late binding is another example - especially when I'm doing a quick utility, I like being able to do it with late binding and automatic casting. When I don't, I don't have to. Works for me.
>
>Why would I want to know that I'm missing a class at runtime? Late binding affords you that capability. However, I'd like to know that something is wrong at compile time. Again, quick utilities - I can do them in VFP. Why do I need VB.NET? Or are you know down grading VB.NET for "quick utilities" and not for Enterprise Applications?
Don't put words into my mouth. I stated that VB.NET is good for both. Additionally, if you dislike late binding because you find out errors too late, why not admit that VB.NET gives you an advantage because its background compiler gives you error info while coding - not having to wait for compilation.
>
>VB importing to the class level is another time saver. If I import a utility library (like the VFP Toolkit for .NET - which I love and use), I can write code like:
>
>DIM x AS String
>x = FileToStr("c:\myfile.txt")
>
>instead of
>
>string x ;
>x = strings.FileToStr("c:\test.txt") ;
>
>Once again, you're misleading the community. The "using" clause in >C#.NET is similar to the "import" clause in VB.NET. Stop misleading >the community with poor examples. If you're gonna recommend the use of >a particular language have your facts straight.
I'm afraid that you are wrong here. VB's imports clause actually drills deeper than the C# using.
>
>Finally, there's one other intangible - a number of the VB team worked on Fox over the years. Our Product Unit Manager, Rob Copeland actually was a Fox Software. One of our lead developers worked on VFP for a few versions. And I've been working with Fox since Foxbase 1.21 or so. Speaking for myself, as I work on the next versions of VB.NET I'm using all the knowledge I've gathered from real world development with VFP, VB and ASP over the years to make sure we build an incredible product...
>
>C# works just as well with VFP. In fact, I've been working with inter->operability between C# and VFP - I haven't experienced any problems >what-so-ever.
I haven't disagreed with that fact. I'm simply saying that I, as a Lead PM on the VB team, as someone working on the next version of the product, am including what I've learned from around 20 years of developing applications for customers in the real-world. Many of them Fox and VFP applications. That's why I said it's intangible.
C# and VB.NET both work well with VFP.
>Thank you. Keep in mind that this transition is not a full >transition. VFP will still be used in the middle tier. This is only >to get into position should Microsoft pull more resources from VFP. >That's a real business approach.
I agree wtih you there. That's why I've been advocating n-tier for a number of years - so that you can move as necessary.
yag
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement
