Меня привлекло именно то, что я мог делать полноценную программу. С окном и элементами управления. У нас сами уроки были скучные, но я делал задачи сам с окнами. С вводом вместо консоли
Что есть число, а есть строка?? Серьёзно? Никто ведь не будет требовать в начале обучения использовать "подходящие" по точности типы. Не говоря уже о том, что в Делфи тоже есть выведение типов и тип писать не обязательно
И да, так почти со всем кодом, за исключением того, что если объект создавался (и он не интерфейсный), его нужно вручную освободить.
Помимо того, что код на Delphi (Pascal) мало отличается (особенно на начальном уровне) от C#, из коробки ты соберешь его под Android или свой iOS. При этом визуально помогая себе программировать.
Дети могут экспериментировать, менять свойства, потому что их видно. Создавать инструменты для себя и не бояться передавать их другим, потому что нет зависимостей. И т.д. А если снабдить среду разработки компонентами для обучения, то можно целые курсы реализовать без строк кода, как в Scratch.
У нас клиенты и rest сервер на Делфи, с кешированием и прочим. При этом, использование хранимых процедур сильно повышают скорость выполнения сложных, комплексных запросов. Потому что не нужно гонять данные между сервером и бд.
Сколько нужно в ИТ разработчиков, занимающихся анализом данных, обучением моделей ИИ или описывающих модели ИИ? Или может все вокруг только веб разработчики пишущие бэкенд?
Помимо вышеперечисленных областей есть: десктоп разработка, мобильная разработка, разработка для IoT, высоко нагруженные системы, разработка игр, сложных CRM, middleware систем, низкоуровневых систем и много, много другого, где питон принимает минимальное участие или вообще не может использоваться.
А полноценное создание/редактирование форм через код с полной интеграцией этого процесса в среде разработки. И этого в Delphi нет
Редактор есть, пиши. Нет функций - запроси. Никто не требовал их, их не создали
В WPF также можно сделать все с нуля только в дизайнере.
Нет нельзя, те же бинды там делаются исключительно в xaml
Сравниваем: надо поменять title у компонента. В редакторе коде просто переходим на нужную позицию в тексте и пишем новый. В дизайнере надо вначале перейти в дизайнер если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новый. Просто даже по количеству действий второй подход уже проигрывает.
Как хитро вы завернули "переходим на нужную позицию в тексте". А сколько там шагов при большой форме?
В Делфи - это. Ткнул на форму, вписал название. Тем более, что даже в свойства заходить не надо, можно нажать ПКМ и изменить значение основных полей.
Перевожу ваш "короткий путь" в реальный: В xaml надо вначале перейти в xaml если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новое значение.
А вот поиск нужного компонента в тексте куда дольше, чем поиск его на форме, прям перед глазами. Ты его видишь вот прямо сразу.
Всё это, потому что никто в здравом уме не будет лезть в текстовый режим формы. В этом нет никакого смысла. Если вы в WPF не можете всё сделать в дизайнере, то в Delphi абсолютно всё можно сделать в дизайнере. От и до. Не говоря уже о том, что в FMX два дизайнера (для формы и для представления (стиля)).
Именно по этому никто не запрашивает проверки ошибок или подсказки. Возможность зайти и что-то исправить текстом - есть, а больше ничего не нужно. Всё, абсолютно всё, можно сделать в дизайнере и сделать это на порядок быстрее. И всё работает в дизайнтайм, в отличие от WPF (даже биндинги, они тут тоже есть и работают "на горячую").
Биндинги есть и для датасетов и списков, и между моделями данных и контролами, и между датасетами и контролами (другими словами можно что угодно с чем угодно связать)
Перестали её развивать почти сразу как выпустили. Вероятно, тогда GUI для Linux были не так нужны, как сейчас, особенно под гнетом того, что Винду то тут, то там отменяют. Библиотека опередила своё время, к сожалению.
Да, тут привыкать нужно, потому что перемещение каретки тоже считается изменением редактора и может быть отменено. Когда привыкнешь - наоборот удобнее становится. Видишь как скакал, как изучал код.
С форматированием могут быть какие-то косяки, его не особо правили после крупных изменений в языке (инлайн, вывод типов, анонимки и т.д.)
Но над IDE очень усердно работают в последнее время. И даже я, часто замечаю, что ту или иную вещь действительно поправили. Кстати, именно текущая бета версия, которая тестируется, является обновлением с уклоном на "правки и улучшения" в IDE.
Мобильные приложения, кстати, на Delphi создаются быстрее, чем на Kotlin. И для мобильных приложений в Delphi имеется два фреймворка: штатный фреймворк FMX (о котором статья), не нативный (может быть частично нативным) и FGX Native отдельный, специально разработанный для создания мобильных приложений.
Из чего угодно можно сделать ужасный урок)
Меня привлекло именно то, что я мог делать полноценную программу. С окном и элементами управления. У нас сами уроки были скучные, но я делал задачи сам с окнами. С вводом вместо консоли
Не программирование, но это то, что может привлечь ребенка. Создание чего-то "осязаемого", а не просто какого-то текста.
Что есть число, а есть строка?? Серьёзно? Никто ведь не будет требовать в начале обучения использовать "подходящие" по точности типы. Не говоря уже о том, что в Делфи тоже есть выведение типов и тип писать не обязательно
Не плюс. Подводные камни - это дополнительные условия и нюансы конкретного языка. Для обучения программирования в общем смысле - это минус
О супер, если приходится искать контрол через регулярки - то очевидно, инструмент так себе
C#
Delphi
И да, так почти со всем кодом, за исключением того, что если объект создавался (и он не интерфейсный), его нужно вручную освободить.
Помимо того, что код на Delphi (Pascal) мало отличается (особенно на начальном уровне) от C#, из коробки ты соберешь его под Android или свой iOS. При этом визуально помогая себе программировать.
Дети могут экспериментировать, менять свойства, потому что их видно. Создавать инструменты для себя и не бояться передавать их другим, потому что нет зависимостей. И т.д. А если снабдить среду разработки компонентами для обучения, то можно целые курсы реализовать без строк кода, как в Scratch.
Не дороже использования Qt или VS для коммерческой разработки.
Без сложных переделок получится конвертировать, если в проекте используются только штатные компоненты и контролы.
Ну и любой платформонезависимый код нужно будет переписать под кроссплатформу.
В современном Делфи сильно расширили RTL, в том числе для возможности создавать кроссплатформенный код.
У нас клиенты и rest сервер на Делфи, с кешированием и прочим. При этом, использование хранимых процедур сильно повышают скорость выполнения сложных, комплексных запросов. Потому что не нужно гонять данные между сервером и бд.
Сколько нужно в ИТ разработчиков, занимающихся анализом данных, обучением моделей ИИ или описывающих модели ИИ? Или может все вокруг только веб разработчики пишущие бэкенд?
Помимо вышеперечисленных областей есть: десктоп разработка, мобильная разработка, разработка для IoT, высоко нагруженные системы, разработка игр, сложных CRM, middleware систем, низкоуровневых систем и много, много другого, где питон принимает минимальное участие или вообще не может использоваться.
Ооо, замечательное окно. И где удобнее? В RAD или в VS? А поиск компонента по названию, уж смешно) Он и в дизайнере есть
Редактор есть, пиши. Нет функций - запроси. Никто не требовал их, их не создали
Нет нельзя, те же бинды там делаются исключительно в xaml
Как хитро вы завернули "переходим на нужную позицию в тексте". А сколько там шагов при большой форме?
В Делфи - это. Ткнул на форму, вписал название. Тем более, что даже в свойства заходить не надо, можно нажать ПКМ и изменить значение основных полей.
Перевожу ваш "короткий путь" в реальный:
В xaml надо вначале перейти в xaml если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новое значение.
А вот поиск нужного компонента в тексте куда дольше, чем поиск его на форме, прям перед глазами. Ты его видишь вот прямо сразу.
Всё это, потому что никто в здравом уме не будет лезть в текстовый режим формы. В этом нет никакого смысла. Если вы в WPF не можете всё сделать в дизайнере, то в Delphi абсолютно всё можно сделать в дизайнере. От и до. Не говоря уже о том, что в FMX два дизайнера (для формы и для представления (стиля)).
Именно по этому никто не запрашивает проверки ошибок или подсказки. Возможность зайти и что-то исправить текстом - есть, а больше ничего не нужно. Всё, абсолютно всё, можно сделать в дизайнере и сделать это на порядок быстрее. И всё работает в дизайнтайм, в отличие от WPF (даже биндинги, они тут тоже есть и работают "на горячую").
Биндинги есть и для датасетов и списков, и между моделями данных и контролами, и между датасетами и контролами (другими словами можно что угодно с чем угодно связать)
Перестали её развивать почти сразу как выпустили. Вероятно, тогда GUI для Linux были не так нужны, как сейчас, особенно под гнетом того, что Винду то тут, то там отменяют. Библиотека опередила своё время, к сожалению.
Да, тут привыкать нужно, потому что перемещение каретки тоже считается изменением редактора и может быть отменено. Когда привыкнешь - наоборот удобнее становится. Видишь как скакал, как изучал код.
С форматированием могут быть какие-то косяки, его не особо правили после крупных изменений в языке (инлайн, вывод типов, анонимки и т.д.)
Но над IDE очень усердно работают в последнее время. И даже я, часто замечаю, что ту или иную вещь действительно поправили. Кстати, именно текущая бета версия, которая тестируется, является обновлением с уклоном на "правки и улучшения" в IDE.
Если про FGX, то можно тут посмотреть, я думаю, а если FMX, то, например, вот это под мобильные платформы в том числе
Мобильные приложения, кстати, на Delphi создаются быстрее, чем на Kotlin. И для мобильных приложений в Delphi имеется два фреймворка: штатный фреймворк FMX (о котором статья), не нативный (может быть частично нативным) и FGX Native отдельный, специально разработанный для создания мобильных приложений.
ActiveX, ole доступ не поменялся. А если и поменялся (что-то добавилось), то это автоматически будет доступно даже на старом Делфи 7.
Тут важнее вопрос "зачем ole?" Тем более, что в Линукс его нет.
Редактировать docx файлы в Делфи, в современном, можно и без ole, библиотеки есть на github
Их ещё много, но я устал писать с телефона
Некогда ему умирать. Да и регулярные обновления, вебинары, нововведения и прочее, не дают.