Хочешь оставить ссылку - предложи поделиться Телеграмм каналом в комментариях. Т.е. либо кто-то заинтересуется и спросит, либо ты можешь приглашаешь в ТГ во время обсуждения. По-моему это достаточно уместно
Дотнеченность кончилась на Delphi 8. Дальше никакого дотнета там нет, кроме нескольких инструментах в самой среде разработки. А вот развитие в целом, в последующих версиях (после 2010) года, очень ощутимо.
Скорее в опросниках не было пункта Delphi. Его "отменяют" во многих аспектах. Игнорируют, будто не существует. При этом легко могут добавить COBOL и Visual Basic. Хотя те уже годами не развиваются и не обновляются, в то время как Delphi регулярно получает обновления, как по языку, так и по инструментам.
Самые крупные компании пользуются старым софтом, написанном на древних языках программирования. Кто помнит, как мы рисовали интерфейсы на Delphi Studio? И дизайн этого софта соответствующий.
А чем язык "древний"? Древнее C++? Нет. Он даже не древнее Питона.
И "Delphi Studio" - никогда не существовало. Был Borland Delphi и сейчас RAD Studio. "Дизайн этого софта" обусловлен тем, что он изначально НАТИВНЫЙ и то, как он отображается диктует ОС.
Delphi не является старым решением и не "годится лишь на легаси". Современные версии позволяют обеспечивать нужную безопасность и быстродействие. Не говоря уже о том, что он является кроссплатформенным и позволяет создавать GUI далеко не уступающий "современному вебу".
Компилятор закрытый. Что в свою очередь говорит о том, что существует только одна IDE для этого языка. И, соответственно, для коммерческой разработки, IDE не бесплатная.
Это, всё, пожалуй, можно охарактеризовать как "не очень хорошо". Но, в России есть поставщики, и можно без проблем приобрести. Для не коммерческой разработки IDE бесплатная и имеет свою (Community) редакцию с небольшими ограничениями. При этом RTL (рантайм библиотеки) и поставляемые два GUI фреймворка (VCL и FMX) имеют "открытые исходники", т.е. мы можем в момент разработки получить к ним доступ, прочитать и даже частично изменить под себя или что-то исправить. IDE очень гибкая и имеет обширный API для плагинов, которые могут позволить встроить новые механизмы в IDE, например, Co-pilot или GPT, управлять проектом или сборкой и т.д. Открытость RTL позволяет более подробно изучить доступные методы и классы (помимо отдельной документации и встроенной в код документации), в частности понять "как работает" или "как реализовано". Т.е. штатно, библиотеками мы можем очень сильно повлиять на то, как работает язык, например, реализовать смартпоинтеры или аналог "defer" из языка Zig (недавно такой делал). Ну и существует открытая Jira для пользователей IDE, где можно завести баг или новую фичу и в течение какого-то времени получить ответ и возможно решение в грядущем патче (баги обычно правят от 3 до 4 месяцев, а фичи сильно по-разному).
Из минусов ещё то, что IDE (и компиляторы) на данный момент, может работать только под Windows. Хотя, с переходом на стандартизированный LSP, мы можем использовать, например, VS Code для написания кода. Но без дизайнеров, все же, это не сильно полезно.
Сейчас язык находится в стадии активной разработки, не смотря на то, что он вышел порядка 29 лет назад, и сильно меняется.
Ну, если говорить о Delphi, то для такого подойдёт пакет HTML Components. Там своя реализация HTML рендера и полный контроль над управлением содержимым. Вставлять можно что угодно, управлять содержимым как нужно ну и сохранять/загружать в удобном формате (или в html).
Кроссплатформа будет доступна, привязок к внешним библиотекам нет. Так что можно за 3-4 вечера соорудить клиент-серверное решение, например, используя RESTfull сервер на MARS, с авторизацией на JWT и серваком под Linux/ Windows.
Ну и выглядеть будет как любой современный веб-сервис, если нужно. Кроссплатформенный GUI фреймворк (FMX) работает на GPU.
А как ты хочешь повлиять на тот же chkdsk? Даже в прошлых версиях там было видно лишь отношение проверенных и не проверенных блоков. Это показывает как бы прогресс, но не поможет, если на каком-то из блоков будет зависание. Не говоря уже о том, что зависнуть он не сможет, будет тайм-аут.
Не говоря уже о том, что статья делает упор на пользовательский софт, где юзер даже с подробным логом не будет пытаться разобраться.
А лог, между прочим, есть почти везде. Если что-то идёт не так, в логе в любом случае подробнее, чем в строке прогресса.
Нам показывают экран с логотипом Google Docs и повторяющийся узор, который сменяет четыре фирменных цвета Google. Программа что-то делает? Пожалуй. Корректно ли она это делает? Возможно. Будет ли этот процесс завершён? Неизвестно
А что изменится, если помимо анимации загрузки будут сменять друг-друга мало говорящие надписи, да ещё и так быстро, что ты там ничего не успеешь прочитать?
Программа делает то, что ты нажал. Что именно? Список операций, чтобы выполнить задачу. Корректно ли она делает? На этот вопрос тебе не ответит даже самый подробный список операций, потому что повлиять на этот процесс ты не сможешь (даже на экране загрузки Линукса не можешь). Ты лишь ждёшь завершения операции. Будет ли этот процесс завершён? Неизвестно, как и в подробнейшем экране загрузки Линукса. Если какая-то операция зависла насмерть, ты будешь лишь видеть эту последнюю операцию и, вероятно, ждать несколько минут, прежде чем поймешь, что всё зависло (хотя, это может быть и не так). Конечно, в случае с Линуксом это полезно (видеть последнюю операцию). Т.к. ты можешь исправить этот момент, если система не загружается, но операции внутри более простых программ не поддаются подобным правкам и последний пункт, скажем, "обработка элементов там-то там-то" тебе в итоге не поможет. Поможет разработчикам, но как правило, подробный лог для разработчиков более полезен.
Я не спорю, что все долгие операции желательно сопровождать как минимум прогрессбаром, который показывал бы прогресс выполнения задачи и при этом реальный прогресс, а не просто анимацию. Но, зачастую, операции без прогрессбара не подразумевались как долгие и если практика будет показывать, что эта операция может быть долгой, то он там вероятно появится.
Anchors (якоря) появились десяток лет назад. Не говоря уже о том, что сам язык вообще никак не связан с каким-то GUI-фреймворком. Да, существуют и другие GUI фреймворки под Delphi. Там и слои разного рода и прочие вещи для компоновки есть
Нет не скриптового языка, который "заточен под веб" (или он мне даже не известен).
C-шарп (почему-то не дает вставить символ решетки) - не заточен под веб, но под него есть специальный инструмент для разработки под веб. И он достаточно популярен. Почему такого инструмента не может быть для Delphi?
Не уверен, что есть полноценные объективные статьи со сравнением. Я видел одну статью, где сравнивали в этом контексте с Flutter и Xamarin и там очень сильно чувствуется субъективность. И связана она либо с намеренным умалчиванием моментов о Delphi, либо с отсутствием опыта с Delphi у автора.
А так, могу сказать следующее о разработке на мобильные устройства на Delphi:
Есть не один, а минимум два полноценных фреймворка для создания приложения под мобилки: FMX (штатный) и FGX Native (сторонний, платный, от нашего разработчика). FMX - это полностью кроссплатформенный фреймворк под все платформы (а не только под мобилки), а в FGX - исключительно под iOS/Android. Но, у FGX есть преимущества в том, что он более узкоспециализирован, следовательно учтено больше моментов и он является нативным фреймворком, в то время как FMX использует свою отрисовку и свои контролы.
В Delphi в обеих фреймворках сохранена идея VCL, за что в своё время так полюбили Delphi. Т.е. имеется полноценный дизайнер окна, а в FMX ещё и дизайнер для представления контрола.
Об FGX в целом мало что можно сказать. Это фреймворк аналогичен VCL: дизайнер, группы контролов, мастера настройки манифеста и прочих специфичных для iOS/Android вещей
Скрины проекта FGX
В FMX же введена новая механика, позволяющая управлять представлением любого контрола. Т.е. мы имеем базовый класс "Кнопка" и можем создать кучу представлений для того, чтобы эта кнопка отображалась и/или вела себя нужным нам образом.
Скрины проекта FMX
Здесь всё построено на стандартных контролах: кнопки, слои и т.д.
Дизайнер представления (кнопки)
Этот проект в том числе под мобильные устройства
При изменении размера он подстраивается
В итоге мы имеем Rapid разработку. Строим интерфейс, пишем код в обработчики (асинхронный тоже можно, через таски), как и в обычном VCL. Должен сказать, что написать хреновое/хорошее приложение можно и на VCL и на FGX и на FMX.
При всём при этом, среда позволяет собирать, запускать и отлаживать приложение на всех этих платформах: VCL - Windows, FMX - Windows/Linux/MacOS/iOS/Android, FGX - iOS/Android. Прекрасно работает с виртуальными машинами и с WSL/WSA.
Ну и соответственно, почти все старые наработки на Delphi, которые не касаются GUI будут нормально компилироваться под другие платформы (если, конечно, нет платформозависимого кода).
То же самое
Хочешь оставить ссылку - предложи поделиться Телеграмм каналом в комментариях. Т.е. либо кто-то заинтересуется и спросит, либо ты можешь приглашаешь в ТГ во время обсуждения. По-моему это достаточно уместно
Самый быстрый способ слить карму - выразить недовольство, что тебе поставили минус на комментарий
Дотнеченность кончилась на Delphi 8. Дальше никакого дотнета там нет, кроме нескольких инструментах в самой среде разработки. А вот развитие в целом, в последующих версиях (после 2010) года, очень ощутимо.
Скорее в опросниках не было пункта Delphi. Его "отменяют" во многих аспектах. Игнорируют, будто не существует. При этом легко могут добавить COBOL и Visual Basic. Хотя те уже годами не развиваются и не обновляются, в то время как Delphi регулярно получает обновления, как по языку, так и по инструментам.
А чем язык "древний"? Древнее C++? Нет. Он даже не древнее Питона.
И "Delphi Studio" - никогда не существовало. Был Borland Delphi и сейчас RAD Studio. "Дизайн этого софта" обусловлен тем, что он изначально НАТИВНЫЙ и то, как он отображается диктует ОС.
Delphi не является старым решением и не "годится лишь на легаси". Современные версии позволяют обеспечивать нужную безопасность и быстродействие. Не говоря уже о том, что он является кроссплатформенным и позволяет создавать GUI далеко не уступающий "современному вебу".
Delphi/Pascal до 2010 года крайне востребованы. И сейчас, Delphi, остается на плаву и имеет устойчивый спрос, хоть и считается "старым".
Компилятор закрытый. Что в свою очередь говорит о том, что существует только одна IDE для этого языка. И, соответственно, для коммерческой разработки, IDE не бесплатная.
Это, всё, пожалуй, можно охарактеризовать как "не очень хорошо". Но, в России есть поставщики, и можно без проблем приобрести. Для не коммерческой разработки IDE бесплатная и имеет свою (Community) редакцию с небольшими ограничениями. При этом RTL (рантайм библиотеки) и поставляемые два GUI фреймворка (VCL и FMX) имеют "открытые исходники", т.е. мы можем в момент разработки получить к ним доступ, прочитать и даже частично изменить под себя или что-то исправить. IDE очень гибкая и имеет обширный API для плагинов, которые могут позволить встроить новые механизмы в IDE, например, Co-pilot или GPT, управлять проектом или сборкой и т.д. Открытость RTL позволяет более подробно изучить доступные методы и классы (помимо отдельной документации и встроенной в код документации), в частности понять "как работает" или "как реализовано". Т.е. штатно, библиотеками мы можем очень сильно повлиять на то, как работает язык, например, реализовать смартпоинтеры или аналог "defer" из языка Zig (недавно такой делал). Ну и существует открытая Jira для пользователей IDE, где можно завести баг или новую фичу и в течение какого-то времени получить ответ и возможно решение в грядущем патче (баги обычно правят от 3 до 4 месяцев, а фичи сильно по-разному).
Из минусов ещё то, что IDE (и компиляторы) на данный момент, может работать только под Windows. Хотя, с переходом на стандартизированный LSP, мы можем использовать, например, VS Code для написания кода. Но без дизайнеров, все же, это не сильно полезно.
Сейчас язык находится в стадии активной разработки, не смотря на то, что он вышел порядка 29 лет назад, и сильно меняется.
Ну, если говорить о Delphi, то для такого подойдёт пакет HTML Components. Там своя реализация HTML рендера и полный контроль над управлением содержимым. Вставлять можно что угодно, управлять содержимым как нужно ну и сохранять/загружать в удобном формате (или в html).
Кроссплатформа будет доступна, привязок к внешним библиотекам нет. Так что можно за 3-4 вечера соорудить клиент-серверное решение, например, используя RESTfull сервер на MARS, с авторизацией на JWT и серваком под Linux/ Windows.
Ну и выглядеть будет как любой современный веб-сервис, если нужно. Кроссплатформенный GUI фреймворк (FMX) работает на GPU.
А в каком виде редактор текста интересует? Что от него требоваться будет?
Ну, на самом деле сама IDE не является кроссплатформенной. Софт, который можно написать является, а среда - нет. К сожалению.
https://habr.com/ru/articles/465507/
SRP - это не когда у тебя один класс имеет только один метод.
А как ты хочешь повлиять на тот же chkdsk? Даже в прошлых версиях там было видно лишь отношение проверенных и не проверенных блоков. Это показывает как бы прогресс, но не поможет, если на каком-то из блоков будет зависание. Не говоря уже о том, что зависнуть он не сможет, будет тайм-аут.
Не говоря уже о том, что статья делает упор на пользовательский софт, где юзер даже с подробным логом не будет пытаться разобраться.
А лог, между прочим, есть почти везде. Если что-то идёт не так, в логе в любом случае подробнее, чем в строке прогресса.
Об этом я в комментарии написал и написал, почему это не будет полезным в обычных программах
А что изменится, если помимо анимации загрузки будут сменять друг-друга мало говорящие надписи, да ещё и так быстро, что ты там ничего не успеешь прочитать?
Программа делает то, что ты нажал. Что именно? Список операций, чтобы выполнить задачу. Корректно ли она делает? На этот вопрос тебе не ответит даже самый подробный список операций, потому что повлиять на этот процесс ты не сможешь (даже на экране загрузки Линукса не можешь). Ты лишь ждёшь завершения операции. Будет ли этот процесс завершён? Неизвестно, как и в подробнейшем экране загрузки Линукса. Если какая-то операция зависла насмерть, ты будешь лишь видеть эту последнюю операцию и, вероятно, ждать несколько минут, прежде чем поймешь, что всё зависло (хотя, это может быть и не так). Конечно, в случае с Линуксом это полезно (видеть последнюю операцию). Т.к. ты можешь исправить этот момент, если система не загружается, но операции внутри более простых программ не поддаются подобным правкам и последний пункт, скажем, "обработка элементов там-то там-то" тебе в итоге не поможет. Поможет разработчикам, но как правило, подробный лог для разработчиков более полезен.
Я не спорю, что все долгие операции желательно сопровождать как минимум прогрессбаром, который показывал бы прогресс выполнения задачи и при этом реальный прогресс, а не просто анимацию. Но, зачастую, операции без прогрессбара не подразумевались как долгие и если практика будет показывать, что эта операция может быть долгой, то он там вероятно появится.
Anchors (якоря) появились десяток лет назад. Не говоря уже о том, что сам язык вообще никак не связан с каким-то GUI-фреймворком. Да, существуют и другие GUI фреймворки под Delphi. Там и слои разного рода и прочие вещи для компоновки есть
Нет не скриптового языка, который "заточен под веб" (или он мне даже не известен).
C-шарп (почему-то не дает вставить символ решетки) - не заточен под веб, но под него есть специальный инструмент для разработки под веб. И он достаточно популярен. Почему такого инструмента не может быть для Delphi?
Не уверен, что есть полноценные объективные статьи со сравнением. Я видел одну статью, где сравнивали в этом контексте с Flutter и Xamarin и там очень сильно чувствуется субъективность. И связана она либо с намеренным умалчиванием моментов о Delphi, либо с отсутствием опыта с Delphi у автора.
А так, могу сказать следующее о разработке на мобильные устройства на Delphi:
Есть не один, а минимум два полноценных фреймворка для создания приложения под мобилки: FMX (штатный) и FGX Native (сторонний, платный, от нашего разработчика). FMX - это полностью кроссплатформенный фреймворк под все платформы (а не только под мобилки), а в FGX - исключительно под iOS/Android. Но, у FGX есть преимущества в том, что он более узкоспециализирован, следовательно учтено больше моментов и он является нативным фреймворком, в то время как FMX использует свою отрисовку и свои контролы.
В Delphi в обеих фреймворках сохранена идея VCL, за что в своё время так полюбили Delphi. Т.е. имеется полноценный дизайнер окна, а в FMX ещё и дизайнер для представления контрола.
Об FGX в целом мало что можно сказать. Это фреймворк аналогичен VCL: дизайнер, группы контролов, мастера настройки манифеста и прочих специфичных для iOS/Android вещей
Скрины проекта FGX
В FMX же введена новая механика, позволяющая управлять представлением любого контрола. Т.е. мы имеем базовый класс "Кнопка" и можем создать кучу представлений для того, чтобы эта кнопка отображалась и/или вела себя нужным нам образом.
Скрины проекта FMX
Этот проект в том числе под мобильные устройства
В итоге мы имеем Rapid разработку. Строим интерфейс, пишем код в обработчики (асинхронный тоже можно, через таски), как и в обычном VCL. Должен сказать, что написать хреновое/хорошее приложение можно и на VCL и на FGX и на FMX.
При всём при этом, среда позволяет собирать, запускать и отлаживать приложение на всех этих платформах: VCL - Windows, FMX - Windows/Linux/MacOS/iOS/Android, FGX - iOS/Android. Прекрасно работает с виртуальными машинами и с WSL/WSA.
Ну и соответственно, почти все старые наработки на Delphi, которые не касаются GUI будут нормально компилироваться под другие платформы (если, конечно, нет платформозависимого кода).
Delphi умеет создавать aab пакеты
На релиз переключитесь и включите сборку 32+64 бит
Если честно, по ощущениям особой тяжести не наблюдается. Если сравнивать, да, тяжелее, но носить и держать комфортно