Вот взять тот же Python. Можно делать хоть Windows-десктопные приложения, причем не в виде скриптов а в скомпилленом виде без необходимости что-то отдельно устанавливать (с помощью https://pyinstaller.org/en/stable/ , к примеру).

Но блин! Медленно!!! Даже простое окошко с кнопкой — ждешь несколько секунд пока оно раздуплится

C# .Net чуть быстрее, но все равно раздражает задержка JIT при запуске, особенно когда много библитек подтягивает

Понятно что C и ++ вне конкуренции. Но какие альтернативы?

Вот есть Flutter от великого и могучего Google. Собрал — и куль, запускается почти как приложение на C

А потом присмотрелся повнимательнее:

	Скрытый текст

	разгадка
	Оказывается Google не придумал ничего лучше, как генерить C++-код на основе Dart и уже потом компилит его и создает exe

Да нет никакой проблемы. Я как-то делал программку на Java. WinAPI через JNI пробрасывал и дергал напрямую. JVM стартует может 0.1 секунды. И всё пошла работать программа. Никакого отличия от C на глаз не было, всё работало абсолютно реактивно. Два раза щелкнул и окошко появилось. Крохотную запускалку на exe делал тоже, по сути получается крохотный exe плюс JVM в виде DLL-ок плюс нагрузка в виде class-файлов.

Уверен, что и с пайтоном можно то же самое сделать.

Просто всем пофиг на скорость.

Если тебе не пофиг — возьми свой любимый стек, тот же пайтон, про который ты написал и попробуй разобраться — от чего там эти тормоза. Выкинь всё лишнее. У меня вот пайтон консольный стартует моментально, без тормозов. WinAPI очевидно тоже работает моментально. Значит что-то происходит между запуском python.exe и вызовами WinAPI, что тормозит выполнение. К примеру в JVM есть два неочевидных фактора, но когда начинает профилировать — они вылазят. Во-первых принято классы паковать в zip-архивы (jar-файлы). Их распаковка занимает время на старте. При этом можно их не паковать или паковать с нулевым сжатием, это даёт прирост в скорости. Думаю, можно и получше формат придумать, до этого я уже не дошёл. Во-вторых JVM проверяет все загружаемые классы на предмет того, не подсовывают ли ей фигню. В целом эта проверка ненужная, я же сам их скомпилировал, откуда там фигня. Поэтому такие проверки раньше можно было отключать, это тоже улучшало время старта.

Ну и естественно фреймворки надо выкинуть или писать их так, чтобы они не влияли на скорость выполнения. Нет никакой проблемы на той же жаве писать, как на C, к примеру. CreateWindowExW и пошёл там в цикле GetMessageW/DispatchMessageW или как там было.

Здравствуйте, Shmj, Вы писали:

S>Понятно что C и ++ вне конкуренции. Но какие альтернативы?

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

Здравствуйте, velkin, Вы писали:

v> S>Понятно что C и ++ вне конкуренции. Но какие альтернативы?

v> По сути альтернатив нет.

Глупости какие. Есть Delphi, есть Lazarus.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, velkin, Вы писали:

v>> S>Понятно что C и ++ вне конкуренции. Но какие альтернативы?
v>> По сути альтернатив нет.
R>Глупости какие. Есть Delphi, есть Lazarus.

С академической точки зрения есть много языков и библиотек достойных изучения. А с точки зрения технологий я бы посоветовал уволить тех, кто советует создавать с нуля коммерческий проект на Delphi, Lazarus и подобном.

Раньше нас всех извиняла неопределённость будущего. Я сам увлёкся .NET после C++. Да и Delphi не полностью обошёл меня стороной. Но какие оправдания будут сейчас? Их больше нет. Сейчас для меня это даже не предмет спора, а предмет молчаливых насмешек.

Здравствуйте, Shmj, Вы писали:

S>Понятно что C и ++ вне конкуренции. Но какие альтернативы?

в вопросе вижу скрытый ответ.

Смотрел тут
https://programming-language-benchmarks.vercel.app/

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

Здравствуйте, vsb, Вы писали:

vsb>Ну и естественно фреймворки надо выкинуть или писать их так, чтобы они не влияли на скорость выполнения. Нет никакой проблемы на той же жаве писать, как на C, к примеру. CreateWindowExW и пошёл там в цикле GetMessageW/DispatchMessageW или как там было.

Ты же предлагаешь написать программу на Win API с обработкой на ином языке.
Было,и не раз. Классика — Visual Basic (еще до .net), Pascal/Delphi и т.д.

Все верно. Пока своя обработка не тормозит, скорость определяется Win API

А вот когда начинают делать свои window less controls не на С++, да еще накрутят всякие свои промежуточные слои из-за того, что никак нельзя без фабрик , фасадов и прочих паттернов, то это все и будет тормозить.

Здравствуйте, velkin, Вы писали:

v> R>Глупости какие. Есть Delphi, есть Lazarus.

v> С академической точки зрения есть много языков и библиотек достойных изучения. А с точки зрения технологий я бы посоветовал уволить тех, кто советует создавать с нуля коммерческий проект на Delphi, Lazarus и подобном.

v> Раньше нас всех извиняла неопределённость будущего. Я сам увлёкся .NET после C++. Да и Delphi не полностью обошёл меня стороной. Но какие оправдания будут сейчас? Их больше нет. Сейчас для меня это даже не предмет спора, а предмет молчаливых насмешек.

Оправдания??? Это в тебе какие-то комплексы говорят. Лично я не вижу причин "оправдываться" за использование одного из лучших языков, пусть и не самого популярного

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вот когда начинают делать свои window less controls не на С++, да еще накрутят всякие свои промежуточные слои из-за того, что никак нельзя без фабрик , фасадов и прочих паттернов, то это все и будет тормозить.

Всё же меня терзают сомнения, что это обязано тормозить. Но писать свой фреймворк для проверки этого утверждения я не буду.

Я считаю, что тормозят конкретные фреймворки. Вот, к примеру, Java Swing — тормозит. Тут спорить не буду. Но в то, что нельзя было написать по-другому, пусть даже и через имитацию UI, тоже верить отказываюсь, не вижу причин.

Основная причина — скорость никому не нужна. Вот и всё. Нужно "good enough". WinAPI летает только потому, что делался в 90-х годах для Pentium 1.

Здравствуйте, vsb, Вы писали:


vsb>Всё же меня терзают сомнения, что это обязано тормозить. Но писать свой фреймворк для проверки этого утверждения я не буду.

Я не писал для Windows GUI ни на Swing, ни на чем-то еще. Но на C# я писал, поэтому кое-что могу сказать о том, что может тормозить.

Например, получение списка файлов из каталога. Это можно сделать простым Directory.GetFiles (за название не поручусь), и вернется массив. Вот он место и займет. Правда, сейчас можно и чем-то вроде Enumerator, и тогда не займет. А в WinAPI не займет никогда — там все получают по одной записи в одну и ту же WIN32_FIND_DATA, поэтому сколько бы ни было файлов в каталоге, памяти в моем АП нужно sizeof WIN32_FIND_DATA.
Да, можно и в C# так же сделать, но соблазн получить все сразу есть, и многие именно так и сделают.
Другой пример. Всякие "массивные" контролы типа ListView и TreeView в C# обрамляются в классе, их обслуживающем, списком или деревом из содержимого. Этот список вообще-то не нужен, так как содержимое есть в самом контроле. Но "сделайте нам удобно" — и делают. Со списком обращаться проще, чем каждый раз SendMessage делать. Опять же не обязательно иметь этот список, можно и виртуальный режим использовать.

Тут дело не в том. что нельзя сделать неэффективно. Можно сделать. Тут дело в том, что на WIN API нельзя сделать неэффективно, таких средств просто нет. Но времени на написание больше уйдет. Буду я возиться с этим энумератором, если можно одним вызовом все получить! Лишнего много получу, говорите ? Э, ладно, и так сойдет, дедлайн на носу.

В итоге все это провоцирует на использование таких неэффективных средств. А еще "память не ресурс, GC все сделает..." В итоге и имеем неэффективный код.

Здравствуйте, vsb, Вы писали:

vsb>Если тебе не пофиг — возьми свой любимый стек, тот же пайтон, про который ты написал и попробуй разобраться — от чего там эти тормоза. Выкинь всё лишнее.

Да там нечего выкидывать — простое оконное приложение с 1 кнопкой для тестов. И тормозит, когда преобразовано в exe-файл через pyinstaller.org. И само по себе долго запускается как скрипт, пол секунды а то и больше.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тут дело не в том. что нельзя сделать неэффективно. Можно сделать. Тут дело в том, что на WIN API нельзя сделать неэффективно, таких средств просто нет. Но времени на написание больше уйдет.

Средств нет, только у граждан усиленно handle текут в GDI. Так-то и с обычными окнами(контролами) такая же ситуация, но в GDI чаще и массовей объекты создаются, что быстро проявляется и падает.
Ну, и необходимость передавать в функции буферы под заполнение, конечно никого не провоцируют выделять под строку 100500 байт, чтобы уж точно всё уместилось.

PD>Буду я возиться с этим энумератором, если можно одним вызовом все получить! Лишнего много получу, говорите ? Э, ладно, и так сойдет, дедлайн на носу.

Если этих людей пересадить на другой язык и заставить использовать WinAPI, то они изменят подход к разработке?
Вот как-то у меня ещё ни разу не было проблем из-за того, что кто-то вызывал GetFiles, а не EnumerateFiles.
Люди даже с GC умудряются утечки памяти плодить, используют неподходящие структуры данных и т.д. и т.п.

PD>В итоге все это провоцирует на использование таких неэффективных средств. А еще "память не ресурс, GC все сделает..." В итоге и имеем неэффективный код.

Сейчас бы инструменты винить в низкой квалификации разработчиков.

Здравствуйте, rudzuk, Вы писали:

v>> Раньше нас всех извиняла неопределённость будущего. Я сам увлёкся .NET после C++. Да и Delphi не полностью обошёл меня стороной. Но какие оправдания будут сейчас? Их больше нет. Сейчас для меня это даже не предмет спора, а предмет молчаливых насмешек.
R>Оправдания??? Это в тебе какие-то комплексы говорят. Лично я не вижу причин "оправдываться" за использование одного из лучших языков, пусть и не самого популярного

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

Кстати, я тут посмотрел.

Lazarus
графический (GTK+, Qt, Windows API)

GTK — Си.
Qt — C++.
Windows API — Си.

Это один из главных доводов использовать C/C++. По сути используя что-то другое со временем начинаешь понимать, что в конечном итоге всё завязано на C/C++. У меня в своё время была мысль, зачем мне использовать что-то через переходники, когда я могу делать это напрямую в C/C++.

Там даже термин для этих переходников придумали, пишу по бумажке, interoperability. Интерпоплер, интерпоре, интероперабилити. Да, мы сделали это, мы установили функциональную совместимость с языками C/C++ программируя на ещё "одном из лучших языков".

Здравствуйте, velkin, Вы писали:

v> Оправдания нужны для заказчика. Тебе как программисту это конечно же не нужно. В конце концов именно заказчику потом жить с этим проектом, когда от него уйдёт разработчик "одного из лучших языков".

Заказчику нужен результат и сроки, а его интерес к инструменту исполнителя это из области фантазий форумных фантазеров.

v> Кстати, я тут посмотрел.

v> Lazarus
v> графический (GTK+, Qt, Windows API)

v> GTK — Си.
v> Qt — C++.
v> Windows API — Си.

v> Это один из главных доводов использовать C/C++.

То есть, все вокруг должны писать на Сях потому что библиотеки имеют Си-апи? Давно такой чуши не читал.

v> По сути используя что-то другое со временем начинаешь понимать, что в конечном итоге всё завязано на C/C++.

Ну да, исторически так сложилось, что Си-апи это единственный безгеморойный способ обеспечить взаимодействие с разношерстным окружением. Это не хорошо и не плохо, это просто объективная реальность в которой мы все находимся.

v> Там даже термин для этих переходников придумали, пишу по бумажке, interoperability. Интерпоплер, интерпоре, интероперабилити. Да, мы сделали это, мы установили функциональную совместимость с языками C/C++ программируя на ещё "одном из лучших языков".

Если ты не в курсе, в "одном из лучших языков" нет необходимости ни в каких переходниках. Примитивы Сей ровнехонько ложаться на примитивы Паскаля. Это тебе не с жабой интероперабилиться...

Здравствуйте, velkin, Вы писали:

V>Это один из главных доводов использовать C/C++. По сути используя что-то другое со временем начинаешь понимать, что в конечном итоге всё завязано на C/C++. У меня в своё время была мысль, зачем мне использовать что-то через переходники, когда я могу делать это напрямую в C/C++.

Как в C++ нужен *.h файлик с описанием функций и типов из dll, так и в Delphi (подозреваю, что в Lazarus также) нужен аналогичный *.pas файл.
Разница только в том, что для С++ скорее всего есть готовое от разработчика, а для Delphi придётся самому писать или искать сторонний.
Переходников от этого только не появляется и вызов осуществляется так же нативно, как в С++.
В .NET вот dll сама хранит описания типов и методов и не нужно никакие файлики дополнительные подключать, чтобы компилятор узнал что можно из библиотеки вызывать.
Не знаю зачем вы там на С++ этими переходниками пользуетесь и почему за столько лет не завезли похожих плюшек.

Здравствуйте, karbofos42, Вы писали:

K>Не знаю зачем вы там на С++ этими переходниками пользуетесь и почему за столько лет не завезли похожих плюшек.

В C/C++ никто и не пользуется переходниками, поскольку они не нужны. Это я вспоминаю .NET с его языками программирования. Не хочешь писать сложный движок с нуля, ну смотри, для .NET как всегда ничего нет, но есть же переходник для проекта на C/C++. Начинают всплывать понятия маршалинг, интероперабельность и прочее.

В принципе эта тема уже давным давно устарела. Лично для меня открытия сделанные топикастером были в 2008 году. Под капотом вот же удивительно, всегда оказывается C/C++. Я бы единственное, что добавил, что новичкам лучше сначала выучить Си, потом перейти на C++.

Это позволит избежать ошибок в изучении. Почему программисты прошлого были умнее. Когда лучше двигаться от математика и аппаратчика, до абстракциониста и пользователя, а не наоборот.

Что касается всяких кричалок какой язык учить, опять же кого это волнует. Например, C/C++ позволяет создать наиболее совершенную программу, естественно при наличии профессионализма. Но ведь коммерческие программисты просто зарабатывают деньги.

Это заказчик должен думать, что он использует, а не программисты, которых он нанимает. Заказчик хочет проект на Delphi, Rust, Java, Go, Kotlin и прочих. Так пожалуйста, это его ресурсы, его деньги, его время.

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

Вот C/C++ как раз профессиональные, хотя объективно говоря в них нет ничего особенного. Просто они заняли всю нишу и писать не на них всё равно, что переписывать все операционки и топовые проекты с нуля.

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

Здравствуйте, karbofos42, Вы писали:

K>Средств нет, только у граждан усиленно handle текут в GDI. Так-то и с обычными окнами(контролами) такая же ситуация, но в GDI чаще и массовей объекты создаются, что быстро проявляется и падает.

Или нет. мне нравилось на WinAPI писать когда-то мелкие утилиты, но писал и довольно развесистый GUI — система видеонаблюдения с кастомными контролами. Работало месяцами без остановки.

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

Ой, практически у всех этих функций есть вызов для получения размера буфера, так что не надо.

Здравствуйте, Shmj, Вы писали:

S>Понятно что C и ++ вне конкуренции. Но какие альтернативы?

Присмотрись к Qt, а точнее, QML — это язык по типу JavaScript.
Его используют в том числе для разработки GUI-приложений на мобильных платформах Sailfish/Аврора (правда там упрощенный набор компонент).
По сути на этих ОС QML — единственный способ писать gui-приложения

Здравствуйте, Nuzhny, Вы писали:

N>Или нет. мне нравилось на WinAPI писать когда-то мелкие утилиты, но писал и довольно развесистый GUI — система видеонаблюдения с кастомными контролами. Работало месяцами без остановки.

N>Ой, практически у всех этих функций есть вызов для получения размера буфера, так что не надо.

Напоминаю, что я отвечал на тезис: "Тут дело в том, что на WIN API нельзя сделать неэффективно, таких средств просто нет."
Так есть такие средства или нет?

Здравствуйте, velkin, Вы писали:

V>В C/C++ никто и не пользуется переходниками, поскольку они не нужны.

"Переходники" не нужны примерно в любом нативном языке, а не только в Си и плюсах.

V>Это я вспоминаю .NET с его языками программирования. Не хочешь писать сложный движок с нуля, ну смотри, для .NET как всегда ничего нет, но есть же переходник для проекта на C/C++.

Это лет 10 как не актуальная проблема. Всё важное уже переписали под .NET.
А как называется, что в С++ у многих библиотек свой тип для строк и свои контейнеры?
Вот эти постоянные преобразования между QString и std:string или char* — это не переходники?

V>Начинают всплывать понятия маршалинг, интероперабельность и прочее.

А такие замечательные вещи как: COM/OLE/ActiveX, нигде в памяти не всплывают?

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

Детский сад какой-то. За разработкой всех распространённых языков в итоге стоят корпорации, т.к. они это оплачивают.
Даже вот не знаю почему это Майкрософт и Интел указаны на сайте https://isocpp.org/about как "Gold members".
Россия не оказывает никакого влияние на развитие любого популярного языка.
Принципиальная разница тут только в том, что для C++ запилили компилятор для процессоров Эльбрус и Байкал, а для Java или C# — нет.

V>А то, что можно где-то стать профессионалом просто выбрав какой-то язык программирования, так это как по мне и вовсе обман маркетологов.

Обман маркетологов в том, что любой нормальный программист перебирает несколько языков, а в итоге останавливается на тех, что ему нравятся и приносят доход?