Re: Alternatives To Foxpro

Sure. The cool technologies long hasn't been anything Microsoft. However, I believe that Microsoft does deliver good solutions that have the core features you need to build sophisticated systems. Where Microsoft lacks and always has lacked is doing the last bit of abstraction to make a technology really easy to use. But, the tools to create that last bit are usually there and that's where I've spent a lot of my time (because that's what I like to do - adapt for real world develoeper use cases).

Other technologies are more hip these days for sure - .NET is almost 10 years old now and hardly anything fresh or exciting but if you develop on Windows and you're interested in integration with the OS, then it's the best solution by far out there. One set of system APIs for Web, Service and desktop with re-usability across all. This simply isn't available from anybody else. And you can still use your front ends of choice (ie. JavaScript/Html if you choose).

I don't think that MS is an end all solution but based on the work I do which is very cross-cutting from desktop to Web, it fits with what I need. One set of tools that works across it all without having to switch.

In my opinion Microsoft thought they would guide the world "lemming developers" in their direction. I laughed when many vendors wouldn't allow flash and silverlight in their browsers.. Now MS wont even allow Silverlight in their own IE 10 browser.. MS goes where the money is.. even if they put billions of dollars into something, dragging lemming developers along the way.. then MS drops the project and the lemming developers go over the cliff.. Many developers have switched to ruby - python - php - java and other techs so they're bound by MS..

Very true, but you have to pick your poison. I completely ignored Silverlight for example, realizing early on that Html/Css would eventually win out and win the day. Although we're not there yet I think eventually that will bear out, not just for Microsoft but also for Apple (iOs), Google (Android) for the very same reasons. Developers will demand (and already are stepping up to that with solutions like PhoneGap, Sencha Touch, Titanium etc.) that you can build apps once and run them on various devices. We're not there yet, but the writing's on the wall that that's where we're heading.

Things will change regardless of what you're doing now so whatever solution you're building today is likely going be very different in the next few years I'd bet. At least Microsoft is 'playing catchup' and providing solutions/integration for new technologies, and you can pretty easily work with anything that's coming along. I don't consider that a bad thing at all. You can run with the latest and greatest bleeding edge tech and still use their tools to build it. That seems like a big win to me.

I'm not happy with a lot that Microsoft does, but overall the stack and tools is pretty close to what I need to do my job which is more I can say of most other single focused solutions that I've explored.

+++ Rick ---

The above creates json faster than all the other ways I've done it in vfp... unless I just need 1 or 2 records.. then I do a SEEK ... SCAN WHILE.. generate the json in the loop.....

Of course it's faster, because you're not checking for valid json so you're not parsing the string as any other parser has to do. The perf difference will be significant. However, if you have special characters, your JSON breaks, which is even less cool :-) The bottom line with this IMHO: If it hasn't broken your client code yet, you're lucky that it hasn't or you're not testing edge cases hard enough.

I'm sure other people have better.. faster ways... I was just saying that in the past this was faster at creating json than C# in .NET.. but it looks like MVC had many improvements added to it in the ajax/json area.

Actually JSON production can be done in a lot of different ways and MVC is not even necessary to make that work especially if you're building an SPA app. A service is the way to go for this actually (and I'd argue that for any platform including VFP). Separation of concerns. OTOH, none of the native .NET JSON parsers support ADO.NET objects natively (you can build your own converters) but various third party parsers and tools do.

So I'm sure Rick is right about C# .NET is faster... I just want to see for myself...

My point wasn't that .NET is faster or better - frankly for 90% of the apps people build performance of language/runtime has become mostly inconsequential due to faster hardware and optimization.

Instead I'm trying to point out that a lot of things that die-hard FoxPro people keep clinging to are not always true - they're based on hear-say and second hand knowledge. There are things that VFP *does* do better, but honestly there are not that many of them. The main differentiator of VFP and other languages/tools IMHO is that:

While that's powerful and nice it also isn't necessary in most scenarios and even undesirable if you're using a SQL backend (which also then works different in VFP natively).

What else is there that you can't do in other languages? Not much...

I've been using ExtJS 3/4 for 2 years now... works like a charm... If I take just the json produced and run it through jslint... I'ts valid... no trailing comma "that IE doesnt like"

No argument there. Client side libraries don't require Microsoft or any other big company to back them and there are lots of choices most of which mix and match just fine. But also realize that this is also not a one size fits all. ExtJS is for LOB/Form UIs and doesn't work so well for free form, document centric UIs. Heck even ExtJs is in flux with the move to Sencha which uses a completely different mechanism from the ExtJs UI framework even though it's the same team doing the work.

There's no right or wrong with anything. If you have something that works for you you should stick to it as long as it makes sense politically. I have no interest on selling anybody on any other technology, but I get really miffed when people misrepresent tools to do things 'better' when that's often not the case.

I also want to make it clear that I still support FoxPro with the tools I sell and I love doing it and continue to evolve them even though the financial incentive to do so has long since dried up...

+++ Rick ---