Тут весьма показателен был пример про использование только ADODB.Recordset и какого-то навороченного грида вместо родного фокпрошного (бр-р-р, гадость этот родной грид...)

Вопрос к фокспрошникам. А слышали про DataEnvironment в VB? Да, да, такой же DataEnvironment как в фоксе, только чуть удобнее. И любые навороченные гриды и остальные data-aware controls работают с DE чудесно, точно так же, как родные контролы в фоксе. Почти все происходит само, пол-программы мышкой пишется.

Чего тогда спорить и надрываться? Типизирование ввели, множественное наследование интерфейсов ввели, скоро введем обязательное объявление переменных и перейдем полностью на ADODB (т.к. базы "ползут" на SQL-сервера).
В дополнении к прозвучавшему ("... и будем настаивать на улучшении согласно нашим требованиям"), получается вообще полная ерунда. И чем тогда программа на фоксе будет отличаться от VB-шной или MS Access-овской?
Микрософт не зря хотела прикрыть его еще после 6-й версии - какой смысл поддерживать продукты с аналогичной функциональностью?

Наиболее частые участники holy wars - узкие, зациклившиеся профессионалы (тот же 1024). Большинство прозвучавших доводов с обоих сторон - дурацкие, сейчас возможности многих продуктов элементарно дублируют друг друга.
Мой довод - про отсутствие типизирования - и тот опровергли, есть это в последних версиях. Остается JIT-компиляция, т.е. модули фокса продолжают интерпретироваться. Фокспрошники тыкают тем, что в этом случае зато можно вычислять выражения "на-лету". Дык, в Access я тоже применяется вычисление выражения "на-лету". Но там, все равно, модули компиляться во время загрузки в память.

По большому счету, VB/VBA/FOX - вчерашний день. Пора всерьез заняться .NET. При грамотном проектировании, трудозатраты там получаются гораздо ниже (в разы), чем при использовании перечисленных инструментов. К сожалению, новичков отпугивает тот факт, что при написании с 0-ля, в лоб, трудоемкость получается выше, чем на фоксе или VB. Дык, потому как если мы имеем ООП, то извольте ЭТИМ пользоваться, и извольте нехило экономить на повторном использовании кода, а при использовании .NET еще и на аттрибутном программировании.
Напр. Берем контрол (ComboBox). Предположим, что мы юзаем dictionary-подстановку с помощью него. Наследуемся от него. Затачиваем на самостоятельный опрос БД, кэширование данных, использование глобального статического кэша для всех экземпляров контрола и пр.
Затем создаем "россыпь" классов-наследников, которые могут иметь или не иметь переопределенные свойства и методы. Но главное - можно указать с помощью аттрибутов в конкретных классах наследниках: строка запроса к БД, имя поля данных по-умолчанию, политику кэширования и синхронизации и еще миллион мелочей. Получили, скажем, EmloyeeSelector (один из наших наследников от ComboBox), и на всех формах где требуется выбрать работника просто бросаем этот контрол мышкой. Все!, забыли об Employee и всем что касается валидации, обновления и т.д. Точно так же можно поступить с любой сущностью в программе (и не ограничиваться ComboBox). Потом просто можно набрасывать мышкой формы, а 3/4 клиентской программы уже сидит в контролах, которые знают как правильно обрабатывать собственные сущности.

Одним словом, в этом .NET столько приколов, и такой простор для фантазии, что никакому фоксу и VB и не снилось.
----
ну не мог же я запостить и не встать на одну из сторон, а иначе, зачем вообще сюда постить?