А вы знаете лично живых программистов на Embarcadero RAD Studio C++ Builder?

я как-то удивился, что оно ещё в ходу, или это норма?

В 90-е на Delphi и Builder была написана просто тонна ПО. И поддерживать и развивать его приходится до сих пор.

Кстати, им оказывается 25 лет недавно исполнилось, они статью на русском написали: https://blogs.embarcadero.com/ru/the-cbuilder-25th-anniversary-visual-development-the-power-of-the-c-language-and-2-5-decades-of-continuing-excellence/

Она у тебя перед носом, ты в неё этот срач прям сейчас пишешь.

увы, у меня есть такие волшебные панели, на которых верстка ползет :(

и таки да, чтобы «там» работало, прибили гвоздями. но теперь у разраба все хреново выглядит.

увы, у меня есть такие волшебные панели, на которых верстка ползет :(

Ну тут как сверстали так и ползёт. Никто же не мешает верстать в тех же абс. координатах в вебчике. С другой стороны только тут что-то и двигается по адаптивной вёрстке и всему остальному. И опыта/иструметария для вебчика в этом плане несоизмеримо больше, чем у всех формошлёпов, да так, что те на всё забивают и просто реализуют какое-нибудь подмножество цсс.
Я как бы понимаю, что мы все немного старпёрем и всё считаем говном, кроме того, на чём работаем, но даже такому консервативному челу как я, уже начинает быть понятно, что рядом с вебчиком, электроном и жсом всё остальное начинает посасывать. Ну серьёзно, это факт. Тут надо не ныть про то, что электрон говно, а искать/пилить какой-то лёгкий электрон (типа нейтрино. Будет тяжело, лол).

под один единственный размер как на компе у разраба

Это проблема не wysiwyg, а конкретных реализаций или даже дефолтов этих реализаций.

чтобы ничего не разъезжалось и складывалось на маленьком экране как надо

В суровой действительности сайты без отдельной мобильной версии на телефоне часто максимум условно-юзабельны и выглядят как какашка. Я когда-то вынужден был пользоваться яндекс-картами через браузер на телефоне - спасибо, пусть лучше «как в дельфи» чем это. Было бы всё няшно и гладко в любой реализации, массовый пользователь не укатился бы в мобильные приложения.

Ну, и я знаю. И что? Когда «специалистов в предметной области» очень уважаемых людей сажают пограммировать, что тут сделаешь? Только на ЛОР-е трындеть дартаньяны могут, а на деле. Нужно связь с их ПО сделать, вчера. А от них - только библиотэка+закрытый шифрованный протокол. Иди, выполняй, тыж погроммист.

Это проблема не wysiwyg, а конкретных реализаций или даже дефолтов этих реализаций.

Декларативная хрень не делается wysiwyg. В принципе не делается. Нет смысла. Декларация - это структура данных. Типа можно и sql делать wysiwyg методом, но это - бессмысленно. Потому что нормальная декларативная модель тупо не выражается вузивугом.

В суровой действительности сайты без отдельной мобильной версии на телефоне часто максимум условно-юзабельны и выглядят как какашка.

Между говном и технической невозможностью использовать, всё таки лучше - говно. У нас вон, кто-то просто не смог, потому что оно не влезло.

все херачат на абс. координатах.

О чем я и написал, не умеют готовить.

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

Ну что значит «практик». Седьмой Delphi не умел в локализацию из коробки. Вот тебе и вся «практика». Юникода в сорцах нет, юникода в декларациях форм нету. Что ты сделаешь с полностью однобайтовой программой? Единственное, что можно сделать — это запустить ее на правильной системной кодировке.

Когда я пришел работать тут мне неделю ставили компоненты, чтобы их проект начал собираться.

Встречается такая болезнь, вместо того что бы написать три строчки кода, не включая мозг начитают искать готовые компоненты.

Кроме того, в говновебе сорцы есть by design

С какого ещё «by design» ?

Корпоративное ПО пишется строго под определенное разрешение.

Неправда ваша.

Помню это говно, в то время это было передовое решение, а сейчас фишки VCL есть вообще во всех платформах и фреймворках

Что ты несёшь, зумерок? Дудя опять пересмотрел?

У говновеба есть важное приемущество и перед кутэ, и перед дельфи. его не надо деплоить, он работает на всех ОС одинаково, в говновебе не надо делать прямого подключения к бд, сношаться с пробрасыванием впн у клиентах и вообще высовывать жопу своей субд куда-то в окно.

Wordpress + noVNC + «терминальный» VNC сервер?

По сути server side Blazor IMHO похож на VNС и даже X2GO, разница лишь в том, что для прорисовки на клиенте он передает дифы DHTML, а не спрайтов или векторов?

В говновебе хттп by design вместо дрочки бд, трехзвенка с возможностью нормально сделать кэширование и логику/микросервисы/что душе угодно, вместо безальетранивной двузвенки с обоссанными вложенками в субд

Какая связь между multi-tier и видом используемого GUI?

Нормальные пацаны давно уже делают многозвенки, которые не зависят от типа GUI и при желании переключают GUI Web/Desktop одним нажатием кнопки, ничего не меняя в бизнес логике и более низких слоях приложений:

https://cslanet.com/

https://docs.devexpress.com/eXpressAppFramework/112559/overview/architecture

и, вишенкой на торте, уродывание схемы данных под сраные гриды и под корявые вложенки, потому что мы по-другому не умеем.

Что за вложенки? Хранимые процедуры? Какая связь между способом реализации BL и data-tier и выбором типа GUI?

Кроме того, в говновебе сорцы есть by design и надо прикладывать усилия, чтобы их порсрать. Чтобы просрать сорцы в дельфи формочках усилий не надо, они сами просираются вместе с исполнителем.

Сорцы у десктопных приложений для Git и архивных систем имеют какие-то кардинальные отличия? Отсутствие репозитариев с пакетным менеджером? Но в мире .NET все это ДА, есть :)

Херова гора компонентов, которые притащили в нулевых, авторы которых умерли ...

Какая-то маниакальная страсть к описанию медицинских последствий использования нежелательного кое кому софта? Что первично, а что вторично? Или это новый способ устранения конкурентов и нежелательных путей развития тех или иных технологий? Запрещенная наука? Что там произошло с автором запрещенного языка программирования Perl ?

А там что? Бинарники? Нет, там сорцы скриптов. Если их специально не изпоганили.

Нормальные пацаны

Давно ты видел нормальных пацанов в этом сегменте?

Нормальные пацаны давно уже делают многозвенки, которые не зависят от типа GUI

Тогда оно и нахрен не нужно, если есть нормальные пацаны, которые стоят столько же, сколько пацаны способные написать нормальную вебню. На хой хер тебе два гуя? Чтобы 2 раза сопровождать одно и тоже? Денег деть некуда?

Что за вложенки? Хранимые процедуры? Какая связь между способом реализации BL и data-tier и выбором типа GUI?

Прямая. Потому что так там заведено и никто ничего делать по-другому не будет. А приделать можно хоть вебсокеты. Но их никто приделывать не будет, потому что это велик и убивает всю суть рад. Тоже самое можно сделать в вебчике быстрее и проще.

Сорцы у десктопных приложений для Git

Я прекрасно помню, как пытался объяснить одному дельфисту что такое этот ваш гит и каким идиотом я себя при этом чувствоал. Ты н е понимаешь суть рада. Рад - это херак-херак и в продакшон. Какие-то там гит? Что-то сидеть проектировать, программировать? Никому это не надо. Хорошо программировать лучше без рада и без дельфи. Всё это делали не за этим.

Какая-то маниакальная страсть к описанию медицинских последствий использования нежелательного кое кому софта?

Просто мужики которые рвались через дельфи поделки в гейтсы уже тогда были не молодыми пацанами. Никто не вечен, такие дела.

Что там произошло с автором запрещенного языка программирования Perl ?

Вот не упоминай перл рядом с этим говном. Там комунити - какие-никакие инженеры, это опенсорц и все дела. Если кто-то из разрабов помрет - сорцы есть, их берет другой разраб и пляшем дальше.

Да не то, чтобы как нодеры, там нормальные компоненты типа нужные. Но пм нет, сорцы закрытые, лицензии, приракти, keygen разблокируйте венду и вот это всё.

Тогда оно и нахрен не нужно, если есть нормальные пацаны, которые стоят столько же, сколько пацаны способные написать нормальную вебню.

Так веб чем-то лучше чтоли? Зачем написать веб, когда нормальные пацаны могут десктоп ? :)

