Comments 47
TL:DR нейросетевой бред. Или не нейросетевой, но тогда это писал школьник с уровнем знаний "оооо в си есть указатели", а не человек с 20-летним опытом на Си.
нужно видеть разницу между системным и прикладным программированием. Если у вас завис браузер (прикладное ПО), вы его просто перезапустите. Но если «упал» сервер СУБД в момент банковской транзакции — это катастрофа.
А вы точно понимаете разницу между системным и прикладным ПО?
меня бесило, что массивы из 100 и 200 элементов — это разные типы. Я пожаловался другу, он посочувствовал и сказал: "А вот в С по-другому".
Ну как сказать... Оба типа кастуются в C к обычному указателю в ряде случаев, но эти типы всё равно разные, и слава богу.
void accept_100(int (*arr)[100]) {}
int main(void) {
int arr100[100];
int arr200[200];
accept_100(&arr100); // ok
accept_100(&arr200); // error: passing argument 1 of ‘accept_100’ from incompatible pointer type
return 0;
}
получается, что у утки шасси не выпускаются. И это ловушка эволюции
То есть в правильной иерархии классов утка должна выпускать шасси? Идиотский пример.
Пока ИИ умеет выполнять только самые базовые задачи в программировании, например переложить данные из одного массива в другой по заданному правилу.
Я конечно ИИ-скептик, но мне всё-таки кажется, что на сегодняшний день возможности ИИ в программировании мягко говоря немного больше.
нейросетевой бред.
С большой долей вероятности нейронка не причислила бы Кернигана к «создателям» Си:
«Язык программирования Си» от создателей С Брайана Кернигана и Денниса Ритчи.
Ох, простите, промахнулся - вместо +. Потому напишу текстом что зашёл в комменты чтобы написать почти точно по тем же пунктам, или поддержать того, кто , вероятнее всего, напишет раньше. "Автор" вообще читал что у него получилось?
Нужно понимать, что С — язык для системного программирования
Зачем в системном программировании такие штуки как SDL? Разве скриптование Unreal - системное программирование?
Чаще всего С ругают по двум причинам: за указатели и за то, что нет автоматического управления памятью.
Скорее за то, что система сборки сложнее самого языка. И за то, что С с Qt не дружит.
Если нравится строить абстракции — это C++
С++ помогает строить одни абстракции и мешает строить другие. А С ничему не помогает и ничему не мешает.
Чего в статье не хватает, так это замечания что как ни FFI, так к С.
Так это претензии к системам сборки - они все неадекватные какие-то. А на Qt тоже свет клином не сошелся.
Зачем передёргивать? Системы сборки такие, какие получились для конкретного языка. Что там курица и что яйцо - вопрос философский, а сама логика - царь хороший бояре плохие. И на Qt свет таки сошёлся клином - что ещё работает почти везде и поставляется с IDE которая собирает apk мяу не сказав? Для С есть SDL - сравнение с Qt как раз и позволяет выдвигать претензии.
С какой IDE, причем тут IDE, зачем вообще IDE? Системы сборки всегда стараются делать как раз НЕ зависимыми от конкретного языка. Причем тут низкоуровневой SDL, который надо сравнивать скорее с libxcb или Win32 API, нежели высокоуровневым Qt, для которого тоже полно альтернатив "почти везде", хоть GTK, хоть Tcl/Tk ? В общем, коммент из сугубо узкой личной ниши.
IDE при том, что царь хороший а бояре плохие не катит. Язык и инструменты - единое целое от которого и зависит как далеко и в совокупности их пошлют. Это относится и к системам сборки и к IDE одинаково. Как пример, Rust - омерзительно медленный туповатый компилятор, причём они это сами знают и как раз сейчас borrow checker переделывают, не рабочий без unsafe что перечёркивает весь маркетинг - ан нет, народ повёлся, много пишет и переписывает, что на октаву ниже только с Go и наблюдается, и по большей части удачно. Почему? Cargo.
SDL при том, что для С ничего другого толком и нету. А для С++ есть… А что тут, рядом с гордой кроссплатформой, делают чисто десктопные ничтожества GTK и Tcl - то только красноглазым энтузиастам и ведомо.
На машинах "которые занимали целые залы" бы ассемблер ЕС, PL/1, Fortran. С был уже на СМ-ках, настольные ЭВМ с портированной операционной системой УНИХ, правда под другим брендом...
Точно! Ибо серия СМ ЭВМ (те, которые в архитектуре DEC PDP) — родной дом Си.
На мейнфремах EC была Мобильная операционная система (МОС ЕС) - портированный unix с Си конечно же. Кроме того на EC был и компилятор Си вне какого либо unix. Знака фигурных скобок не было на стандартной клавиатуре терминалов EC-7920, поэтому вместо него набирали сочетание из двух знаков.
https://ru.wikipedia.org/wiki/Триграф_(языки_Си)
Триграфы до сих пор поддерживаются компиляторами
??=include <stdio.h>
int main()
??<
printf("hello, world!\n");
??>$ gcc -trigraphs hello_world.c
hello_world.c:1:1: warning: trigraph converted to '#' character [-Wtrigraphs]
1 | ??=include <stdio.h>
| ^
hello_world.c:4:1: warning: trigraph converted to '{' character [-Wtrigraphs]
4 | ??<
| ^
hello_world.c:6:1: warning: trigraph converted to '}' character [-Wtrigraphs]
6 | ??>
| ^
3 warnings generated.Совершенно верно. Но два символа легче набирать чем три) По 2 символа имеют диграфы. В стандарте Си с середины 90-х. Но начали использовать 2-х символьные сочетания для фигурных скобок в Си еще раньше (известные мне случаи на ЕС ЭВМ - во второй половине 80-х)
Работы нет для сишников. А те вакансии, которые висят на хх.ру или хабр.карьере, не закрываются по несколько месяцев, как будто они фейковые
Забей там инженер-программист, работы полно, толковых мало
В Embedded широко распространен Си и толковых разработчиков там днем с огнём не ссышешь.
Там же проблема больше не в знании Си как таковом, а в инженерно-техническом понимании этого самого Embedded.
Проблема там в оплате. Эмбедщикам никто не хочет платить и самые толковые ушли в другие сферы.
Ну это везде сейчас проблема - дефицит восокопрофессиональной низкооплачиваемой рабочей силы. Конкретно в этой сфере проблема в том, что есть понимание что "менее толковых" лучше не набирать ибо потом вообще не разберёшь.
Не, я не про сейчас, а вообще.
Формошлёп всегда получал в среднем больше эмбедщика, к сожалению, по крайней мере в РФ. Хотя скиллы не сопоставимы.
На западе немного более выровнено, если не считать фаанги.
Причины мне не очень понятны, но скорее всего просто нашему рынку не особо нужны они т.к. электроники своей мало очень.
Коммерческий embedded это очень низкомаржинальная область. Прошивки обычно не сложные и 70% стоимости конечного девайса составляет стоимость железа на котором прошивка исполняется. Большие сроки разработки, от дизайна до устройства на рынке 1.5-2 года. Окупаемость серии от 10тыс устройств. Высокий риск что партия не взлетит, все это приводит к тому что в embedded экономят на всем,пытаясь хоть как то снизить финансовые риски. Embedded в России способно выжить только в наукоемких отраслях - оборонка, атомка, медтех(там где стоимость прошивки превышает в разы стоимость железа на котором она исполняется).
Вот для меня в глубине души C++ так и остался объектным расширением С. Интересно, сейчас код на С можно скомпилировать С++ компилятором?
Вот для меня в глубине души C++ так и остался объектным расширением С.
Как и для большинства программистов, которых я знаю.
Технически компилятор C и компилятор C++ это одна и та же программа, которая просто запущенна с разными опциями. Но скомпилировать C код в режиме C++ скорее всего не получится, ибо C++ не позволяет некоторых вольностей C, вроде молчаливого неявного преобразования указателей.
Зависит от вашего стиля кода. Я приловчился, так пишу, что в 99% можно. Но и мой C++ в результате очень олдскул :)
Сильно повеселил пассаж про Паскаль. Я могу с таким же успехом сказать, что меня в Си бесит большое количество вложенных фигурных скобок. Всё это чистая вкусовщина. Если взять две однотипные реализации языков, скажем, турбо хх, то они совершенно эквивалентны. И было бы странно, если бы это было не так. Другое дело, эстетические соображения. Но они у каждого свои. Я в своё время предпочитал Паскаль, но если заказчик просил Си, то переписывал на нём. Все были довольны.
C++, мне не очень нравятся
А мне, наоборот, С++ нравится больше, чем Си. На Си любят писать консольные программы, а на С++ – оконные. Соответственно статьи по Си – редко содержат картинки программ, разве, что просто изображения себя любимого.
Хотя, оконные программы на Си тоже есть. Например, консольный видеопроигрыватель FFPlay.c. Но, вот, прилепить его к своей оконной программе – с разбегу не получится. На Гитхабе, я так и нашел, хорошего прототипа. Поэтому, поступил проще. Преобразовал Си-код проигрывателя в классы С++ и подключил, без особых проблем, к своей оконной программе «МедиаТекст» на С++ / WTL (см. скриншот: http://scholium.webservis.ru/Pics/MediaText.png ).
Так что, как говориться: «На вкус и цвет – товарищей нет!».
Самый страшный страх сишника:
Мне не хватает шаблонов.... (но)
...это будет начало конца: сразу добавится метапрограммирование и другие усложнения.
Боязнь острого ножа, а то вдруг порежусь
Кстати, дженерики-то уже и в С завезли..
А подробнее?
https://en.cppreference.com/w/c/language/generic.html
Оно, конечно, такое же кривое, как и modern C++, но есть.
это не дженерики, это свич по типу
Ну "боязнь" вполне оправдана - посмотрите что сейчас творится с C++ и его метапрограммированием. Я писал на плюсах довольно долго, и мне очень нравились лекции Констатина Владимирова, где понятны концепции которые преследуют разработчики. Но в реальных проектах все эти замысловатости могут добавлять скрытых проблем и приводит к удорожанию стоимости поддержания кодовой базы. В моей практике "явное лучше неявного" при написании кода.
В C есть макросы, бывают трехэтажные и более. Еще хуже шаблонов.
Я пишу на чистом С, и у меня есть соответствующий свитер ))
сидеть и разбираться в низком уровне, спокойно и без спешки.
Интересно где такая работа есть(чтоб спокойно и без спешки) ?) И чтоб за это ещё и хорошо платили
Извините, но статья ни о чём, неинтересная и непонятно, кому нужная.
А в результате цепочки наследования получается, что у утки шасси не выпускаются
Так ну не пишите через одно место, и надуманные проблемы перестанут возникать.
Но если «упал» сервер СУБД в момент банковской транзакции — это катастрофа.
А сервер СУБД - это каким боком системное ПО?
Он создан для оптимизации, для выжимания из «железа» максимума.
Вы не знаете, для чего создавался C? Он создавался, как переносимый ассемблер, а не "выжимание". Для "выжимания", точнее просто прямого программирования железа, уже был... ассемблер.
Идеальный баланс
Баланс для чего? Это как сказать, что у гречки идеальный вкус.
Чаще всего С ругают по двум причинам: за указатели и за то, что нет автоматического управления памятью.
Кто эти люди? Проблемы действительно надуманные, но, кажется, не ругающими (если они хоть что-то понимают), а автором. Указателей в C не может не быть, потому как это самый простой способ получить indirection; автоматического управления памятью там, наоборот, быть не может, потому что кто будет управлять управляющим?
А вот моя статья на хабре про курс по С с детективным сюжетом для самобучения.
в частности C++, мне не очень нравятся: объекты загоняют в рамки, начинаются игры в абстракции
C++ язык с поддержкой множества парадигм, поэтому в какие рамки загоняться решает каждый сам для себя
Профессия программист С: плюсы, минусы и нужен ли свитер