Изучить С

Раньше каждая ячейка памяти была на вес золота. Ты знал, сколько тактов займёт команда, сколько циклов задержка в памяти, и планировал всё вручную.

Я помню те времена. Уровень ностальгии – скажем так, умеренный. Я писал драйвер на ассемблере КР580ВМ80А, сохранял на магнитофон, вешал хуки на Монитор (до сих пор благодарен создателям Монитора, которые точки входа для этих хуков предусмотрели), запускал, констатировал, что всё повисло и погибло, в том числе исходники в памяти, загружал их с магнитофона обратно и пытался понять, где я накосячил. И так много-много итераций. Да я его в итоге даже написал, отладил и показывал на рязанском конкурсе программ для «Партнёра». А был бы у меня i386 и блат в Релкоме – я бы, может, вместо этого Линусу помог бы с ядром, он его как раз ровно в те времена начинал. Шучу-шучу, как раз тот опыт мне помог понять, что системное программирование это в первую очередь огромнейшее трудолюбие и терпение, коих у меня явно было маловато.

Потом к «Партнёру» выпустили контроллер дисковода, я его радостно купил. Но собственноручно спаянный шлейф глючил настолько дико, что CP/M загружалась с кучей ворнингов и через два раза на третий (ну не относится владение паяльником к моим сильным сторонам, увы).

Тем, кто грустит по низкому уровню, предлагаю подхватить и реализовать мою идею о современном открытом КПК на одноплатнике с прошивкой а-ля PalmOS 5. Только прошивку я бы всё равно стал делать на Си, поскольку в 2025 году привязываться к процессорной архитектуре очень плохая идея. Си – переносимый ассемблер!

И да, Си это традиционный язык для настоящих инженеров без прибивания своей нетленки к интелу, Арму и кому бы то ни было ещё ржавыми гвоздями, а valgrind – отличный инструмент поиска ошибок в памяти. Да ты и сам наверняка всю эту тираду написал в качестве стёба, поскольку твои дифирамбы Rust-у ЛОР прекрасно помнит. :P

Если вам нужен «язык как язык», то задачи можно найти на сайтах:

• codewars.com - синтаксический тренажер (сокращения и идиомы).
• leetcode.com - алгоритмический тренажер (оптимизация скорости выполнения кода).

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

Для этого (на выбор):

• Таненбаум (книги по ОС, Сетям, Minix).
• Столяров (методичка 2006, второй том трехтомника «Системы и Сети»).
• Robert Love «Linux System Programming».
• Kerriks «Linux Programming Interface».
• Stevenson and Rago «Advanced Programming in the Unix Environment».
• Робачевский «Операционная система UNIX».
• Олиферы Первая часть книги «Компьютерные Сети: Принципы, Технологии, Протоколы» - там объясняется принципы устройства сетей.
• Курячий и Маслинский, проект uneex.org - там вроде даже курс на Си есть.

Только поняв архитектуру ОС и основные части системы, а именно: Kernel, The Shell, Users and Groups, Single Directory Hierarchy, Directories,Links, and Files, File I/O Model, Processes, Memory Management, Static and Shared Libraries, Interporecess Communication and Synchronization, Signals, Threads, Process Groups and Shell Job Control, Sessions, Controlling Terminals, and Controlling Processes, Pseudoterminals, Date and Time, Client-Server Architecture, Realtime, The /proc File System.

Это 20 страничный Fundamentals Overview из книги Michael Kerrisk «The Linux Programming Interface» - вот после ознакомления со всеми вышеперечисленными понятиями есть смысл использовать Си как Си.

Главное учить не языки, а устройство ОС - это основной затык «студентов». Любая программа - это процесс с виртуальным адресным пространством, который имеет право перекладывать байты внутри выделенной памяти, и обращаться за услугами к OC через системные вызовы.

Вообще я бы по рекомендовал начать с методички Столярова 2006 года - как ликбез.

Успехов.

P.S.

Еще есть Youtube канал Дмитрия Кетова, где он ведет лекции по устройству Linux. Тоже рекомендую, грамотно объясняет устройство ОС. Как раз то, что нужно.

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

Золотые слова. Трудолюбие, терпение и дисциплина: сидеть читать и пытаться понять прочитанное.

Си – переносимый ассемблер!

Ещё одни Золотые слова.

Пост - чистое золото.

Ещё одни Золотые слова.

