Какой язык программирования учить

[yacc]

Судя по тому, что и как он пишет, он и разрабатывать-то не очень…

Это особый стиль - дельфийский!
На хабре как-то попалось

Когда начинал изучать Delphi, потратил много времени на принципы работы WinAPI, копание в библиотеке VCL. Зато понял, как все работает внутри. После чтения форумов по Delphi, понял за что дельфи-программистов не любят разработчики C/C++ — большинство вопросов сводилось «как найти компоненту, которая делает ...»

Я-то как раз начинал с WinAPI, причем на win16, причем на чистом С - без каких-либо С++ - программа получается компактная - десяток килобайт exe-file.
Но люди не понимают что MDI приложение в целом совершенно просто реализовать на чистом С без каких-либо классов вообще! И точно также легко сделать всякие диалоговые окна.

[yacc]

Стандартный конвейер с sed/grep/awk поможет решить 99% проблем с обработкой текстов.

Гораздо проще и нагляднее на perl причем с теми же потоками используя while (<>) просто сделав этот скрипт исполняемым, чем городить конвейер из стандартных утилит типа sed
С регулярными выражениями там все отлично.

Более того, на нем очень много сайтов в свое время писали. Тот же ixbt на нем жил.

[yacc]

А что там с линуксом? Наворотили уже, ни хуже чем в винде.

Больших GUI приложений там на минимум порядок меньше, чем коммерческих и даже свободных под винды. Как правило, с более простым функционалом

[yacc]

Всё прекрасно решается другими языками из десятки рейтинга Tiobe.

Нафига городить портянку из классов если на перле это делается  в пять строчек ?
Тем более что на линуксе он есть сразу - вообще практически ничего ставить не надо, особенно монстров IDE

 

пока одни функции выучил, то без практики другие забыл, а фирма или комитет уже новый стандарт языка выкатила, как для C++23

Функции - это не язык - это библиотека. И пофиг что используешь ее на 10%.
Язык - это ключевые слова/операторы и выражения - а что использовать зависит от прикладной области. По библиотекам отдельные книги-справочники существуют.
Как пример, если я на С занимаюсь строкообработкой то math.h мне не нужен, если я не делают синхронизацию между процессами мне не нужен signal.h, не делаю локализацию то мне не нужен locale.h и т.п.

Подавляющее большинство С++ разработчиков не используют MPL - библиотеку метапрограммирования.

[yacc]

Естественно, на эту тему полно литературы, но вы признались, что эти языки не осилили. Вот, например, и на английском и на русском языке описание:
Си++ (C++)

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

[yacc]

Все эти алгоритмы ещё и гораздо лучше реализованы на Delphi

Алгоритмы не могут быть лучше реализованы - они такие же.

Так что ваш perl на Телеге Паскаль не догонит.

Перл для строкообработки на два порядка лучше прямо из коробки - даже модули подключать не надо

[yacc]

Упоротому вендовозу, к сожалению, этого не понять…

Даже под виндами писать на дельфи то, что можно сделать на PowerShell - откровенная глупость.
Пока его толком не было у меня всегда был установлен Сygwin - часть задач на никсах решается гораздо проще - скриптами - и никакая компиляция вообще не требуется.

Продвинутым линкусоидам даже толстые IDE не надо - можно  NeoVIM настроить и работать эффективно в той же отладке.

[yacc]

Что характерно для всех тех чайников, кто пытается их реализовать не на основе OOP, а на процедурном подходе

Вы абсолютно не понимаете программирование - один и тот же алгоритм тот же, что есть классы, что их нет - это ведет к одному и тому же ассемблерному коду, разница будет только в именовании или манглинге
скажем для дерева на С++ будет что-то типа _ZN9org8Tree6AddE для метода Tree::Add
а для С это будет просто _treeAdd для функции treeAdd
И все!
Такой подход - т.е. полное непонимание потрохов и что делает компилятор - характерен для программистов на VB - им формочки главное и чтобы мышкой по свойствам. Как я вижу у вас подход 100% идентичен программистам на VB.

[yacc]

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

Если у кого-то было плохо с математикой - я не виноват.

в том числе многопоточными

Вы сам-то читали те, книги что предложили по алгоритмам ?
Там ВСЕ алгоритмы однопоточные, потому что книги объясняют суть их работы и математический фундамент, что за ними стоит.

[yacc]

ООПщина в простой форме и в С вполне доступна. Объект "камера", объект "фокусер" и т.д.
И, действительно, есть задачи, где она удобна. Но в итоге — да, никакой разницы нет, на каком ЯП писать изначально, после компилятора все одинаково.
И даже перегрузку на С можно делать при помощи макросов и генериков.

Да, все так.

[yacc]

судя по вашим сверхглубоким познаниям

Найдите там многопоточные алгоритмы

[yacc]

Купил себе не так давно классную книжку. Очень советую почитать.