На хой хер тебе два гуя?

Например, один для паблик клиентов может работать в веб, а другой для своих в десктоп варианте.

Чтобы 2 раза сопровождать одно и тоже? Денег деть некуда?

Сопровождение только GUI, а не всей системы в целом, так много стоит?

Прямая. Потому что так там заведено и никто ничего делать по-другому не будет. А приделать можно хоть вебсокеты. Но их никто приделывать не будет, потому что это велик и убивает всю суть рад.

Каким местом хранимые процедуры вредят RAD? Разве модель данных вместе с хранимками (только для оптимизации типовых RAD кейсов) не может кастом генерироваться автоматически на базе бизнес модели приложения?

Я прекрасно помню, как пытался объяснить одному дельфисту что такое этот ваш гит и каким идиотом я себя при этом чувствоал.

Нет в природе программистов, применяющих хотя бы Lazarus, и умеющих пользоваться Github? Зайди ка в пасквилянтский чатег дельфинистов. Посмотрим, что они о тебе там подумают.

Вероятно, для любого ЯП можно найти любителя, кто не знает про системы VCS.

Ты н е понимаешь суть рада.

Да где мне, LOL

Рад - это херак-херак и в продакшон.

Необязательно в продакшин, можно и в сборочный пайплайн.

Какие-то там гит? Что-то сидеть проектировать, программировать? Никому это не надо. Хорошо программировать лучше без рада и без дельфи. Всё это делали не за этим.

