>Precisely. Just as NOLOH generates Web2/ajax that is basically indistinguishable from what you would achieve by other means, the eT compiler delivers IL that is basically indistinguishable from what you could generate using C#.

To be fair, that says more about IL and the Common Type System in .NET than eT, in that MS has developed a system that allows a multitude of disparate languages with all kinds of idiosyncratic syntax to meld into IL whereupon the CLR takes over. I think this aspect of the flexibility of .NET is often overlooked or just misunderstood by its detractors.

>Sure. But the eT compiler has nothing to do with being a VFP developer apart from the head start.

The form of its syntax is VFP so, I am confused as to why this would have "nothing to do with being a VFP developer"?

>You're a NET developer.

You develop .NET IL, sure.

>You can deliver NET apps that run quickly and will work for Silverlight or Webforms or whatever.

From what you are saying, the assemblies will, for sure.

>The assemblies you generate can be used by other developers same as any other NET assembly.

Maybe, but I would be interested to know whether the VS debugger will be able to step through eT generated .NET code?

>Where is the victim?

Maybe the VFP developer who throws his hat in with eT, maybe the customer of an eT developer (see below for the potential reason(s) why)

>Of course I understand why people disappointed at VFP prospects and forced to make a change may be leery about tying their pendant to the VFP mast again. But you're not.

Well, you are in a way. The IL is generated from the source. The source is VFP syntax and class structures.

>You're declaring yourself as a NET developer with a mighty productivity tool.

OK

>If you insist you can deliver C# to the customer for the work you produce if there is any doubt about its NET status.

Well that would be a fabrication because you aren't delivering C# to the customer, you are delivering IL.

>It's all NET and you're a legend in the productivity stakes. Again, where is the victim?

Right, back to the "victim" or victims :)

What you have said above is all well and good. The weaknesses I can see are as follows:-

The Developer:
If the VFP developer decides to put off the decision to learn a more mainstream .NET language (like C# or VB), they are committing to eT. They now declare themselves a .NET developer - happy days! They need a job and there are plenty of those for .NET developers. They go for the interview and are asked about their C# or VB.Net experience. The eT/VFP.Net developer says "I am a .NET developer; it doesn't matter what language you use to generate IL!". The interviewer calmly advises the eT/VFP.Net developer that they have 1,000,000 lines of C# code in their organisation and shows the eT/VFP.Net developer the door.

The Customer:
A customer requires a system to be developed that uses latest technology. He understands anecdotaly that .NET is "the way to go". So, he gets quotes off a number of developers for his new system and the "legend in the productivity stakes" (the eT/VFP.Net developer) wins hands down in terms of his tender and gets the job. The system works as expected, no problems with the job. Six months later, the customer wants some changes to his system and tries to contact his eT/VFP.Net developer. Unfortunately, he is no longer in business, or has moved to another country. That's a shame but no problem, thinks the customer; "I have a .NET system and there are plenty of .NET developers around - after all, remember how many .NET developers tendered to develop my system in the first place". So, he gets a bunch of .NET developers to quote for altering his .NET system. They all ask to see the source code - "is it written in VB.Net or C#" they ask? "Hmmm, isn't it just .NET" says the customer? So, the jobbing .NET devs all look at the source code left by the eT/VFP.Net developer. "What the hell is that! I haven't seen anything like that before, looks like dBase or some such". All of the jobbing .NET devs decline the work because despite the bona-fide IL, they can't or don't want to try to work out the syntax of the source code, particularly not for the money on offer from the customer who is used to paying the lower rate required by the "productivity legend". So, the customer is left with a system that virtually no other .NET developer can or wants to understand because most .NET devs that are available do C# or VB.Net.

Conclusion:
eT is probably of interest to shops that have VFP vertical packages. To the lone VFP dev, it could be a bad move.

>AFAICS NOLOH will turn out to be an excellent choice.

I hope so, but, so far so good.

>But there's a new eT version about to release: stick around and see what eT customers think of it.

Will do :)

Cheers