Comments 61
На любом языке можно писать как на С. ;)
Возьму за пример джаву. Там конечно есть unsafe, например, для работы с памятью, но нигде еще не встречал, чтобы про него рассказывали на курсах, редко в какой книге о нем пишут.
К тому же, не уверен, что стандартная hotspot jvm дает прям настолько полный контакт с железом, без надстроек и jni, конечно же
На Java как раз таки пишут очень много кода "в стиле С". И дело тут не в unsafe.
Любое использование null — это код на С
Любое использование статических функций — это код на С
Любые классы с именами заканчивающимися на -er или -or — это на самом деле не классы а функции на С
И такого вот очень много в Java-мире, и пишут это все люди, которые ранее писали на С, но после перехода на Java не стали изучать как писать на Java а изучили только синтаксис.
Не смог перейти к оригиналу, возможно глюк мобильной версии. Предоставьте, пожалуйста, ссылку.
C заставляет глубоко прорабатывать решение проблемы
А в чём глубина приведённого решения на C? Больше кода вижу, отсутствие фукнций высшего порядка (которые как раз полезно изучать) вижу, решение не совсем той задачи, что на других языках, вижу. А вот глубины проработки — не вижу. Да и сама задача на особую глубину не претендует вроде как.
Язык С заставляет делать многое руками и писать высокооптимизированный код. [...] Как по мне, такое должен попробовать каждый профессиональный разработчик. Ну, как минимум, бэкендер.
Оптимизировать нужно то, что рабтоает медленно. В бекенде чаще всего медленно работает база данных (при этом нужно уметь оптимизировать запросы), ввод-вывод (часто помогает асинхронщина), HTTP запросы (можно оптимизировать пулы соединений, например). Опять же, причём тут C?
Если вы научитесь писать чистый код на С, то вам будет легче сделать это на другом, более простом языке.
Или наоборот.
Если вы научитесь писать чистый код на С, то вам будет легче сделать это на другом, более простом языке.
Или наоборот.
Та статья как раз про тех, кто не научился писать чистый код.
Из второго абзаца той статьи:
Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось.
Понятно, что с чего бы человек не начал изучение программирования, у него есть шанс в будущем научиться делать что-то другое хорошо. Но автор этой ^ статьи достаточно категорично заявляет о необходимости изучения C, а автор статьи по ссылке наоборот предупреждает о возможной опасности низкоуровневого программирования в начале карьеры.
Вообще непонятно, на каком основании автор этой делает заявления о чистоте кода. Чистый код на C значительно отличается от чистого кода на Java, Python или JavaScript. Более того, понятие о чистоте кода сильно варьируется в зависимости от области применения — математический код будет выглядеть ужасно для веб-программиста и наоборот. Да даже в двух соседних проектах одной команды из одной области структура и стиль кода может быть совершенно разный (пример — Scala как улучшенная Java и Scala как Haskell на JVM).
Тем более непонятно заявление о глубине знаний (или, о гспд, глубине проработки проблемы). У меня есть пара знакомых без технического образования (как раз из тех, кто хочет "войти в IT"), которые сейчас изучают Java и Python. Первый недавно потратил вечер на изучение дополнительного кода для представления негативных целых чисел, другой незадолго до этого спрашивал про линии кеша процессора. Они знают про инструкции процессора, стратегии работы с памятью, относительную скорость операций и т.д. Но при этом они в жизни не видели C, потому что для достижения цели он им не нужен.
betterprogramming.pub/why-every-developer-should-start-programming-with-c-39b3a87392bf
(не пишу в личку т.к. в корпортивных блогах исправления делают по 2-3 недели — если делают вообще. а читателям переходить к ориниалу нужно уже сейчас).
я делаю исправления сразу, не стесняйтесь писать мне в личку
У статьи недельной давности — habr.com/ru/company/macloud/blog/554650 около 6 тысяч. Не надо быть супер аналитиком чтобы понять, что большая часть просмотров и комментариев к статье в первые 4-8 часов после публикации.
Тем не менее у большинства авторов корп блогов на хабре стратегия — выложить статью и забить на фидбек на день, два, неделю или даже три. Да, некоторые отвечают на замечания в личку спустя три недели «спасибо, исправили!».
То что это мягко говоря «уже и нахрен не надо», думаю очевидно.
C заставляет глубоко прорабатывать решение проблемы
C мотивирует к написанию чистого кода
При этом вот код автора из его проекта:
github.com/neutralinojs/neutralinojs/blob/master/core-windows/src/server/requestparser.cpp
(т.к. neutralinojs указан им самим как его основная деятельность в личной информации, не думаю что это какой-то наколеночный проект которому он не уделял внимания)
void RequestParser::processChunk(const char *buf, size_t size) {
char c;
size_t i = 0;
c = buf[i];
for(; i < size; ++i, c = buf[i]) {
if(c == '\r') {
half_end_of_line = true;
goto next_iter;
} else if(half_end_of_line && c == '\n') {
if(end_of_line) {
headers_available = true;
} else {
if(!first_line) {
headers[tmp_header_name] = tmp_header_value;
tmp_header_name = "";
tmp_header_value = "";
}
end_of_line = true;
first_line = false;
goto next_iter;
}
}
if(first_line) {
static int field = 0;
if(beginning || end_of_line) {
field = 0;
}
if(c == ' ') {
field++;
} else {
switch(field) {
case 0:
method += c;
break;
case 1:
path += c;
break;
case 2:
proto_ver += c;
break;
}
}
} else {
static int field = 0;
if(end_of_line) {
field = 0;
}
switch(field) {
case 0:
if(c == ' ' && previous_char == ':') {
tmp_header_name.pop_back();
field++;
} else {
tmp_header_name += c;
}
break;
case 1:
tmp_header_value += c;
break;
}
}
half_end_of_line = false;
end_of_line = false;
next_iter:
previous_char = c;
beginning = false;
/* --- begin extended code for body parser --- */
if(c == '\n' && prev_char == '\r') {
if(i+2 < size) {
if( buf[i+1] == '\r' && buf[i+2] == '\n' ) {
beginbody = true;
}
}
}
if(charcount == -1) {
auto size_it = headers.find("Content-Length");
if(size_it != headers.end()) {
charcount = stoi(size_it->second);
}
}
if(headers_available && method == "GET") { // GET request
parsingDone = true;
}
if(beginbody) {
body += buf[i];
if(charcount == body.size()) {
parsingDone = true;
}
}
prev_char = c;
/* --- / end extended code for body parser --- */
}
}
Чет лично я не вижу никакой чистоты кода
(да, это синтаксически С++, но лично я не вижу тут именно идиоматически «плюсов», думаю вполне подходящий пример).
К сожалению проектов на C у автора не нашел :)
В отличие от современных языков программирования, для реализации тех же задач на C вам придётся писать в разы больше кода.
Чем старше становишься — тем ленивее все писать заново. С наличием языкового сахара и хороших библиотек концентрируешься уже больше на сути «написуемой» программы.
Смешивать эти две категории и советовать какие-то общие вещи — несусветная глупость.
Для «студента» не зазорно обучение начать не то что бы с С а даже с Паскаля и с ассемблера, у «свитчера» же такой роскоши нету.
По итогу так и не понял, в чем был плюс такого варианта (предполагаю, что единственная причина — не делать отдельный курс на Java), тогда основ С из курса хватило, чтобы понять, о чем речь в курсе по алгоритмам, но в итоге и С забылся, и алгоритмы пришлось вспоминать заново, уже с решениями на Java.
Предполагаю, что опытному разработчику при необходимости изучить дополнительный язык будет значительно проще, чем новичку сначала учить С, а потом уже учить тот язык, который он хочет использовать в работе.
C мотивирует к написанию чистого кода
Это не так, проект написанный на Си, код которого можно назвать чистым — очень большая редкость.
C заставляет глубоко прорабатывать решение проблемы
Тут скорее борьба с самим языком, чем проработка решения.
Если вы научитесь писать чистый код на С, то вам будет легче сделать это на другом, более простом языке.
Если вы в принципе научитесь писать чистый код вне зависимости от языка, то будете это делать на любом языке.
Язык С заставляет делать многое руками и писать высокооптимизированный код.
Не многое, а всё нужно делать руками, обобщённое программирование там просто ужасно, макросы в макросах и не дай бог где-то ошибёшься, искать ошибку будешь вечность и отлаживаться не получиться. А вот высокооптимизированный код писать получится только спустя не один год практики, потому-что оптимизация начинается с архитектуры.
Почему стоит начать изучение программирования с языка C
А почему не с ассемблера? Хотя бы на уровне erfaren.narod.ru. Кстати, «народный» дизассемблер IdaPro, Ильфака Гильфанова, позволяет переводить ассемблерный бинарный код, типа dll и exe-файлов, в Си код.
Тем не менее, я лично предпочитаю С++, поскольку на этом языке можно проще и удобней организовать модульность. Для примера возьмем опенсорсный консольный видеопроигрыватель FFPlay.c и пробуем его внедрить в собственное оконное приложение. Я, лично, пока не перевел этот код в классы, не мог решить подобную проблему.
С другой стороны, Си-код SQLite ни в какие классы переводить не нужно. Оно и понятно, это не оконное приложение, а консольное, поэтом просто внедряем его в свой С++ проект и все прекрасно работает без «напильника».
Короче говоря, для общего развития, ассемблер и Си нужны, но не более. Для серьезной работы хорош С++. А для разовой подготовки (обработки) данных очень эффективен Питон и другие скриптовые языки. Однако краеугольным камнем программирования я считаю С++.
потому, что не стоит
Важно, чтобы ты попробовал писать на нескольких разных языках и понял их преимущества и недостатки.
Категорически не согласен почти со всей статьёй.
Не надо учить Си первым языком, если есть выбор! Первый императивный язык нужен для того, чтобы научиться работать с переменными, массивами, абстракциям (функции, объекты) и прочая, прочая, прочая. Чтобы было интересно этим заниматься, лучше, если проблемы будут возникать где-то в районе "как формализовать вот этот кусок предметной области?", а не "откуда взялся очередной UB?".
Как научились — можно либо лезть вниз (в том числе в Си), либо вверх (к какой-нибудь предметной области).
C заставляет глубоко прорабатывать решение проблемы
Нет, он заставляет детально расписать происходящее поближе к железу (а точнее — к виртуальной машине Си, привет от модели памяти), причём покороче, чтобы посвящённым меньше символов набирать. Это не то же самое, что "проработать решение проблемы".
Посмотрите на некоторые куски стандартной библиотеки: заточено под UNIX (сигналы?) и null-terminated строки в однобайтовой кодировке (причём даже с кодами 0-127, привет от знакового char и падающего на отрицательных числах isdigit). Это ещё о локалях не говорим. Это активно создаёт видимость, что мы решили проблему, воспользовавшись стандартной atof (и огребя от локалей), strstr (и огребя от ненормализованного юникода), tolower (и огребя от неоднобайтовых символов).
Никаких требований "подумать о проблеме" язык не выдвигает — что хочешь, то и пиши. Не угадал, что написать — получил поддых. В отличие от, например, Rust, где даже по строчке проитерироваться нельзя, не сказав явно, что именно надо — байты, code units, grapheme clusters. Вот это я бы назвал "заставляет глубоко прорабатывать".
Кстати, разработчики, участвующие в соревновательных хакатонах, часто тренируют этот скил, решая нестандартные задачи как раз на C.
Полагаю, что автор подразумевает всякие олимпиады по программированию. Тогда я считаю, что у меня есть некоторый опыт, чтобы ответственно заявить: фигня полная, на соревнованиях пишут на C++ и Java. Никто не пишет самостоятельно динамический массив или словарь, берут std::vector<> и std::map<>. А вот где встроенных абстракций не хватает — там пишем свои. Благо, таких задач хватает, и свой вектор там — скучнейшая часть.
C позволяет прикоснуться к «низкоуровневому» программированию
Автор сам пишет: "Как по мне, такое должен попробовать каждый профессиональный разработчик.". Согласен, должен попробовать. Но не первым языком, а дальше, когда уже не путаешься в отличиях цикла от условного оператора.
Компиляторы C при должной оптимизации создают невероятно быстрый ассемблерный код.
Придирка: если только вы не пишете интерпретатор.
C мотивирует к написанию чистого кода
Каким именно образом? Больно бьёт палкой за некоторые виды ошибок, иногда через полтора часа после запуска программы, а за некоторые не бьёт (утечки памяти)? Так себе методический приём. Нет чтобы линтеры запустить (есть для любого языка) или на этапе компиляции какие-то ошибки управления памятью ловить.
и переход от С к С++ будет органичным и почти мгновенным.
Это два принципиально разных языка с разными стилям написания кода и библиотек! Не будет никакого мгновенного перехода, будет сишный код в файле с расширением .cpp.
Не надо учить Си первым языком, если есть выбор!
Если выбор между С и Pascal — лучше C :)
Во первых, С-подобный синтаксис встречается чаще чем паскале-подобный. Во вторых, научиться не стрелять в ногу с помощью С — это полезное умение.
Если б оно ещё и стреляло стабильно… Но debug-режим, sanitizer'ы и Valgrind тут, конечно, сильно помогают.
А как может такое получиться, что выбор только из них? В смысле, в нормальных условиях (не будем брать условную школу, где есть проблемы с преподавателями информатики, которые сами толком ни одного языка не знают)?
Во вторых, научиться не стрелять в ногу с помощью С — это полезное умение.
И чем именно полезно? Это же совершенно непереносимый навык.
Умение отлаживать систему, которая умеет либо полностью работать, либо иногда необъяснимо падать с вероятность 1% в непонятном месте вполне переносимо с сишного UB на многопоточные приложения, распределённые системы и области с большими данными. Например, какие-нибудь сложные алгоритмы могут упасть после недели работы. Или если у вас десяток тысяч серверов и какая-нибудь коллизия хэшей с вероятностью 0.001% (а из-за масштабов каждый час что-нибудь да падает).
Скорее даже не умение отлаживать, а умение такое писать: чётко следовать заданной модели, не применять "очевидные рассуждения" на самом деле выходящие за рамки модели (вроде "очевидной" sequential consistency) и, когда всё-таки случилась беда, не пугаться происходящего безумия.
И чем именно полезно? Это же совершенно непереносимый навык.си как раз замечательно переносимый, не просто так его «переносимым ассемблером» окрестили. Просто не все умеют писать на переносимых сях переносимый код.
Не надо учить Си первым языком, если есть выбор! Первый императивный язык нужен для того, чтобы научиться работать с переменными, массивами, абстракциям (функции, объекты) и прочая, прочая, прочая.честно говоря, тоже не согласен. Выучить высокоуровневый язык начав с си довольно-таки просто. Ну, только иногда будет пригорать от динамической типизации. А вот всякие питоны/жсы ну никак не помогут выучить работу с памятью. В итоге получится разработчик, который не понимает почему написанный им код тормозит, и которому будет в разы сложнее переквалифицироваться.
Единственный нюанс — начинать изучать программирование с работы с памятью… скучно. Поэтому на мой взгляд идеальным вариантом будет начать курсом условного питона (базовая алгоритмика), потом продолжить си (работа с памятью, алгоритмы и структуры данных), а уже потом джава/шарп (для изучения паттернов проектирования). Жаль только на нормальную проработку такого варианта у большинства вузов нет ни часов ни квалификации преподавателей.
Инструктор рассказывает вам, что такое автомобиль, что такое дорожные знаки, где газ, где тормоз, что будет, если нажать эту кнопочку, что будет, если этот рычажок. Затем постепенно вы ездите вдвоём по городу, учитесь правильно поворачивать, а затем вам рассказывают, как вести себя при аварии и в аварийно опасном моменте.
Вас садят в гоночный автомобиль и говорят проехать трассуя менее, чем за две минуты. За вопросы, что это за стрелочка, вас бьют по голове и отправляют учить матчасть, а в случае столкновения вы можете погибнуть.
Когда-то давно я начинал учить Си и Питон примерно в одно время. И это мои эмоции от каждого из них (угадайте, где кто). Когда ты пытаешься понять, что такое функции, то тебе совершенно не до того, что звёздочка означает указатель, а тот факт, что передать двумерный массив[m][n] можно как можно как одномерный массив[m*n] (и это проще сделать, чем передавать его в двумерной виде), ломает тебе мозг и желание программировать. А замена простого array.length выражением типа sizeof(array_of_int) / sizeof(int) радости этому всему не добавляет. Есть кривая обучения, и если для питона она пологая, то для Си тебе нужно одновременно изучать Си, компьютер, алгоритмы, работу с памятью, дебаг и трассировку.
Несколько лет изучая питон, я понял и внутреннее устройство компьютера, и работу компиляторов/интерпретаторов, и научился гуглить проблемы и догадываться об их причинах, но когда я только начинал, то всего этого я не знал. Заставьте выйти из вима того, кто про линукс не слышал. А вот саблайм он закроет без проблем.
Нет. Всё что можно написать на С++ можно написать на Си — он же низкоуровневый… Зачем мне классы если есть структуры? Да и без структур можно. В результате нет стимула двигаться вверх, а там много полезного/экономящего время.
Cи мотивирует к написанию чистого кода
Такое может сказать только человек, который сам на Си ничего не написал. Это по автору, кстати, видно. Куча пустых, ни на чём не основанных уверждений. Но вернёмся к чистому коду. В реальности код на Си — это хак на хаке и хаком погоняет. В Си простые вещи делать достаточно непросто. В следствие этого, рано или поздно программиста задалбывают сложности, и он начинает искать кратчайшие пути к достижению цели. Вот один пример из моей практики: я работал с человеком, который написал небольшой фреймвок для логирования событий на Си. События ассоциировались с неким контекстом, собиралась статистика, и прочее. На нормальном языке программирования, например, Питоне, вы бы сделали with EventContext() as ctx: .... Но это Си. В нём подобная конструкция разворачивается в выделение памяти, явное по-элементное инициализирование структуры, указатель на которую надо где-то хранить и передовать в каждую функцию, где будет совершаться логирование, а в конце память нужно будет освободить. Как вот этот человек решил, хрен со всем этим — я сделаю контекст статической переменной! По сути, он пришёл к анти-паттерну синглтона, потому что нормальная организация работы с объектами в Си — это много кропотливой работы. И вы думаете, это единственный пример. Такого полным-полно практически в любом коде на Си.
В этом случае эти два языка можно учить параллельно, но они в какой-то момент «пересекутся» — и переход от С к С++ будет органичным и почти мгновенным.нет, нет, нет, и нет! Худшее, что можно сделать с будущим разработчиком — пытаться учить его одновременно с и с++. В итоге он не может ни писать на плюсах (потому что «си с классами» очень не приветствуются в адекватных кодобазах), ни на си (потому что уже привык опираться на некоторые плюсовые фичи).
Для примера: как часто приходится применять решения олимпиадных задач в бизнесе, если и часто, то какой процент разработчиков это затрагивает?будет обидно, если нетривиальная задачка таки возникнет, и никто в вашей команде не сможет её решить?
А если ваш стартапчик с рокстарами разорится — обидно не будет, я так понимаю? Будет очередное "мы пилили очередной мегапродукт, делающий всем хорошо, вот только несправедливый жестокий мир его подкосил"?
Да нет, это вы смешиваете. У вас выше — нерешаемая "нетривиальная задачка", а тут вдруг попёрла куча других интересных людей совсем не по этой части. "Нетривиальные задачки" в бизнесе бывают нетривиальны самыми разными путями, и совсем даже не все из них решатся, если вдруг у кого-то есть "база" и он может чё-то там накодить на С. Люди, которые (обычно) успешно решают нетривиальные задачки бизнеса, связанные с кодом — это именно "звездные программисты", а не люди, у которых могучая база знаний основ С.
А вот база никуда не денется.
… и точно так же может быть почти совсем невостребованной после "банальной смены места работы". Ну впрочем можно зато проходить собеседования в конторы, которые упарываются по алгоритмам, это да.
… и точно так же может быть почти совсем невостребованной после «банальной смены места работы»вы наверно сможете привести пример, когда при смене работы базовые знания теряют актуальность?
Ну понятненько, "если будет такая задача, которую будет сложно впихнуть в железо, то вот тут-то всё и пригодится!". Действительно, если проблема в гвоздях, а у вас чисто случайно в руках молоток — то всё складывается просто отлично. Кто бы сомневался.
вы наверно сможете привести пример, когда при смене работы базовые знания теряют актуальность?
Вы понимаете, в чем разница между "не востребовано" и "потеряло актуальность"?
Ну понятненько, «если будет такая задача, которую будет сложно впихнуть в железо, то вот тут-то всё и пригодится!»самый простой пример — бекенд на AWS или подобных. Чем больше CPU/RAM/диска жрет ваш сервис, тем больше вы платите за это железо. Пока у вас единицы мелких контейнеров, проще закидать проблему железом. А когда сотни/тысячи, оптимизация внезапно становится чертовски выгодной.
Вы понимаете, в чем разница между «не востребовано» и «потеряло актуальность»?это не имеет значения если у вас нет примера.
Новичка необходимо вводить в мир программирования с простого.
Переменные, циклы, условия, да? Совсем как в С ;) На простых уровнях С очень простой язык.
начинать путь с высокоуровневых абстракций, библиотек, фреймворков
Лучше бы с алгоритмов. Библиотеки с фреймворками — в одних языках одни, в других — другие, за время изучения что-то устареет, что-то выпустят новое…
Переменные, циклы, условия, да? Совсем как в С ;)
Следующий обязательный шаг и популярная абстракция — массивы и строки — уже убьёт всех начинающих программистов на Си из-за а) неопределённого поведения при выходе за границу; б) необходимости руками возиться с памятью.
Лучше бы с алгоритмов. Библиотеки с фреймворками — в одних языках одни, в других — другие, за время изучения что-то устареет, что-то выпустят новое…Верно подмечено про устаревание!
Переменные, циклы, условия, да? Совсем как в С ;)
Про типы данных вы случайно забыли, да? Что вы там накодите простого и интересного, не приближаясь к строкам и спискам? Числа Фибоначчи посчитаете?
А по статье — так ведь Rust все эти пункты выполняет намного лучше!
Почему стоит начать изучение программирования с языка C