RAD - это не только Delphi и не только рисовалки формочек. И что плохого в рисовалках, если можно одну и ту же форму представить и в конструкторе и в декларативном редакторе?

https://docs.avaloniaui.net/docs/getting-started/ide-support

Никто не вечен, такие дела.

Лишь бы никто им не «помогал» в этом направлении.

Так веб чем-то лучше чтоли? Зачем написать веб, когда нормальные пацаны могут десктоп ? :)

Если есть нормальные пацаны то тупо нет смысла вкладываться в дохлый десктоп на дельфи, пилить там велики и решать проблемы, которые уже 100 раз решены.

Например, один для паблик клиентов может работать в веб, а другой для своих в десктоп варианте.

А почему не сделать всё в вебе для внутр. использования и для внешнего? Зачем делать 2 раза одно и тоже, причём на разных технологических базах?

Сопровождение только GUI, а не всей системы в целом, так много стоит?

Оно просто что-то стоит. Чем больше система тем больше оно стоит и больше с этим головняка.

Каким местом хранимые процедуры вредят RAD?

А где тезис о том что хранимки вредят rad?

Разве модель данных вместе с хранимками (только для оптимизации типовых RAD кейсов) не может кастом генерироваться автоматически на базе бизнес модели приложения?

Если бы всё могло генерироваться автоматически и все кейсы были типовыми программисты бы уже нахер не были бы нужны. Но оттого рад и сосёт, потому что кейсы вроде бы и типовые, но есть нюанс.

Зайди ка в пасквилянтский чатег дельфинистов.

Целый отдел дельфистов, которые ни в каких чатах не сидят. В других местах, поверь, дельфисты не лучше. Про гит, хоть некоторые и знают, но кто им пользуется. Каждый пилит свою предметку и между собой они не пересекаются, типа зачем нужен гит, да? Админы сорцы же бекапят, а так по разработке - всё нормально. Если завтра он словит шифровальщик, мы можем остаться без сорцев. Про ci/cd там никто не слышал, вот и думай.

И что плохого в рисовалках, если можно одну и ту же форму представить и в конструкторе и в декларативном редакторе?

То, что если можно сделать декларативно, рад не нужен, потому что ты уже сделал её декларативно, зачем тебе её еще раз рисовать? А если ты её сначала нарисовал, то нарисовал ты говно, потому твои рисовалки будут просто жалким подмножеством декларативной реализации, которую проектанты твоего рад натужились высрать. Причём сами проектанты будут на 100% с этим согласны. В декларативных вещах есть классы, селекторы и пр. абстракции, которые не выражаются рисовалкой. Все это сведётся в лучшем случае к буквально написанию каого-нибудь цсс мышкой.

https://docs.avaloniaui.net/docs/getting-started/ide-support
d:DesignWidth=«800» d:DesignHeight=«450»

Ты постишь ссылки на говнину и даже не понимаешь в чем дело. Вебщики все это уже по 100 раз перетёрли, прохавали и придумали что с этим делать. А с такими поделками ты будешь жрать говно, которые другие уже поели. Просто худший сценарий.

Если есть нормальные пацаны то тупо нет смысла вкладываться в дохлый десктоп на дельфи, пилить там велики и решать проблемы, которые уже 100 раз решены.

А причем тут Delphi, по крайне мере VCL? Я тебе уже намекал на .NET WinForms и Avalonia. Кстати по словам дельфинистов современный FMX в отдельных случаях может быть даже поинтереснее WPF и Avalonia.

А почему не сделать всё в вебе для внутр. использования и для внешнего? Зачем делать 2 раза одно и тоже, причём на разных технологических базах?

1) Потому что программирование под Desktop с использованием DevExpress все же обеспечивает более богатый user experience.

2) Обычно не одно и тоже, а разные формы разных частей системы поверх ядра BL, например на базе CSLA.NET. Но для своих тоже можно сделать и более лайтовый вариант в веб для мобильных пользователей. А десктопный вариант - это для офисных или домашних юзеров, - тяжелая артилерия, позволяющая получить максимум продуктивности от их кнопкодавста.

Оно просто что-то стоит. Чем больше система тем больше оно стоит и больше с этим головняка.

Сомневаюсь, что десктопный ЛК для своих штатных сотрудников и веб ЛК для паблик клиентов в поддержке затратнее, чем оба веб варианта. Потому что там и так нужно поддерживать отдельно своих и отдельно паблик - это разные формы, разные сущности, разные ответы на вопросы даже в случае веб+веб.

А где тезис о том что хранимки вредят rad?

Вероятно, это:

Но их никто приделывать не будет, потому что это велик и убивает всю суть рад.

?

