![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
"С быстрым компилятором workflow намного более гладкий"
У меня на тему популярности Delphi и Firebird на постсоветском пространстве была такая мысль: простота языка и среды и большая скорость компиляции в дельфях, а так же удобство использования Firebird при разработке привели к тому, что одного среднего программиста было достаточно для реализации достаточно приличного размера проектов (ну там 150-200 kloc - это вот типичное, во что можно уместить неплохую опердень).
И это сыграло злую шутку - без работы в команде (за отсутствием оной) и контактов с внешним миром в стиле "опять не пойми чего наделали в 100501-й библиотеке на Ц++/рубигеме/надо новый буст" люди окукливались и начинали варится в собственном соку, не использовать контроль версий и игнорировать регресс разработки и продажи софта до состояния "надо бежать, чтобы оставаться на месте". А потом херак - и восьмые винды, вижуалстудии, корявые линуксы с корявыми методиками деплоймента и пакетными менеджерами, жабы с мавенами, гит, андроиды с корявыми SDK и прочее разложение, а мозг то привык к удобству работы.
И это сыграло злую шутку - без работы в команде (за отсутствием оной) и контактов с внешним миром в стиле "опять не пойми чего наделали в 100501-й библиотеке на Ц++/рубигеме/надо новый буст" люди окукливались и начинали варится в собственном соку, не использовать контроль версий и игнорировать регресс разработки и продажи софта до состояния "надо бежать, чтобы оставаться на месте". А потом херак - и восьмые винды, вижуалстудии, корявые линуксы с корявыми методиками деплоймента и пакетными менеджерами, жабы с мавенами, гит, андроиды с корявыми SDK и прочее разложение, а мозг то привык к удобству работы.
no subject
Охреневают даже от показа демо-приложения "Рыбки" из 1995 года. Типа, как-так - работающая с БД программа без строчки кода. Где паттерны, где вью-контроллер, где, @ля, проекция на классы?
no subject
Это конечно огромный, но единcтвенный плюс.
Охреневают даже от показа демо-приложения "Рыбки" из 1995 года. Типа, как-так - работающая с БД программа без строчки кода. Где паттерны, где вью-контроллер, где, @ля, проекция на классы?
Еще больше они охренеют, когда захотят с этим работать. Вот тогда они захотят обратно и проекцию на классы и все остальное.
И кстати на заметку - дельфи ДАЛЕКО не единственная платформа, где мышкой можно создать приложение, мышкой накликать связи с бд, мышкой создать интерфейс и т.п. И мне кажется, в этом нет ничего хорошего, что вместо того, чтобы учить SQL или фрейиворки студенты учатся такому мышкопрограммированию.
no subject
А вот изучение монстроидальных фреймворков вместо теоретических основ и их практических реализаций как раз и плодит нынешних "программистов".
Да, в Дельфи можно накликать мышкой и трехзвенку, и веб-приложение, и службу.
80% программистам, пишущих заказной код для автоматизации предприятий как раз.
Фишка в том, что дельфи может и так и эдак. В продуктовом софтостроении дизайн-тайм мало используется, но там и квалификации другие.
И таки хорошо, что большинство компонентокидателей уплыло с дельфей еще в начале 2000-х.
no subject
Так в том то все и дело, что не надо :(
Даже в стандартных компонентах, когда можно только выбирать таблицы и потом подключать датасорцы к гридам. Также и лукап-поля настраиваются. Это не говоря уже о таких продвинутых вещах как FIBPlus.
no subject
no subject
Все эти ORM и прочая жабовщина нужна сугубо для сложной бизнес-логики, для косячных языков со статик типами без метапрограммирования и в случае редко изменямой схемы БД.
Для отображения и простой обработки даже в статически типизированных языка типа жабы или c# лучше использовать динамическую типизацию в виде датасетов, последовательностей хэш мапов и прочего такого. Или сразу языки с динамической типизацией. В итоге, для веб-приложений все равно придется json отдавать фронт-енду.
no subject
коими дельфи также и является
Для отображения и простой обработки
простые программы, это миф - вам ли не знать. Все программы поначалу простые, а потом сложность нарастает как снежный ком и уже ORM не кажется такой избыточной.
no subject
Я вот тут еще подумал, про динамические языки. Ну предположим поле поменялось. В статически типизированном языке придется везде рефакторить, иначе оно компилироваться перестанет. В динамически типизированном приложение скомпилируется, запустится и упадет уже в течение работы приложения, что намного хуже. Остается только надеяться на юнит-тесты, но их надо тогда писать на любой чих, что не совсем интересно.
no subject
Если это поле используется для вычислений и наличие его значения обязательно - да, статик типы сразу становятся лучше - проблемы детектируются на этапе компиляции. Для этого я использую кодогенерацию из моделей и БД и ORM и классов.
Если значение поля используется для вычислений, но наличие значения не обязательно и есть разумное значение "по умолчанию" - то лучше его сразу использовать в стиле fieldValue = resultset.GetField("name", defaultValue) + опциональный warn в логи на отсутствие поля. Т.е. динамические типы (== ассоциативные массивы, хэш-мапы и самодельные dynamic в дотнете). И прочие null/Option/Maybe и fromMaybe.
Если же все назначение поля - это протащить его от запроса до сериализации в JSON или показа в гриде - то можно вообще изменения игнорировать, а проблемы если и будут на стороне фронт-енда, то они не критичны. Если делать аккуратно - любые проблемы фронтенда не должны приводить к повреждению состояния БД и бизнес-логики на бэк-енде. Пользователи сами сообщат, что поля не видят, или что вместо поля видят надпись "field 'Worm' not found".
А делать софт, который всерьез сломается от мелочей вида "пользователь увидел корявое сообщение" или "от пользователя не пришло значение поля" - паук не велит. Т.к. от сторонних инфраструктурных косяков статик типы не защищают и проблемы с внешней по отношению к нашему софту дурью всегда будут, от этого надо защищаться или уметь переживать.
А чтобы защитится от проблем вида "изменили поле" с помощью статик типов полноценно - это нужен вывод типов в рантайме, т.е. подключаемся к БД - загружаем метаданные всех запросов, выводим типы и ругаемся юзеру, в логи и разработчику в мониторинг, если что не так. Ни один современный язык этого не умеет, поэтому можно не дергаться :)