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

[Eddy_Em]

ООПщина в простой форме и в С вполне доступна. Объект "камера", объект "фокусер" и т.д.
И, действительно, есть задачи, где она удобна. Но в итоге — да, никакой разницы нет, на каком ЯП писать изначально, после компилятора все одинаково.
И даже перегрузку на С можно делать при помощи макросов и генериков. Может, кому-то даже понравится, но мне проще явно указывать нужную функцию.
Вот шаблонов в С нет. Хотя, этот, вроде бы недостаток с одной стороны, является достоинством с другой. Время компиляции! Лично мне, пересобирающему во время разработки чуть ли не каждые 5-10 минут, это важно. А коллеге приходится каждый раз по полминуты ждать, пока его шаблоны развернутся. Да и чтение: "топорный" сишный код куда как проще читать, чем это нагромождение шаблонов. А чем сложней - тем больше шансов где-то ошибиться.
Вот против констэкпров я бы ничего не сказал, а с удовольствием бы их использовал. Вот, засранцы, которые всякий бред вроде дженериков и булов вводят в новый стандарт С, лучше бы с констэкспров начали!
А еще - абы не запретили, как в шланге, вложенные функции. Уж слишком много всяких вещей без вложенных функций сильно пострадает в производительности.

[yacc]

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

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

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

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

[yacc]

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

Да, все так.

[Павел Васильев]

Вы сам-то читали те, книги что предложили по алгоритмам ?

И вам советую, например, одну из них. Хотя вы вряд ли что там поймёте, судя по вашим сверхглубоким познаниям в математике и реализации алгоритмов без ООП.

[yacc]

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

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

[Eddy_Em]

Купил себе не так давно классную книжку. Очень советую почитать.
Правда, тяжелая, зараза. Уж подумываю, не сделать ли в сортире откидной столик, а то неудобно читать: руки затекают быстро.

[Ph_user]

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

[Eddy_Em]

Лет почти 20 назад, когда мне понадобилось использовать быстрые алгоритмы поиска звезд на изображении камеры подсмотра, я попытался было использовать openCV. Это было адски медленно: в кусочке 300х300 пикселей он находил (бинаризация, морфологическая фильтрация, поиск 4-связных областей) три "звезды" за какое-то дикое время (чуть ли не 300мс). Пришлось писать свое, чтобы уложиться в 50мс. Уложился в 30. И дальше продолжал тянуть этот свой велосипед в течение многих лет.
А вот недавно, когда добавлял в "астровидеогид" (deprecated, но новый некогда писать) очередную камеру, подумал: а почему бы не сравнить мой алгоритм с OpenCV? Вдруг там уже все ОК, и он так сильно не тормозит? Не вышло: сишный интерфейс полностью изничтожили, а с крестами связываться я не собираюсь.
Ну, меня производительность моих алгоритмов устраивает, а если захочется еще шустрей, можно распараллелить поиск связных областей (всего-то нужно добавить функцию "связи" кусков и перенумерации). На современных процессорах, где десятки ядер, параллелизация очень хорошо может зайти.
Ну и упомянутые SIMD-инструкции тоже. Вот у меня дома процессор за 10тыр с алиэкспресса, поддерживает avx512. Т.е. теоретически можно за один присест по 512 пикселей изображения обрабатывать (те же морфологические операции сводятся к логическим: "и", "или" + сдвигам).

[Karagy]

По поводу устоявшегося ООП: очевидна узость подхода диспетчеризации только по типу. Но когда указываешь на это адептам - они впадают в истерику. Какая-то невероятная привнесённая этим ООП косность мышления.

[yacc]

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

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

[Вантуз]

Если не созрел для C++, то и С ему тоже не осилить

[Вантуз]

Наоборот, 99,99% софта имеют оконный и многооконный графический интерфейс общения не только с компиляторами, но и с готовым софтом.

/* Где здесь смайлик "в цитатник"? */

[Павел Васильев]

/* Где здесь смайлик "в цитатник"? */

[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.

[Eddy_Em]

Нет уж, что GTK, что Qt - просто адская дрянь!
Я встречал лишь одну вменяемую библиотеку виджетов - nuklear. А в качестве бэкенда - opengl.
Но, к счастью, мне не нужно писать приложения с GUI. Нет у меня задач, где оно нужно. Разве что фитсы свежеотснятые смотреть в ccd_capture: там я на opengl сделал (все равно виджеты для этого не нужны, только сочетания клавиш).
Весь мой клиент-серверный софт имеет простой текстовый протокол, чтобы даже из netcat можно было управлять.
Ну, а с железками все ясно: для STM32 GUI не нужен.

[yacc]

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

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

[Eddy_Em]

Есть и веб-морды, но только для именно сетевых решений: управление спектрографами, всякие графики метео и т.д., и т.п. Вахтеру вот, недавно, при помощи дикпика веб-морды для управления шлагбаумом нарисовал (шлагбаум около нашего комплекса "Астро-М", поэтому пришлось мне отдуваться...
А вообще, очень многое мое железо так и эксплуатируют - напрямую из терминала. Т.к. лень писать "прокладку". Ну, максимум - баш-скрипт для автоматизации рутины.

[yacc]

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

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

[Eddy_Em]

Так и сейчас достаточно. А автоматическому конвейеру GUI априори не нужен. Да и "полуавтоматическому" нужен лишь вначале: проверить свои алгоритмы. Те же экзопланеты искать: графики гнуплотом строятся лишь на самом заключительном этапе. Все основное - в командной строке, т.к. идиотов руками эти десятки тысяч звёзд обрабатывать нет.
Возможно, когда-нибудь, когда запустим все 5 телескопов "Астро-М", если будем живы и не лень будет, сделаем для планировщика веб-морду. Но поначалу хватит элементарного текстового конфиг-файла.
Абы у коллеги его "верхний уровень" заработал уже, а то стыдоба: обещали к осени оставшиеся 3 телескопа запустить, а воз и ныне там... Писал бы он не на С++, а как я - на С, наверняка всё уже бы работало! По крайней мере, на нижний уровень мне чуть больше месяца понадобилось. Но там ещё работы с механикой полно: оказалось, что в астросибовских монтировках неправильно концевики стоят + нужен концевик "юг", чтобы телескоп можно было хотя бы как БТА - на 540 градусов относительно главной оси вращать...

[yacc]

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