Если бы всё могло генерироваться автоматически и все кейсы были типовыми программисты бы уже нахер не были бы нужны. Но оттого рад и сосёт, потому что кейсы вроде бы и типовые, но есть нюанс.

Так не все, почитай про XAF RAD насколько он кастомизируемый, сохраняя при этом ООП расширяемость для программистов. И отзывы реальных пользователей про ускорение формошлепства для типовых учетных систем до 50 раз.

Целый отдел дельфистов, которые ни в каких чатах не сидят. В других местах, поверь, дельфисты не лучше. Про гит, хоть некоторые и знают, но кто им пользуется. Каждый пилит свою предметку и между собой они не пересекаются, типа зачем нужен гит, да? Админы сорцы же бекапят, а так по разработке - всё нормально.

Ленивые старперы?

Если завтра он словит шифровальщик, мы можем остаться без сорцев. Про ci/cd там никто не слышал, вот и думай.

Идеальные разработчики по методе DevOps CI/CD словить шифровальщик не могут?

То, что если можно сделать декларативно, рад не нужен, потому что ты уже сделал её декларативно, зачем тебе её еще раз рисовать? А если ты её сначала нарисовал, то нарисовал ты говно, потому твои рисовалки будут просто жалким подмножеством декларативной реализации, которую проектанты твоего рад натужились высрать. Причём сами проектанты будут на 100% с этим согласны. В декларативных вещах есть классы, селекторы и пр. абстракции, которые не выражаются рисовалкой. Все это сведётся в лучшем случае к буквально написанию каого-нибудь цсс мышкой.

Так значит проблема в разработчиках дизайнеров, а не в концепции дуального (XAML vs дизайнер) подхода к решению вопроса формошлепства?

Еще ты упоминал про преимущество деплоя через веб, отчасти можно согласиться, если у пользователя тонкий клиент и/или нет возможности устанавливать приложения из-за различных касперов в самых жестких режимах защиты и т.п. Тогда пользователь может использовать только браузер.

Но как я уже упоминал десктопное приложение можно деплоить точно также через веб страничку с noVNC -> терминальный сервер VNC, где крутятся десктопные проги под Linux.

Здесь тебе все преимущества типового веб приложения: простой деплой, отсутствие необходимости настройки подключений и проброса портов по VPN к следующему Tier типа сервера приложений либо сразу СУБД и т.п. Но если серьезно относиться к безопасности, то я бы поостерегся ходить с обычных веб браузеров для безопасной работы в ЛК своих штатных работников даже по TLS v1.3. В таком случае все же лучше использовать какой-то более безопасный VPN с аппаратными криптоключами на обоих концах туннеля хотя бы типа SSH.

Кроме того ничто не мешает обычному десктопному приложению использовать HTTP(S) для связи со своим сервером приложений и даже не поверишь, автоматически обновлять свою версию при запуске, аналогично тому, как веб браузер каждый раз скачивает мегабайты HTML и JavaScript кода при обновлении их на сервере.

Ты постишь ссылки на говнину

Почему говнину?

и даже не понимаешь в чем дело.

На основании чего ты сделал такой вывод?

Вебщики все это уже по 100 раз перетёрли, прохавали и придумали что с этим делать. А с такими поделками ты будешь жрать говно, которые другие уже поели. Просто худший сценарий.

Вот именно, что ваши веб фреймворки меняются как ежегодно линяющая шерсть на теле мартышки. Зачем мне постоянно бегать за современными модными веб (и не только) технологиями, когда этим могут заняться молодые и инициативные разработчики DevExpress, а я скромно воспользуюсь их результатами, предоставленными единообразным интерфейсом вчера, сегодня, завтра.

Скачай комунити эдишон, посмотри :) среда как в дельфи/билдере, компилятор моднее стал на основе шланга.

Не, он уже не совсем такой, какой ты учил :)

Ты несешь херню, поминая Патрика не по делу, т.к. не в теме за сабж (там даже не про дельфи ни разу :) Что до наследства борланла-дебаркадера, их просто купили снова. Билдер уже умеет в современные плюсы и снова развивается. А мир стал бы чище без упоротых фанатиков-инструментофобов.

Сам ты не понимаешь суть рада :) он изначально и был для быстрого прототипирования, просто потом эффективные манагеры стали дуинг ит вронг: прототипы («поцы» от POC) обозвали MVP («минимально полезный продукт») и закладываться стали ровно на хуяк-хуяк, т.к. «тайм ту маркет» избаловал заказчиков. А прототип он по определению не для продакшена, а для выкидывания в помойку под обещания потом сделать ынтерпрайзно, но сначала они обещали так и делать, а потом «обещали обещать»... а щас и стесняться перестали, упарываясь в «эффективную эффективеость».

- Ваш грид - комбайн, нам он нахер не нужен, мы обходимся. Приделать к табличке нужный функционал не долго. Вот вы можете в этом своём гриде сделать X?
- Аааа, ыыыы, а зачем вам нужен X? У нас нет в гриде X, значит вам не нужен X!!!

