Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
DOT HISTORY will repeat itself
Message
 
To
14/10/2004 03:48:36
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Visual FoxPro and .NET
Miscellaneous
Thread ID:
00950538
Message ID:
00951326
Views:
9
Walter,
very good points and I think most developers here think the same way. The "JVP" group here is louder, though, and seemingly trolling.
There is a middle ground too and that is to use .NET interop and use VFP and .NET together. USing this strategy, you can continue to develop primarily in VFP (or .NET) and still use the strength of the other..

>Jay,
>
>You want facts. Ok I'll give you them.
>
>1. .NET is not a data-centric language, but rather a general purpose development platform
>2. You have very limited ways of working with a DML locally (with ADO.NET): You'll have to do most of your data stuff remotely.
>3. Data binding is not as easy as in VFP.
>4. Datasets in .NET don't scale as they have to reside in memory.
>5. .NET generally is more low-level, meaning you generally need more .NET code to do the same as in VFP.
>6. .NET gives you more low - level control (e.g. on the OS)
>7. .NET's application is far wider than VFP.
>8. .NET is MS strategic development platform
>9. .NET is not based on database technology. VFP is more geared towards that.
>10. There are still a lot of (RAD) productivity features for .NET in the pipeline, which indicates that .NET currently is at its infancy.
>11. The .NET team is looking at VFP strengths to include in future .NET releases.
>12. According to Neil Tonking there is a plan for developing a Microsoft Business Framework based on or interconnection with .NET which makes development of database applications way easier.
>
>Question: Do you've got first hand experience in developping .NET applications ?
>
>If no, then please read some comments from other (NON-JVP supporters) regarding .NET here. You'd better read those messages as well and you might have a better and more balanced picture of the issue.
>
>I'm well aware of what facts are, as oposed to a lot of people here. The problem is that a personal experience in a certain problem is too easily presented as fact. Example:
>
>- A .NET newbee tries to port his VFP application into .NET and does not realize that you should only download the data you need via a SQL command through ADO.NET in stead of USE Mytable and THISFORM.Grid.RecordSource = Mytable. This person might conclude that .NET cannot handle lots of data and present this as fact.
>
>- A .NET developer might succeed convert his 'Tastrade' level application from VFP to .NET thereby concluding that it is easy to port YOUR application to .NET.
>
>
>My standpoint on this issue has mainly to do with the data-centricness characteristics of a development tool to develop data centric database applications.
>
>The fact is, is there is about nothing you can do with ADO.NET, you cannot do with VFP. There are however a lot of things you can do in VFP you cannot do with ADO.NET:
>
>1. Use sophisticated DML, (such as SQL, REPLACE ALL, SEEK, etc) on data that somehow got into the client. You'll have to program this functionality yourself.
>1a. For an example try to combine meta data found in the executable or a file locally with results from a SQL server. In VFP this is a breeze whereas in .NET you'll hit the wall soon, and have to rely on doubtfull constructs such as where you'll have to send the metadata to the SQL server for processing.
>1b. In VFP you can combine remote data with a DBF file and a local cursor in one SQL - SELECT statement. VFP handles data transparently. For a big part you can use the same DML for remote data, DBFs and cursors.
>2. The performance of about all data handling in VFP is at the least not slower than in .NET and in most cases significantly faster when it comes to more advanced data munging.
>3. ADO.NET datasets don't scale. They eat up memory whereas VFP cursor are flushed to disk when reaching a certain size.
>
>Draw your conclusions from here. If the points above are not a problem for you then fine. But projecting your situation on people who do use these advantages of VFP is way, way out of line. When having a data centric application you might find VFP more suited for that than .NET from a technical point of view.
>
>But of course this discussion is not at all about facts, it is about FUD. The fear for VFPs future. That in fact is irrelevant to me.
>
>Walter,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>>>That reply merits a "BRAVO!"??????
>
>>To me, yes. To you, obviously not.
>>
>>>Aside from the fact that an insult and fallacious statements should never garner a "bravo", your standards for such an accolade sure are very very low.
>>
>>Didn't see it as an insult. Seemed like the facts as I also understand them by reading historical threads from Walter. Lots of opinions, not a lot of facts or practical experience, and he doesn't seem to know the differnce between the two with regards to the subject matter.
>>
>>Not low standards, but rather a high level of agreement.
Previous
Reply
Map
View

Click here to load this message in the networking platform