Ну это-то сказали задолго до меня. :) Просто, чтобы понять, насколько это глубокая истина, надо на обычном ассемблере пописать, а лучше на двух-трёх, разных архитектур. Вот тогда и приходит мысль, что «всё фигня, кроме пчёл».

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

про слакофагов напишу

Только поняв архитектуру ОС и основные части системы, а именно: Kernel, The Shell, Users and Groups, Single Directory Hierarchy, Directories,Links, and Files, File I/O Model, Processes, Memory Management, Static and Shared Libraries, Interporecess Communication and Synchronization, Signals, Threads, Process Groups and Shell Job Control, Sessions, Controlling Terminals, and Controlling Processes, Pseudoterminals, Date and Time, Client-Server Architecture, Realtime, The /proc File System.

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

Меня конкретно достала быстроменяющаяся сфера «Девопс» если так сказать. Да и само название размытое, в одной компании ты просто инфраструктурный код пишешь, оркестраторы. В другой как девопс дальше пайплайнов не полезешь. А еще тут любят часто завозить что-то очень модное и не совсем нужное

Тем, кто грустит по низкому уровню, предлагаю подхватить и реализовать мою идею о современном открытом КПК на одноплатнике с прошивкой а-ля PalmOS 5. Только прошивку я бы всё равно стал делать на Си, поскольку в 2025 году привязываться к процессорной архитектуре очень плохая идея. Си – переносимый ассемблер!

а почему не лисп? просто вот интересно :)

Меня конкретно достала быстроменяющаяся сфера «Девопс» если так сказать.

Да, DevOps - опошленное слово, потерявшее свой смысл, сейчас так зовут просто админов. Изначально это инженеры поддержки работоспособности систем SRE. Если классические разработчики это SWE, то те команды которые отвечают за работоспособность и функционирование Site Reliability Engineer.

https://sre.google/books/

На самом деле тема глубокая. И честно говоря во многом поинтересней SWE.

https://sre.google/sre-book/preface/:

Немного «распаковав» этот термин, прежде всего стоит сказать: SRE — это инженеры. Мы применяем принципы информатики и инженерии к проектированию и разработке вычислительных систем — как правило, больших распределённых систем. Иногда наша задача — писать программное обеспечение для этих систем вместе с коллегами из продуктовой разработки; иногда — создавать все дополнительные компоненты, которые таким системам нужны, например резервное копирование или балансировку нагрузки, в идеале так, чтобы их можно было переиспользовать в разных системах; а иногда — понять, как применить уже существующие решения к новым задачам.

Си – переносимый ассемблер!

а почему не лисп? просто вот интересно :)

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

а почему не лисп? просто вот интересно :)

Читайте Столярова. Он - гений методических объяснений. В форуме вам никто, ничего толком не объяснит. А вот Столяр в своем трехтомнике методично раскладывает по полочкам. У него есть целый раздел про Ассемблер в первом Томе Трехтомника, а во Втором Томе Трехтомника у него как раз разбирается Си.

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

Но Столяров именно в этих вопросах - дока, и на своем месте. Объяснить базу Асм, Си, UNIX API, TCP/IP - он это делает на 5+. Потом правда гонит лишка про высокий уровень, но это потом.

P.S.

И уже в конце, в 3 Томе, у Столяра есть глава про Lisp, S - синтаксис (вроде он так называется, гуглить не хочется). Так вот, с проработанным Асм+Си+UNIX_API от Столяра будет ясно, что Lisp сразу предлагает list как базовую абстракцию языка, а Cи предлагает условия и ячейки переменных.

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

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

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

А. В. Столяров. «Программирование: введение в профессию»

+ задачник Столярова.

У меня приличная библиотека книг, и порой я теряюсь с чего начать. Много книг дублируют друг друга. Для себя я выбрал простой критерий: если в книге есть вопросы после главы, то она в приоритете.

А Столяр отдельно добавил вопросы, да еще и ответы в отдельной книге, т.е. он по этой шкале в двойном приоритете. Хотя я все равно предпочту Tanenbaum и McKusick.

хорошая попытка, но у меня аллергия на цифровые материалы.

Как вы тогда собираетесь программировать с «аллергией на цифровые материалы»?

Выход один: распечатывать на принтере исходный код каждого git коммита и каждого diff. У вас достаточно высокие требования к процессу разработки, и их требуется компенсировать каким-то запредельным уровнем мастерства.