Лично потратил годик-другой на прикручивание к гриду DevExpress фич, которых в нем не было. Проблема скорее в том, что ихний грид реализован намного сложнее, чем мог бы быть. Во-первых, потому что они упарывались ООП в худшем его виде, как с большой вероятностью реализованы и все остальные либы DevExpress. Во-вторых, они привязались к синхронной модели логики, похожую на таковую у штатных БД компонентов делфей, которая приводит к росту вложенных вызовов эдак до 30 с вероятностью укусить себя за хвост и к лютым тормозам в работе при ожидании синхронных ответов.

Можно ли их упрекнуть за то, что они используют ту же модель, которую использовал сам Borland?

Если же говорить по поводу «нужен ли грид», то я не знаю, чем заменить его для аналитики. По-хорошему нужен многомерный грид и возможность строить графики по нему (это я тоже делал, к слову). А просто «добавить заказ» можно сделать и без грида, тут вопросов нет.

Сам ты не понимаешь суть рада :) он изначально и был для быстрого прототипирования, просто потом эффективные манагеры стали дуинг ит вронг: прототипы («поцы» от POC) обозвали MVP

Давайте начнем с того, что RAD — это чисто маркетинговый термин, у него нет технического смысла. Быстро выплюнуть кусок дерьма можно и на Си, но почему-то никто не называет это RAD. Есть технический термин «готовое решение», есть термин «говнокод», но никакого RAD нету.

Давайте начнем с того, что RAD — это чисто маркетинговый термин,

RAD - это ведь Rapid Application Development. Определение даже не заставляет использовать визуальные дизайнеры и GUI вообще.

Лично потратил годик-другой на прикручивание к гриду DevExpress фич, которых в нем не было.

Велосипед? Есть описание в интернет или на Github?

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

IMHO это большое преимущество DevExpress по сравнению с другими вендорами. Хорошие навороченные абстракции, с которыми интересно работать.

Во-вторых, они привязались к синхронной модели логики, похожую на таковую у штатных БД компонентов делфей, которая приводит к росту вложенных вызовов эдак до 30 с вероятностью укусить себя за хвост и к лютым тормозам в работе при ожидании синхронных ответов.

Не надо зацикливаться на Borland VCL. В FMX это не исправлено?

В случае DevExpress for .NET все хорошо:

https://docs.devexpress.com/eXpressAppFramework/401747/ui-construction/views/...

https://docs.devexpress.com/Dashboard/401305/common-features/asynchronous-mode

https://supportcenter.devexpress.com/ticket/details/t444369/gridcontrol-how-t...

Можно ли их упрекнуть за то, что они используют ту же модель, которую использовал сам Borland?

Вероятно, упрекнуть можно только тех, кто использует устаревшие технологии Borland?

Билдер уже умеет в современные плюсы и снова развивается

Ага, и трава в 2002 году такая зелёная и вкусная. И C++Builder серьёзный конкурент Microsoft Visual C++, а не панацея для застрявших в 90-ых Legacy-наркоманов.

поминая Патрика не по делу

Можешь ли ты себе представить Патрика виндовозом, тягающим кнопочки TButton на формочки TForm? Вот и я не могу. Так что Delphi, C++Builder и прочие говноподелки «ООО Эм..Бракодело» – максимально непатрикоугодный хлам. Предать анафеме, сжеть и оросить святой водой, чтобы больше на свет не вылазило ни в каком виде.

Нет, разница как раз в том, что в то время на Си ты бы делал дольше, т.к. практически безальтернативно на WinAPI. А потом еще на MFC, который не сильно от него ушел (пустые каркасы, практически без дефолтного поведения, к которым нужно дописать макромагию). Пока ты не выходил за рамки того что щас уверенно называется less code/no-code, сляпать из кубиков прототип было намного быстрее чем на Си. Даже на вижуал бейсике. Так что смысл у RAD был практический (майкрософт вот его очень старнно понимала). Проблемой вижуал бейсика было, что как только тебе нужно было кастомный компонент — уже нужно было уметь на Си, а потом еще на всех видах OLE и тех же яиц с боку — COM и ActiveX :) А у борландовский продуктов такого разрыва не было, можно было спуститься на уровень WinAPI при желании сразу. Другое дело что это могли не только лишь все, кто не давал себе труда глянуть в прилагавшийся электро-мануал.

А приплел ты Патрика сюда потому что... Почему? :) Остальные твои кукареки такой же уровень эмо-истерики. «Кирпичи кривые» (С)

RAD - это ведь Rapid Application Development. Определение даже не заставляет использовать визуальные дизайнеры и GUI вообще

Да, определение не относится к GUI вообще. Я про то, что никакой «быстрой разработки» не существует с технической стороны, нет никаких способов разработать то же самое приложение быстрее, чем при «небыстрой» разработке.

