Разработка на Pure C

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

Аноны в игноре, прогавал.

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

И правильно делает.

витает необходимость реализовать пару библиотек

зачем? отсутствие библиотек - это проблема маловостребованных язычков, а сишные библиотеки за 50 лет существования языка уже есть на все случаи жизни

и небольших программ (с минимальным GUI) на Pure C.

для gui бери gtk

Подскажите, что ныне используется для компиляции? Какие IDE?

emacs

Появились ли пакетные менеджеры?

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

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

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

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

Нужны. Зачем зависеть от пакетного менеджера конкретного дистрибутива?

Не нужны. Зачем зависеть от пакетного менеджера языка?

Языки не существуют в вакууме, множество модулей завязаны на системные библиотеки и наоборот, приложения использующие питон завязаны на его модули, соответственно и обновляться должны вместе. Иначе обновишь библиотеку и зависящие от неё модули поломаются. Ну и просто странно обновлять разные библиотеки разными командами. Поэтому конечно же модули опакечивают в системные пакеты и пользуются ими:

https://repology.org/project/python:pycairo/versions

Я, например, 5 лет разрабатывая на питоне, pip не запускал ни разу. И не запущу, потому что он поставит неизвестно что неизвестно куда, а C’шную часть гарантированно соберёт неправильно. А если не дай бог опечататься, ещё и троянов понаставит.

А если не дай бог опечататься, ещё и троянов понаставит.

Тяжела жизнь параноика…

Ты не знаешь что на pypi уже который раз обнаруживают малварь с названиями похожими на названия известных пакетов, или не веришь что можешь опечататься?

Сорцы всех системных прог вы тоже читаете как я понимаю?

Про С знаю

О! Ты знаешь оракловский Про С (Pro*C)? Не многие о нём сейчас знают=)

Есть же virtualenv?

Не страдай херней, бери PyQt или Electron, и пиши свои либы под них

Это ж хлрошо: в остальном мире за последние 20 лет мало что изменилось к лучшему

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

Что за язык Pure C?

Даже я знаю. Чистый Си.

Петя дворник.

Это ещё что за байда?

Педоракл впринципе ничего хорошего сделать не может.

Язык для прочищения дымохода.

Владимир

Есть, и что?

Попробуйте написать пакет чтобы одинаково работал и под win64 и под ATtiny13. Или вы предлагаете для каждой платформы свой репозиторий писать? Собственно, примерно так разумные люди и сделали - встроили dev- версии библиотек в системный репозиторий. Даже в виндовом порте mingw (msys2 кажется) и то пакетный менеджер есть, причем с Си-шными библиотеками.

vim?

Сокращенное от «purgen C»

gcc + geany + make

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

Так везде можно проглядеть. Помню в баше ошибку лишь спустя n лет нашли.

Пользуюсь qt-creator’ом. Компилирую, понятное дело, при помощи gcc.

Мелочи (один-два файла без зависимостей) собираю вручную, что крупней без сложных зависимостей — make’ом, а все остальное — CMake’ом.

// Eddy_Em

В Geany есть куча плагинов, хз зачем ты ушел, в том числе и для автокомплита, go to declaration/implementation, отладчик, менеджер проекта, итд.

Какие IDE?

Geany неплох, есть еще GnomeBuilder, но им я не пользовался.

Появились ли пакетные менеджеры?

Только саrgо.

Там нет стат. анализатора, нет вменяемого автодополнения и навигации по коду. В общем, пока что лучше qt-creator я не встречал редактора сишного кода.

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

в разы быстрее

Пруфани.

Даже на gtk/gtk.h видно, возьми любую большую сишную либу, заинклудь все в QtCreator и Geany (-g tags либо в файлы проекта ее добавь через плагины), можешь заодно потребление памяти сравнить.

Я написал все ради справедливости, Geany может куда больше чем тупой автокомплит по текущим открытым файлам, но надо плагины ставить. Но это не QtCreator все же.