Примерно в 93-94 я почитывал вот такое ( распространялось в текстовых файлах в кодировке ДОС или КОИ-8  )
На фоне того DOS или даже Win3.1 это смотрелось очень круто!
Поэтому в FreeBSD сидеть в терминале VT100 телнетом мне нравилось
Линукс еще только появлялся ( первый с которым я столкнулся позже была слака )

[yacc]

Цитата: yacc от 18 Фев 2026 [12:05:26]
Больших GUI приложений там на минимум порядок меньше
Ну, мне сравнивать не с чем, т.к. маздаем я уже 20+ лет не пользуюсь.

А мне есть с чем - я GUI программированием с 90-х занимался. И у *NIX по сравнению с виндами был разный путь.
Винды изначально были рассчитаны на однопользовательские десктопы, поэтому окна там сделаны проще, зато унифицированнее для пользователей и программистов - те же контролы содержатся в user.dll, а всякие типовые диалоги ( типа открытия или сохранения файла ) - в commctr.dll.
И все это легко доступно в SDK так что и на чистом С вполне можно сваять программу с диалогами/формами/мультиокнную.
А тем более легко на С++ на MFC\WTL. И еще легче в VB, перетаскивая контролы на форму.

*NIX пошел своим путем, ибо это изначально была многопользовательская система, где getty ждет соединения, форкает логин и запускает сессию  пользователя с shell, и таких сессий разных пользователей одновременно может быть много.
К графике они подошли с той же позиции и соорудили Х, которая аналогично позволяла иметь несколько сессий на одну машину.
Только вот сил на это ушло много и поэтому сам X поддерживает в Xlib только откровенные примитивы рисования - линии, круги, заливку, текст шрифтом. Никаких кнопок/диалогов там вообще нет.
Наглядно чистое приложение с кнопкой можно глянуть тут
https://www.linuxquestions.org/questions/programming-9/xlib-code-example-launching-pop-up-dialog-from-a-parent-window-maximize-problem-4175749415/
Там видно что "кнопка" - это  вызов XSetForeground XFillRectangle  XDrawRectangle XDrawString.
Т.е. это как программерам на DOS писать интерфейс используя BGI - графическая библиотека с такими же примитивами.
Контролов, или как в никсах их называют "виджеты" - в чистом Х - нет.

А есть они уже с оконными менеджерами и соответсвующими библиотеками - например CTWM
https://en.wikipedia.org/wiki/CTWM
Он использует что-то типа LessTif -свободного аналога коммерческой библиотеки виджетов Motif.
Плюс появилось дофига разных библиотек виджетов - LessTif, Tk, FLTK,... а позже wxWidget, Gtk, Qt которые требуют разного кода условно для одного и тоже диалога в программе.

Поэтому на никсах особо GUI не писали. За 90-е я, наверное полтора десятка коммерческих прог сделал на MFC и одну фиксил на С++ Builder, плюс несколько десятков примеров прогнал на чистом С с WinAPI. И сделал пожалуй только пару примеров на LessTif под FreeBSD под Х - это было очень геморно.
Натурально GUI на никсах проще писать на Java\Swing и не париться с низким уровнем. Я такое делал и запускал и виндах и на RedHat\SuSE и на Sun Solaris UNIX SYSTEM V R4 при этом не перекомпилируя программу - просто копируя jar.

Поэтому графического софта на лине гораздо меньше  - потому что там не стандарт, а солянка. Более менее он пошел как устоялся Gtk и сделали свободным Qt.

[yacc]

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

Часть линуксоидов чтобы не париться с виджетами и выбором библиотеки под них, тупо делают GUI с веб мордой: тупо запуская приложение запускается мини веб-сервер даже с простым CGI на свой порт и дергается веб-браузер на localhost:port

[yacc]

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

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

[yacc]

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

[yacc]

Я в курсе, какие помои эти "коммерческие разработки"

Не, может вы себе представляете женщину-кассира в кассе продаж авиа или жд билетов, которая работает в командной строке, а чтобы посчитать более сложные варианты, типа из Мск в Хабаровск через Иркутск, а обратно из Хабаровска в Мск через Новосибирск, использует sed и awk и которая пишет скрипты на баше на лету....
А я вот не представляю такой вариант
Как и банковское приложение на смартфоне в командной строке - тоже не представляю

[yacc]

Шансы на человеческую графику в unix могли быть, если бы авторы X сделали бы ввод/вывод графики таким же простым для юзера, как взаимодействие с файловой системой.

И на удаленную сессию через rcp гонять ? Или через nfs ?
Вся суть Х - это многопользовательская система, как и обычный терминал, только графическая.

[yacc]

Вот и обращаться с ней надо, как с /dev/tty.

И будет в целом такой же монстр как и  Х
Там вроде /dev/tty7 как раз за иксами.

[yacc]

примеры типа rio, например

Это уже Plan 9 получится