Велосипед? Есть описание в интернет или на Github?

Проприетарщина же ж. Прикинь, в делфи можно писать свои компоненты.

IMHO это большое преимущество DevExpress по сравнению с другими вендорами. Хорошие навороченные абстракции, с которыми интересно работать

Кому-то «интересно работать», а у кого-то опять что-то упало или опять сроки пролюблены, потому что с утра до вечера приходится вычитывать девекспересовскую лапшу, чтобы сделать новую фичу. Это типичный результат применения ООП — монолит, который нужно полностью прочитать, чтобы понять, как его доработать/переработать одну фичу. Вот тебе и «абстракции».

Не надо зацикливаться на Borland VCL. В FMX это не исправлено?

Насколько мне известно, в FMX, как и в WPF, «исправлено» только рисование. Я сейчас почитал ихний DoRequestAlign — та же синхронная параша, из-за которой Delphi 7 по две секунды менял раб стол. Конечно, когда контролы отвязаны от оконных дескрипторов и смена положения не приводит к системному вызову и прерываниям видеокарты, то смена раб стола происходит, грубо говоря, не 2 секунды, а 200 мс, но хрен редьки не слаще — проблему с БД это не решает, и LiveBinding ее точно так же не решил.

В случае DevExpress for .NET все хорошо

Валидный поинт. В VCL версии тоже были элементы асинхронности, но слишком мало.

Вероятно, упрекнуть можно только тех, кто использует устаревшие технологии Borland?

А типа FMX дофига чего решило?

Можешь ли ты себе представить Патрика виндовозом, тягающим кнопочки TButton на формочки TForm? Вот и я не могу. Так что Delphi, C++Builder и прочие говноподелки «ООО Эм..Бракодело» – максимально непатрикоугодный хлам. Предать анафеме, сжеть и оросить святой водой, чтобы больше на свет не вылазило ни в каком виде

С одной стороны я не согласен с ретроградами, которые превозносят Си, хотя Си — очень плохой язык, и его плохость не оправдана никакой низкоуровневостью — он просто плох, поскольку никогда не проектировался. С другой стороны, я не люблю и не верю во всё это программирование мышкой — в молодисти я люто мастурбировал на линуксовую консольку, на шел-скрипты, на васик, которые ни к какому программированию мышкой не относились. Это потом уже так получилось, что я начал писать на паскале, IDE в котором имелась возможность писать мышкой, но даже тогда мышкой я предпочитал не кодить. Хуже того, каким-то образом я прошел на GSoC именно по разработке дизайнера граф интерфейса, после чего я возненавидел всей душой саму эту технологию. И тогда, и сейчас я абсолютно уверен, что единственный способ адекватно писать GUI — это интерактивное приложение аля REPL, где смена кода прямо на работающем приложении показывает результаты. Но для этого нужно выкинуть в мусорник все эти GTK, Qt, VCL, FMX, WPF, UWP, которые безнадежно застряли в синхронно-императивном стиле кодинга, и перейти на конвеерно-декларативный стиль, где данные отвязаны от отображения, где программист описывает правила превращения данных в интерфейс, а не правила перехода между каждой парой состояний из тысяч подобных переходов.

Самое смешное то, что разработчики игр уже довольно давно строят GUI именно в таком стиле, отдельно расчитывая модель и отдельно рисуя графику, при этом детали отрисовки графики минимально влияют на модель. Конечено REPL там нет, хотя, Blizzard World Editor довольно близко подобрался к этому идеалу — например, там есть предпросмотр анимации сцен.

В 2000x я много писал на C++ Builder 6, знаю людей которые до сих пор пишут на новых версиях этой IDE и знаю компании, которым пофиг, на чем написано - лишь бы обмен платёжками шёл непрерывным потоком и у бухов были кнопочки для решения разных ситуаций вне пространства 1С. Последнее, что писал, кажется - это был интерфейс к API (SSL/XML) Яндекса для автоматизированной подачи рекламы типа «от партнёров». Было круто. Но с того момента пришло осознание, что чистый C++ Builder - удобен только для рисования GUI или наоборот мелких программ-консолек. Для всего остального стал широко использовать RTTI, подставлять в код промежуточные скриптовые движки - javascript, lua, pascalscript и COM… - и появилась необходимая гибкость. Логика из «__fastcall хардкода++» перетекла в другие слои - в интерфейсе остались только вызовы.

Потом перешел на .NET, а потом в веб - php/perl/python. Через еще какое-то время накушался и Window Forms, и ReactJS, и Electron и других мегамонстров - считаю, что все технологии, делающие из моих 100Кб кода «релизы» размером 100Мб и больше - это нездоровое IT-ожирение, которое нужно лечить. Или если для 100Кб кода мне нужна говно-среда размером 500Гб и куча лицензий на компоненты к ней - это тоже нужно лечить. Экономика должна быть экономной. Либо мой проект должен быть Проектом на 1000 индийцев.