еще конечно лучше писать какие-то реально нужные программы, а не искуственные задачи с codewars и leetcode, …

Ложная дихотомия. Нужно делать и то и то. Ни какие «реальные программы» не заменят Leetcode. Так как 99.9% реальной программы это примитивная плоская обвязка «ядра» программы именуемая plumbing и прекрасно реализуемая LLM.

Научиться программировать можно только через Leetcode, решая замудренные задачи где требуется применить нужную Структуру Данных в подзамыленном описании. 1 год на Leetcode заменяет 10 лет в «реальном программировании». И Leetcode это первый шаг а System Design и Архитектуре.

Без Leetcode плоские циклы из разных книг по UNIX API будут восприниматься с трудом. А после 2-3 лет будут читаться с легкостью, как хорошая проза.

P.S.

Само собой без фанатизма, так как некоторые люди ничего кроме Leetcode не умеют. Но это фанатизм как есть.

P.P.S.

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

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

P.S. signed char и есть байт как бы.

Взять любую программу из тех что нравятся и начать её повторять, задачи вырастут как грибы. Используем гугл, чтобы посмотреть как решается задача, в чистом виде всё равно не будет, всё равно разбираться в коде. И полезно и результат сразу в копилку, в отличии от чего то бесполезного. Или наоборот, недостаёт какой то программы, начинаем её писать (GUI для rsync). Если вас надо уговаривать, чтобы писать, то это уже бесполезно, думаю никто не готов постоянно вас подталкивать и упрашивать.

Ладно, соглашусь с вами, но добавлю, может пропасть интерес, если не изучать ничего реального и не применять хоть какие-то навыки, на хоть какой-то реальной задаче, рецепт на мой взгляд такой, 30/70, где 70% изучение чего-то реального, 30 задачи с leetcode или codewars, ну ладно 35/65

Или наоборот, недостаёт какой то программы, начинаем её писать (GUI для rsync).

1. Основное преимущество Linux - возможность автоматизации процессов пользователем: CLI комманды соединяются вместе через конвееры и обмениваются текстовыми данными. Писать GUI под rsync - буквально уничтожать все преимущество Linux.

2. Невозможно читать не зная грамоты, прежде чем что-то переписывать, надо хотя бы выучить алфавит. А в Linux алфавит это системные вызовы и общая архитектура Kernel/Userspace, streams, pipes, streams redirections.

3. Читайте Столярова, какие истерики он бы не закатывал в форумах, базис в книгах он дает отличный. Его методичка 2006 года - это вообще золотой стандарт. Там по абзацу про все рассказано: режимы работы процессора, многозадачность, драйвера, азы использования UNIX. А желательно прочитать Трехтомник на 99% там все по делу.

P.S.

У меня просто холодеет от тех советов которые дают в форумах: это биться головой в пол и уйти не солоно хлебавши. Не понимая базовой архитектуры - что-то там воять, да еще и GUI - это путь вникуда. Сначала надо освоить CLI и программы фильтры c STDIN/STDOUT.

P.P.S.

По поводу Столярова, есть 10ки дублирующих книг. Но Столяр пишет для полного 0, т.е. не «выделываться», а взять и просто понять, что к чему. Остальные книги как правило уже подразумевают какую-то квалификацию. И пишет он хорошо.

P.P.P.S.

Совет писать rsync под GUI - это полное и тотальное не понимание принципов Shell автоматизации. Весь смысл rsync в том, что можно написать скрипт который будет автоматически по часам делать нужные бекапы, или делать бекапы по подключению диска. Весь смысл CLI - автоматизация рутины.

Или наоборот, недостаёт какой то программы, начинаем её писать (GUI для rsync).

Вы предлагаете «формошлёпить» - в этом нет ничего плохого. Но формошлепить выгодней на React или Darts или Vue. Формошлепить на С да еще и под Linux - тратить время в пустую, т.е. же яйца только в профиль, только окружение экзотическое. Если цель делать что-то без малейшего представления о внутреннем устойстве, то гораздо выгодней идти в реактивные фреймворки. Это все печально заканчивается, но если хочется эффектного старта - то пожалуйста.

Если уж изучать Си, то под задачи Си - это либо программирование микроконтроллеров. Либо системное программирование, а это индексные дескрипторы, файловые дескрипторы, виртуальное адресное пространство процесса, сеть. И shell с make как необходимое окружение.

