платформой разработки. Был софт на delphi 7, для сеошников, от платформы требовались качественные готовые компоненты/библиотеки для запросов в веб, для разбора html, ну и какого-то простенького NLP - аналог pymorphy, для вычленения полезного контента со страницы - аналога boilerpipe и т.д. Софт во всем уступал конкурентам и был закономерно похоронен рынком) По сути его востребованность ограничилась только периодом расцвета ныне почившего SEO, когда еще не было более развитых конкурентов в лице веб-сервисов. Из косяков, которые все еще помню, навскидку:
1) Библиотека для http запросов - indy v9 - была очень сырой. Фактически её пришлось форкать и допиливать, но периодически всплывали глюки. Пока конкуренты тестили и пилили новый полезный функционал и улучшали UX, мы разбирались, почему же эта ср*ная библиотека не хочет посылать cookies, которые ей пришли в предыдущем ответе, или неадекватно реагирует на редирект. Вообщем, чего-то удобного, сравнимого с питоновским requests, тогда в делфи не было, да и сейчас вряд ли завезли. Да вот даже реализацию JSON wire protocol для скраппинга через selenium все еще не завезли)) https://stackoverflow.com/questions/41899371/is-it-possible-to-use-selenium-web-driver-with-delphi - инфа на 2017 год
2) Библиотек для корректного парсинга невалидного html (сравнимого по качеству с питоновским lxml.html) и обработки xpath-запросов тоже в свое время не нашли. Собственно последнее из того, что делали, перед тем как я оттуда уволился, был переход на врапперы сишных библиотек curl и libxml2. Но я сомневаюсь что его все-таки доделали до того как проект окончательно загнулся, т.к. для этого надо было переписать около 80% кода - очень сильно завязались на интерфейсы глючного TIdHTTP. Кстати даже на 10 версию indy перейти было проблематично, из-за того что у неё интерфейс оказался не обратно совместимым.
3) Низкая культура разработки программистов на делфи у большинства программистов - софт пилился по сути джуниорами, вчерашними выпускниками вуза, одним из которых на тот момент был я) Платформа очень провоцирует на антипаттерны - например, обработчикам событий даются по умолчанию анонимные имена типа Button100500_Click(), которые ленивые программисты потом не хотят править. Алсо в 7 версии не было дженериков (притом что в c++ они уже давно были), поэтому ассоциативные массивы делались через одно место - через сериализацию нестроковых данных в строку, сохранением в StringList и парсингом обратно. Да и к слову, реализовывать какую-либо логику в обработчиках неправильно, надо её враппить в свои классы. Но никто этого не делал, в результате привязались к легаси компонентам и не могли перейти на более современную версию делфи, поддерживающую юникод, променять кривой VCL на FireMonkey (хотя уровень кривизны последнего замерить не довелось, поверим на слово маркетологам embarcadero). С системами контроля версий отдельная боль была - IDE очень любила править что-то в dfm-файлах при малейшем открытии формы в редакторе, алсо требовалось хранить бинарный .res-файл в репозитории, что само по себе плохая идея и чревато corrupt'ом. Юнит-тесты - их вообще кто-то пишет на делфи? Ни в одной библиотеке, которую использовали, не находили тестов) Тоже показатель культуры кода. Чтобы написать враппер сишной библиотеки, делфи разработчику надо еще знать си. В то же время очень маловероятно, что программисту на c/c++ придется интегрироваться с библиотекой, реализованной только на delphi и не имеющей аналогов.
7 версия - это середина 90х годов, о чем вообще речь? тогда и у плюсов стандарта не было. Что же касается хороших разработчиков - множество сеньоров когда-то начинало на дельфе. Я бы даже сказал, что сейчас опыт работы на дельфи - не минус, а плюс. Но что до новых проектов на дельфе - это смешно, дельфи труп и живет только за счет старых проектов, переписать которых выйдет дороже.
Обсуждают сегодня