Короче, сейчас важны приоритеты: открытость, кроссплатформенность, utf8, скорость и качество написания, возможность долгого сопровождения, передачи проекта другим разработчикам, дальнейшего развития и т.п. Мне кажется, C++ Builder всему этому не удовлетворяет - и только это является одной настоящей причиной избегать его. А так - ничего плохого в нём нет, бухгалтера радуются, когда «похоже на 1С» и платёжки текут рекой.

Нет, разница как раз в том, что в то время на Си ты бы делал дольше, т.к. практически безальтернативно на WinAPI

В какое еще «в то время»? GTK существует уже весьма давно. Да и не он один.

Проблемой вижуал бейсика было, что как только тебе нужно было кастомный компонент — уже нужно было уметь на Си, а потом еще на всех видах OLE и тех же яиц с боку — COM и ActiveX :) А у борландовский продуктов такого разрыва не было, можно было спуститься на уровень WinAPI при желании сразу

Qt?

Прикинь, в делфи можно писать свои компоненты.

Серьезно? :)

Кому-то «интересно работать», а у кого-то опять что-то упало или опять сроки пролюблены, потому что с утра до вечера приходится вычитывать девекспересовскую лапшу, чтобы сделать новую фичу. Это типичный результат применения ООП — монолит, который нужно полностью прочитать, чтобы понять, как его доработать/переработать одну фичу. Вот тебе и «абстракции».

Потому что надо сначала прочитать доки, а уже потом лезть в попытки их доработок. Сроки горят обычно у галер, у которых нет узкоспециализированных людей и они хватаются за все денежные проекты подряд, до которых могут дотянуться цепкие лапки их сейлзов. Могли бы лучше попытаться найти готовых экспертов по DevExpress и оплатить работу им, а не «пытаться выучить предмет за день до экзамена».

Не надо зацикливаться на Borland VCL. В FMX это не исправлено?

Насколько мне известно, в FMX, как и в WPF, «исправлено» только рисование. Я сейчас почитал ихний DoRequestAlign — та же синхронная параша, из-за которой Delphi 7 по две секунды менял раб стол.

ОК, если твои слова правда, то тогда я еще раз убедился, что наборы популярных компонентов DevExpress для .NET заруливают менее популярные поделки и даже их собственные, которые не для .NET.

Вывод: .NET рулез!

Вероятно, упрекнуть можно только тех, кто использует устаревшие технологии Borland?

А типа FMX дофига чего решило?

Лично я не проверял, но если в дельфийском чатиге подтвердят твои слова, то нужно просто переходить на .NET и не заниматься мазохизмом. Есть ведь и Pascal for .NET, если кому-то уж приспичил такой синтаксис или нужно тащить с собой старый код не через вызовы DLL.

https://docs.elementscompiler.com/Oxygene/

Проблемой вижуал бейсика было, что как только тебе нужно было кастомный компонент — уже нужно было уметь на Си, а потом еще на всех видах OLE и тех же яиц с боку — COM и ActiveX :)

VB 5 и 6 поддерживали создание своих визуальных компонентов, которые можно было встраивать даже в формы документов MS Office.

А у борландовский продуктов такого разрыва не было, можно было спуститься на уровень WinAPI при желании сразу.

А в VB нельзя было вызывать API функции?

Другое дело что это могли не только лишь все, кто не давал себе труда глянуть в прилагавшийся электро-мануал.

Именно так :)

Короче, сейчас важны приоритеты: открытость, кроссплатформенность, utf8, скорость и качество написания, возможность долгого сопровождения

Разве в .NET, начиная с версии v5, всего этого нет?

Или если для 100Кб кода мне нужна говно-среда размером 500Гб

Почему говно?

и куча лицензий на компоненты к ней - это тоже нужно лечить.

Почему куча? Достаточно одной DevExpress Universal :)

Экономика должна быть экономной.

Ессно оплатить оборудование для запуска якобы большой IDE стоит во много раз меньше (экономнее), чем платить велосипедостроителям по рынку профи разработчиков, использующих готовые компоненты.

За еду то конечно, можете хоть на асме, хоть в машкода писать свои формы :)

Либо мой проект должен быть Проектом на 1000 индийцев.

Осталось только вам дать в подчинение тысячу индийцев, чтобы вы попытались создать свой недо .NET :)

Могли бы лучше попытаться найти готовых экспертов по DevExpress и оплатить работу им, а не «пытаться выучить предмет за день до экзамена»

Ну по итогу я и стал тем самым «экспертом по DevExpress». Но я не испытываю иллюзий по его поводу, мол «не поучаствовал сложности» и всё такое. Почувствовал, очень сложно, на любой чих нужно заворачивать dependency injection в dependency injection, хотя на самом деле проще тупо накладывать патчи на сорцы самого девэкспресса. Не знаю, как для тебя, а для меня это достоверный сигнал того, что разработка либы вообще не подразумевала расширение, вот тебе готовые фичи — будь добр программировать мышкой на них. Я в прошлом обсуждении приводил статистику того, насколько много багов в этом DevExpress оставляет сама компания-разработчик — куда там стороннему разрабу, который не ковыряет либу на фултайм годами.

