Здравствуйте, misha_irpen, Вы писали:

_>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.

Первые 10 страниц я прочитал, дальше уже не могу. Потому извиняюсь если дублирую чей-то другой пост.

Самое первое, что хотел бы заметить — это то, что мы живем в жестоком мире, где главное не качество, а маркетинг и продвижение. Сколько прекрасных технологий не выжило из-за более баблистых конкурентов? А сколько просто не вышло на рынок? А сколько авторов даже не начали работу из-за боязни конкурентов?

Короче все это — cruel world.

Сколько раз MS делала подлянки с частичным выполнением стандарта или недокументированым API? И в результате у конкурентов выходили несовместимые продукты, которые не могли предоставить весь функционал продуктов мс. ессно заказчики просили писать на технологии, которую "рекомендует" мс.
Как удается в таких условиях выжить джаве — мне непонятно, но sun держиться и они молодцы.

Потому уход делфи из рынка я считаю на 60% по маркетинговым причинам, а не техническим.

Теперь техническая часть.
Сразу оговорюсь — я с самых пеленок (в переносном смысле) ориенторовался на продукты MS исходя из простой как сало истины "бабло побеждает зло", но дальшие мысли попытаюсь сделать максимально объективными.
И еще: опыта в разработке на делфи у меня немного, использовал его когда только преподы заставляли писать именно на нем.

1. Делфи в некоторых вещах даже опередило свое время: в частности в datatable/gridview (может называется по-другому, но думаю все поняли). Такого уровня легкость работы с источниками данных и их отображением появилась только в .net 1.1/2.0 (2003/2005). НО при желании сделать "чуть влево-чуть вправо" надо было потратить намного больше усилий, чем сделать "по прямой". Это отталкивало и казалось что решение нерасширяемо (еще раз повторюсь, что это все ИМХО). Очень много механизмов в делфи скрыто от глаз девелопера, а вообще-то прятать надо их от юзера, а не девелопера.
2. Оптимизация. Я начинал писать любой модуль с {$O-}.
Один раз у меня был цикл

for i:=0 to 8 do
...

каково было мое удивление когда он после 8 шел в 9, 10 и так до 12, где вылезала ошибка доступа. Тогда я отнес код преподу, который слегка о*[удивился]*л с таких дел.
И это не единственный случай.
2.1. "Inaccessible due optimization". Кто знает, тот поймет.
3. IDE. Это самое слабое место всей цепочки.
3.1. Ошибка работы с чем-то.
Наверное все попадали в ситуацию когда Delphi IDE нарывалось на какую-то ошибку. Тогда оно начинало об этом гласить через какое-нить окно с единственной кнопкой "OK", часто еще с паузой в 2-3 с, с зависанием среды и в цикле. Например если что-то случилось с БД или компонент не найден.
3.2. Intellisense (ну или как там его) — мелочь, но неприятно.
Не прикалывало то что подсветка фильтрует следующий идентификатор согласно типа. Т.е., если я хочу написать

 iSomeVal := getString().Length;

то метод getString() не высветится, т.к. он возвращает string а не integer.
3.3. Совсем мелочь, но задолбало. Удаление пустых обработчиков.
Лично я (потеряв из-за сбоев не один кусок кода) нажимаю Ctrl+S через каждые 5-10 с. А делфи "оптимизирует" код и удаляет пустые обработчики (в т.ч. и новосозданные). А еще когда не находит какой-то контрол норовит удалить его с формы. Такое впечатление, что из формы можно удалить контрол и все будет ОК — прога запашет. Типа девелоперы могут просто так кидать контролы.
4. "Закон один для всех". В делфи часто встречаются исключения. Например writeln — чуть ли не единственная функция, куда можно передать переменное к-во параметров. А вот простым смертным — низза. Похожая ситуация с массивами.

Остальные замечания еще меньше, потому даже писать не буду.

Резюме
Спрос на любую технологию формируется с двух сторон:
1. Заказчик.
1.1. Есть уже готовач инфраструктура на некой технологии. Отсюда некоторая инертность рынка.
1.2. Есть удачный опыт работы с технологией.
1.3. Просто скзали/услышая, что эта технология — круто.
2. Программист.
2.1. Опыт работы с технологией.
2.2. Удобство.
2.3. Библиотеки.
и т.д.

именно п.2. формируется из этих многих ИМХО которые перечислены в этой ветке (сила мелочей в том, что их много). Каждая мелочь (приятная и не очень) формирует ИМХО, которое потом формирует ИМХО коллективное, а в последствии — рынок. А еще на ИМХО влияет реклама и усилия по продвижению.

Вывод

Задача IT — предоставление сервисов в других областях народного хозяйства. Потому если вы можете сделать своего заказчика счастливым на delphi — делайте, ему скорее всего абсолютно пофиг что вы используете. Коллективное ИМХО отодвинуло delphi на второй план, но это абсолютно никому не мешает использовать его в своем проекте — главное чтобы закачик был счастлив.