Мне хочется завершить этот монолог на взвешенной ноте. Одно дело «учиться программировать» - да! тогда нужен быстрый результат. Другое дело «изучать язык Си» - тогда нужна базовая теоретическая подготовка в устройстве ОС.

Язык Си далеко не самый лучший язык для старта программиста, гораздо лучше высокоуровневые языки позволяющие почувствовать вкус к завершенным проектам - в самом самом начале. Но коли уже дошло дело до планомерного освоения профессии программиста, тогда Столяров или Таненбаум. А лучше вместе. И тут уж без Си не обойтись.

Но формошлепить выгодней на React или Darts или Vue.

На PureBasic.

Не понятно для чего TC именно Си. Для будущей работы или саморазвития.

На Си.

Непонятно для чего ТС именно PureBasic – ненужное проприетарное поделие. В этой теме этот язык – оффтоп.

В этой теме этот язык – оффтоп

Так же как и React или Darts или Vue.

Не понятно для чего TC именно Си. Для будущей работы или саморазвития.

У ТС здравое и похвальное желание стать инженером-разработчиком, он его оформляет в силу своей текущей компетенции «изучить Си». Автор поста обратился за помощью в сообщество, дело сообщества объяснить: вам нужно не столько Си, а понимание принципов устройства ОС которые описаны у Таненбаума и Столярова.

Си - это просто символ системного программирования для обывателя. «Хочу стать системным программистом - надо выучить Си» - это ошибка вызванная незнанием. Мне тоже казалось, что если я выучу С++ по книге Страуструпа то получу все необходимые знания. А на деле это книга про тонкости синтаксиса, а не про системное программирование. Книги по синтаксису Си/C++ как правило подразумевают, что автор прекрасно понимает как устроена ОС, что такое поток с процессом и так далее. Это ловушка для обывателя, он учит синтаксические ухищрения в место базовых понятий.

Вывод: Тема сложная. Упрощая. Надо «Литкодить на Python» - для алгоритмов, сидеть в CLI для общих навыков, читать Столярова+Таненбаума для понимания сути.

У ТС здравое и похвальное желание стать инженером-разработчиком

А где это можно прочитать от ТС?

В втором предложении заглавного поста этой темы, можно прочитать «между строк» чего хочет ТС. Также оценить его текущий уровень компетенции.

Давайте попрощаемся, у нас с вами общение явно не заладится. Всего доброго.

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

Изучай RUST - крась волосы в синий. Тем более если хотя бы на 50% пишут о RUST и M$, то знание C может и не пригодится, а ты уже ко всему приноровился.

А так, те кто утверждают что знают сишечку, пусть сначала покажут своё решение для дополнительной задачки под номером 1.23 из K&R 1977 (1.24 из второго издания).

Написать программу, которая удаляет все комментарии из программы на языке C.

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

А ключи лежат в других дисциплинах. Данная задача на курс лекций «Алгоритмы и Структуры Данных», а не на на курс лекций «Язык Си».

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

Это задача уровня Medium из Leetcode, изучается на 3ем курсе Вуза в курсе лекций «Алгоритмы и Структуры Данных».

Ты до конца задачу прочитай.

Ты до конца задачу прочитай.

«The C Programming Language» Brian W. Kernighan, Dennis M. Ritchie:

Exercise 1-24. Write a program to check a C program for rudimentary syntax errors unbalances parentheses, braсkets and braces. Don't forget about quotes, both single and double, escape sequences, and comments. (This program is hard if you do it in full generality.)

Прочитал. Суть моего комментария не меняется. Задача не про Си, а про базовый алгоритм отслеживания уровня вложения. Базовая задача Competitive Programming - но расширенная на несколько синтаксических маркеров: разные типы скобочек, комментарии, кавычки.

К чему ваш фейспалм? По ходу дела вы не понимаете, что вам пишут и путаете синтаксис с алгоритмами. Какую-то чушь заливаете «Кен Томпсон не знал Си до конца» (один из создателей Go) и в подтверждение своих слов даете задачу со звёздочкой на синтаксический анализ текста через стек. Как будто писать эту задачу на Lua или Ruby без библиотек будет чем-то легче, и синтаксис хоть как-то поможет. Сложность задачи не в синтаксисе, а в семантике зависимостей: «комментарии в кавычках» или «кавычки в комментарии».