ОК, если твои слова правда, то тогда я еще раз убедился, что наборы популярных компонентов DevExpress для .NET заруливают менее популярные поделки и даже их собственные, которые не для .NET

Скорее ты убедился, что Delphi — кусок дерьма, в который превратился некогда купленный проект Blue Label Software Pascal => Compas Pascal => PolyPascal, над которым Borland только слепила IDE Turbo Pascal. Это не считая того, что безупречную (для того времени) архитектуру самого языка разработал Вирт, который с этой движухи не получил совсем ничего.

Лично я не проверял, но если в дельфийском чатиге подтвердят твои слова, то нужно просто переходить на .NET и не заниматься мазохизмом

Еще бы написал «пора переходить на Visual Basic». А, хотя, ты примерно так и писал. Но по-хорошему это всё неактуальные технологии.

VB 5 и 6 поддерживали создание своих визуальных компонентов, которые можно было встраивать даже в формы документов MS Office

Да, и я бы хотел достать той же травы, которая была у создателей этой архитектуры. Хотя, тогда было модно натягивать сов на глобус, ну типа появлялось много готовых решений и еще больше спроса на них (памяти советского союза посвящается), и именно в это время под наркотой был создан современный стэк технологий: JS, Java, Python, PHP, MySQL, Qt, GTK, VBA (Excel 1993), MS Access. Правда, многие из них сдохли, поскольку слишком уж были неадекватны.

Еще бы написал «пора переходить на Visual Basic».

Наоборот, не надо переходить на Visual Basic.NET ! Зачем плодить себе конкурентов :)

А, хотя, ты примерно так и писал. Но по-хорошему это всё неактуальные технологии.

Интересно, чем же таким неактуален Visual Basic.NET ?

Да, и я бы хотел достать той же травы, которая была у создателей этой архитектуры.

А какие были недостатки у нее кроме завязки на Windows и отсутствия наследования в VB 5 и 6?

Лично я не проверял, но если в дельфийском чатиге подтвердят твои слова,

На всякий случай:

https://t.me/Delphi_Lazarus

https://t.me/Delphi_Lazarus_offtop

https://t.me/freepascal_en

Или если для 100Кб кода мне нужна говно-среда размером 500Гб

Почему говно?

Потому что затраты $2000+ на подписку DevExpress для кода в 100Кб не окупятся никогда, даже если я 10 раз напишу еще столько. Такая IDE изначально не нужна. Для 100Кб достаточно Vim установленного на Asus-eee и компилятора.

Специально посмотрел в свои старые сырцы: даже для средне-мелкого проекта (16 тыс строк, 1.1Мб, 190 файлов) - как-то не вижу острой необходимости в жире типа Visual Studio/Eclipse/… VSCode - даже его с избытком хватает.

Потому что затраты $2000+ на подписку DevExpress

Это вечная лицензия на все старые версии и новые в течение года с момента покупки. Можно не продлять и выбирать подходящую версию из десятка релизов за последние несколько лет и использовать их сколь угодно долго, после окончания подписки не будут доступны только новые релизы, выпущенные после окончания подписки, а старые до момента окончания подписки доступны и лицензированы вам навсегда. Кроме того DevExpress нередко выпускает критические фиксы даже для старых релизов еще в течение нескольких лет после окончания текущей подписки.

для кода в 100Кб не окупятся никогда,

Для DevExpress можно написать и 10Kb кода и удачно продать его от $30/h и более.

даже если я 10 раз напишу еще столько.

Вы продаете LoC (lines of code) ?

В 100кб явно не уложиться для конкуренции с DevExpress, может быть в сотни раз больше за ближайшие лет 100+ вы чего-то и напишите отдаленно похожее хотя бы на часть их набора.

Сколько стоимостей Universal лицензии вам платят в год на работе, если не секрет?

Такая IDE изначально не нужна. Для 100Кб достаточно Vim установленного на Asus-eee и компилятора.

Причем тут кбайты сорцов, причем тут выбор редактора?

Специально посмотрел в свои старые сырцы: даже для средне-мелкого проекта (16 тыс строк, 1.1Мб, 190 файлов) - как-то не вижу острой необходимости в жире типа Visual Studio/Eclipse/… VSCode - даже его с избытком хватает.

Мои обертки вокруг XtraGrid позволяют декларативно задавать многоуровневые master-detail таблицы всего в несколько строчек кода (по одной строчке на каждый уровень вложенности).

А XAF вообще позволяет редактировать модель приложения в дизайнере, а потом сгенерить и поддерживать в актуальном состоянии после правок для нее и базу данных и формочки, поддерживающие кастомизацию вплоть до использования своих компонентов.