>>Now if we would take such a radical turn, and start cutting the deck to build up steam (Phileas Fogg comes to mind), we'd lose the only bakcwards-compatible language I ever knew. This year I saw a FPD-app which was made to run within a VFP form. The difference between versions was about a dozen lines, half of them cosmetic. Find another language which can do that.
>>
>>Do you want to sever the tether?
>
>Now that you put it that way, I suppose we would have the same ruckus that the VB programmers had when VB.Net came out. The major complaint is that of backwards compatibility. You can't port run-of-the-mill VB6 apps to VB.Net without a significant rewrite.

My point is that VB always had such major rewrites across versions, it's just that this one now is really serious. The initial list of features which can't be used anymore went to hundred items. They've found a way to get some of them back, but the difference is still significant. We never had that - the things which stopped working in a new version were rare, few, and not as important.

>At some point you will not be able to run code that targeted an OS that has been obsolete for years.

2.6 targeted DOS, UNIX, Mac and Windows. Which ones are obsolete now? Besides, the OS-specific things were made to work across platforms - for one, the filename oriented stuff in fpath.plb/foxtools.fll worked the same on all four platforms. This is not a Fortran compiler, which still includes support for punched cards. The few things which are obsolete are the @say/get engine, and the window-related commands, but the latter still work fine with forms. Foundation read is something I'd like to see kicked out (because I never made the examples work nor understood them :).

>I don't know for a fact but I would speculate that this puts an unnecessary burden on the language, having to add features to take advantage of a new OS's services without breaking old code.

This was discussed already, and I think we had an answer from one of our guys in MSFT (JKoziol, I think) that the whole old-stuff-package takes about 0.6 megs of runtime. It's far easier to just keep it there than to spend time and effort to take it away. Besides, it may well contain a lot of stuff that we still use.