Причём тут «Сишечка», как вы выражаетесь, когда в книге ясно написано, что книга не учебник программирования. И задача явно помечена как сложная в своей полноте.

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

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

Preface to the First Edition (Книга - не учебник программирования, Книга - учебник языка Си для программистов.)

...
The book is not an introductory programming manual; it assumes some familiarity with basic programming concepts like variables, assignment statements, loops, and functions.
...

Ваши комментарии очередной образец форумного невежества.

А как на счёт разделения труда в экономике? Приходите вы к сборщику мебели и говорите: ты сам что-ли в Сибирь ездил, сам ДСП клеил, или сборщику ПК заявите выпаивай давай микросхемы с материнки и заново запаивай, иначе ты не сборщик. Это как сборщику завести брёвна и сказать давай теперь собирай или сборщику ПК высыпать микросхемы в ладонь и сказать давай собери.
У человека есть объём информации в голове, как только начнёшь туда забивать что-то новое, то старое выветривается. Команда с разделением труда всегда обойдёт одиночек с многократным разрывом. В команде могут развиваться целые направления. Так что подход «а выучу как я язык ради…» потраченное без интереса и удовольствия время. Там же куча направлений, кто-то для проца команды придумывает, чтобы проц выжал максимальное и у него душа сама лежит к этому. Кто-то придумывает 3D-движки, где надо в совершенстве знать высшую математику (не просидеть на лекции, а знать). Кто-то связывает железяку с компом. Сборщик ПК может и желательно знать схемотехнику компа, но это его не основная задача, а даже не обязательная, знать схему и знать входной/выходной интерфейс не одно и тоже.

подтверждение своих слов даете задачу со звёздочкой на синтаксический анализ текста через стек

Не было такого. Товарищ luke просит решение задачи 1.24 на Си. Про стек уже ниже по треду lenin386 сказал, что это «элементарная задача на стек».

Задача, прямо скажем, не элементарная в своем полном решении. Но основывается она на элементарном алгоритме подсчёта уровня вложений, который дальше можно усиливать стеком заменив увеличение/уменьшение на push/pop.

Дело то не в этом. А в общем не понимании luke о чем он говорит.

1. Книга не учебник программирования.
2. Философия книги изучить язык можно только работая на нем.
3. Сама задача недвусмысленно помечена как сложная, и не требует полного решения.
4. Основное: задача и близко не про Си. Это просто полновесная задача оценки синтаксической верности. По простому Linter.

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

Это такая концентрированная бредятина. Что как-то мимо пройти совестно. «Один из создателей UNIX не понимает языка Си» - вы что там ацетоном на на нанюхались такое писать, господин luke.

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

Спасибо всем. Было интересно.

Дополню. Тут возникла небольшая путаница, вызванная тем, что в разных {пере,}изданиях «The C Programming Language» одна и та же задача фигурирует под разными номерами. В оригинальной книге она была под номером 1.23, а во втором издании – 1.24. Всех представивших свои решения стриггерило на задачу 1.23 из второго издания, и в этой задаче задание было – написать программу, удаляющую из текста программы на Си все комментарии. Эта задача проще, чем 1.24 из этого же издания, которая как раз и заключается в том, что нужно написать свой линтер (и это сложная программа, если писать её для общего случая).

for rudimentary syntax errors unbalances parentheses

ты даже скопировать не можешь без ошибок

Есть два издания. В первом 1.23, во втором 1.24. Если читать по-диагонали, то кажется, что это алгоритмическая задача на стек. Если же вдуматься, то что такое rudimentary syntax error? Это ж не только скобочки, кавычки, и комментарии, это могут быть и правильно расставленные точки с запятой, и запятые – тоже казалось бы rudimentary. В итоге эта задача именно на знание синтаксиса языка, а не алгоритмическая задача как тут талдычит lbvf50txt

ну бро эт мелько

по существу операторные скобки и прочие комменты и проч да и вообще язык блочный(ну с изысками строчно-ориентированности) так что та задачка(которая проще) реально проверка сбалансированности скобок нескольких видов с опцией возможного «исправления» что бы за один скан все(по возможности) дисбалансы пометить ибо «там» классический парсинг в глубину с возвратом ( top-down parsing) ll(1)

а так твоё замечание верно

да на знание языка

но исправление ошибок может быть через lr а может через ll разбор

в первом случае (более характерном для первого издания K&R) вы ещё более правы

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