Разработка базы данных Oracle началась в 1977 году (тоже на ассемблере) и тоже была переписана на С в 1983 году. К тому времени это был уже один из самых популярных языков в мире.
В 1985 году вышла Windows 1.0. Хотя код операционной системы Windows не является открытым, общеизвестно, что ядро в основном написано на С с небольшими вставками ассемблера. Разработка Linux началась в 1991 году и началась сразу на С. В следующем году она была опубликована под лицензией GPL и использована как часть GNU Operating System, которая и сама начиналась как проект на С и Lisp, так что многие компоненты были написаны на С.
Но проекты на С — это не только то, что стартовало десятилетия назад, когда выбор языков, скажем прямо, был достаточно ограничен. Много С-кода пишется и сейчас, на нём начинаются и новые проекты. Для этого есть причины.
Как именно язык С управляет миром?
Не смотря на современную тенденцию к использованию высокоуровневых языков, фундамент мира ИТ всё ещё держится на языке С. Вот лишь некоторые из систем, написанных на С и ежедневно используемых миллионами людей.
Microsoft Windows
Как уже говорилось выше, ядро Windows — это в основном код на С. Можно по-разному относится к этой операционной системе, но уже несколько десятилетий она занимает наибольшую долю рынка десктопных ОС.
Linux
Linux тоже написано большей частью на С. 97% всех суперкомпьютеров мира работают на Linux. Неоспорима его большая доля на рынке серверов, а кто-то использует его и на десктопе.
Mac
Вы не поверите, но и третья «большая» ОС в нашем списке тоже написана на С (по крайней мере её ядро).
Драйвера
Когда мы говорим о драйвере устройства, не важно под какую операционную систему, в абсолютном большинстве случаев мы говорим о коде на С.
Мобильные ОС
Ядра iOS, Android и Windows Phone тоже написаны на С. По сути они являются мобильными адаптациями уже существовавших ранее ядер Mac OS, Linux и Windows. Так что прямо сейчас в вашем кармане работает С-код.
Базы данных
Все наиболее популярные базы данных в мире (Oracle Database, MySQL, MS SQL Server, PostgreSQL) написаны на С (некоторые — на комбинации С/С++). Базы данных используются во всех типах систем: финансы, медиа, телеком, здравоохранение, образование, продажи, веб и т.д. Если вы не живёте на необитаемом острове — вы сталкиваетесь с системами на базах данных (и, как следствие, с работой кода на С) ежедневно.
Графика, видео, спецэффекты
Современный кинематограф создаётся в основном специальным ПО, предназначенным для этого. Высоконагруженные системы, от которых требуется обрабатывать огромные массивы видеоданных, часто пишутся на С и С++. Чем эффективнее будет код — тем быстрее будет получен результат, тем больше возможностей откроется перед художниками и аниматорами по доводке деталей будущего киношедевра. И тем больше денег сэкономит кинопроизводитель.
Embedded-разработка
Просто вспомните свой обычный день. Вы просыпаетесь от будильника (который, возможно, управляется микроконтроллером с кодом на С). Затем ваша микроволновка (тоже с микроконтроллером) разогревает ваш завтрак. Вы наливаете кофе из кофеварки (ну, вы уже поняли). За завтраком вы включаете телевизор или радио (снова embedded железо и код). Дальше вы открываете дверь гаража (с пульта). Очень большая часть кода во всех вышеперечисленных устройствах написана на С.
И вот вы добрались до своего автомобиля. В нём работают (и, скорее всего, написаны на С), следующие системы:
- управление автоматической коробкой передач
- система определения давления в шинах
- сенсоры
- сохранения положений сидушек и зеркал
- экран бортового компьютера
- сигнализация
- система электронной стабилизации
- круиз-контроль
- климат-контроль
- зажигание без ключа
- обогрев сидений
- подушки безопасности
… этот перечень может быть сильно расширен в зависимости от навороченности вашего авто.
Каждый день вы сталкиваетесь с банкоматами, кассовыми аппаратами, светофорами, системами контроля доступа, видеонаблюдением — везде микроконтроллеры, везде код на С.
Почему люди всё ещё пишут на С?
Сегодня есть множество языков программирования и многие из них, скажем прямо, позволяют писать код быстрее и легче, чем на С. Высокоуровневые языки дают нам отличные инструменты для абстракций, богатые стандартные библиотеки, работу с разными форматами данных «из коробки», легкий доступ к сети и вебу, к базам данных и т.д.
Но, не смотря на всё вышеперечисленное, есть причины, по которым код на С всё ещё работает и будет работать ещё долго. В мире разработки ПО нет «серебрянной пули», нет одного языка, который закрыл бы все ниши. В некоторых сферах С всё ещё предпочтительный выбор, а в некоторых — вообще единственный возможный.
Комбинация портируемости и эффективности
С разрабатывался как «портируемый ассемблер». Он так близок к машинному коду, как только это возможно, но всё же он — не машинный код. Есть как минимум один компилятор С под вообще любую существующую в мире процессорную архитектуру (ну, если только вы не спаяли вчера собственный процессор где-нибудь в гараже). Более того, под основные архитектуры компиляторы С писались и оптимизировались уже несколько десятилетий. А это означает, что они просто бешено эффективные. У вас займёт очень много времени написать и оптимизировать ассемблерный код до того уровня, который улучшит результат, генерируемый по-умолчанию стандартным компилятором С.
Язык С также стал чем-то вроде универсального языка для общения программистов. Не знаешь, на каком языке выразить идею, чтобы незнакомый тебе разработчик на другом конце мира понял, что за алгоритм ты написал? Просто пиши на С. Alex Allain из команды Dropbox сказал так:
С — это отличный язык для выражения общих идей в программировании способом, удобным для большинства людей. Многие из соглашений и принципов языка С были заимствованы другими языками, так что с помощью кода на С вам, вероятно, удастся объясниться даже с теми программистами, которые на С никогда и не писали
Прямой и быстрый доступ к памяти
Простой доступ к произвольным ячейкам памяти вместе с арифметикой указателей сделали язык С отличным выбором для системного программирования. На стыке аппаратного и программного обеспечения находятся адреса памяти, которые на самом деле являются портами ввода/вывода некоторых устройств. Драйвера и ядра ОС общаются через них с внешним миром. Возможность делать это легко и быстро — ключ к эффективности.
Микроконтроллер может быть спроектирован таким образом, например, что байт по адресу 0x40008000 будет отправлен UART к какому-то периферийному устройству, тогда, когда бит номер 4 в ячейке памяти по адресу 0x40008001 будет выставлен в 1.
Код на С для оправки байта для такого микроконтроллера будет выглядить вот так:
#define UART_BYTE *(char *)0x40008000
#define UART_SEND *(volatile char *)0x40008001 |= 0x08
void send_uart(char byte)
{
UART_BYTE = byte; // записываем отправляемое значение в ячейку 0x40008000
UART_SEND; // поднимаем бит номер 4 в ячейке 0x40008001
}Обратите внимание на ключевое слово volatile — оно здесь необходимо, чтобы не дать компилятору оптимизировать, например, цикл, в котором ячейке памяти по данному адресу несколько раз подряд присвоится одно и то же значение (компилятор может решить сделать это лишь один раз, если ключевого слова volatile не будет).
Детерминированность использования ресурсов
Общеизвестным фактом является то, что системное программирование не может полагаться на языки со сборщиком мусора. Более того, в некоторых системах вообще запрещена динамическая аллокация памяти. Embedded-приложения должны использовать свои ресурсы очень экономно. Некоторые из них работают в операционных системах реального времени, где вызов сборщика мусора (с его неопределённо долгим временем работы) не допустим. А запрет на динамическое выделение памяти требует наличия удобных средств работы с выделенной заранее памятью — таких, как указатели С.
Размер кода
Рантайм С очень невелик. Бинарник, полученный после компиляции и линковки кода на С, будет меньше бинарников на многих других языках. Даже по сравнению с С++ размер часто бывает в 2 раза меньше. С++ вынужден поддерживать абстракции, вроде исключений, что не даётся бесплатно. Это, безусловно, неплохой в некоторых случаях инструмент, но он требует дополнительного кода.
Давайте посмотрим вот на такой код на С++:
// Объявление класса А. Реализация методов находится где-то в другом месте
class A
{
public:
A(); // Конструктор
~A(); // Деструктор (called when the object goes out of scope or is deleted)
void myMethod(); // Просто метод
};
// Объявление класса В. Реализация методов находится где-то в другом месте
class B
{
public:
B(); // Конструктор
~B(); // Деструктор
void myMethod(); // Просто метод
};
// Объявление класса С. Реализация методов находится где-то в другом месте
class C
{
public:
C(); // Конструктор
~C(); // Деструктор
void myMethod(); // Просто метод
};
void myFunction()
{
A a; // Вызван конструктор a.A()
{
B b; // Вызван конструктор b.B()
b.myMethod();
} // Вызван деструктор b.~B()
{
C c; // Вызван конструктор c.C()
c.myMethod();
} // Вызван деструктор c.~C()
a.myMethod();
} // Вызван деструктор a.~A()Методы классов A, B и C объявлены где-то в других файлах. Таким образом, компилятор пока не может проанализировать их и понять, генерируют ли они исключения. То есть он должен быть готов к тому, что да, генерируют. И их нужно обрабатывать. Если возникнет исключение — нужно суметь отмотать стек и вызвать деструкторы всех созданных объектов. Это всё увеличивает объём сгенерированного кода. Мы получаем оверхед языка С++ по сравнению с С. Для многих приложений это не допустимо. И, хотя компиляторы С++ часто дают возможность отключить использование исключений, это тоже не даётся даром, поскольку код стандартной библиотеки С++ использует их для сообщений об ошибках. Придётся или жить без этой информации, либо переписывать части стандартной библиотеки.
И это мы ещё говорим о языке С++, чей принцип «Вы не платите за то, чем вы не пользуетесь». Для других языков оверхед как по размеру бинарников, так и по быстродействию будет ещё хуже. Язык С не даёт вам много крутых фич, но зато те, которые вы используете, будут работать ровно так, как это будет написано в вашем коде.
Причины изучить С (если вы ещё этого не сделали)
Язык С не так сложно выучить, а вот польза от этого может быть существенная.
Общий язык
Как уже говорилось выше: если вы пишете на С — вас всегда поймут. Много реализаций алгоритмов в книгах или статьях приводятся впервые именно на языке С. Это даёт максимальную портируемость, максимальную простоту использования на любой платформе. Я видел, как программисты на некоторых высокоуровневых языках рыскали по интернету в поисках реализации какого-то алгоритма на их языке просто потому, что не понимали деталей его реализации на С.
Учитывайте также, что С — это старый и распространённый язык, так что если вы ищете какой-то алгоритм в интернете, то максимальный шанс у вас будет в случае, если вы ищете его С-реализацию.
Понимание того, как работает ваш компьютер
Когда мы с коллегами обсуждаем нюансы поведения некоторых частей кода и у нас случаются сложности в понимании происходящего, приходится спускаться на более низкие уровни и заканчивается это всё «говоря языком С, это работает вот так...» — и мы вспоминаем «указатели» (даже в языках, где их нет) и копирование «по ссылке или по значению» (опять таки, даже если язык по-умолчанию реализует лишь что-то одно) и так далее.
Мы редко доходим в детализации происходящего к ассемблерному коду, но вот на уровне языка С мы действительно думаем и разговариваем.
Возможность работать над интересными проектами
Множество действительно классных вещей написаны на С. Когда вы, ради собственного удовольствия или за деньги решите покопаться в движке базы данных или ядра ОС — вы будете делать это на С. Нет причин отказывать себе в удовольствии прикоснуться к чему-то столь фундаментальному из-за незнания этого языка программирования.
Вывод
Миром управляют не масоны. Миром управляют программисты на С.
У языка С нет «срока годности». Он близок к железу, портируем и очень практичен в плане использования ресурсов. Вы можете найти себе проект по душе в куче интересных областей. Большая функциональность более современных языков не обязательно означает большую практическую пользу того кода, который будет на них написан.
Мир полон устройств, в которых работает код на С. Мы используем их каждый день. Язык С — это не только прошлое, настоящее, но и, насколько хватает взгляда, будущее во многих областях разработки ПО.
Комментарии (121)
KirEv
29.01.2018 16:45С — крутой язык, сложно представить какой ЯП сможет его заменить.
Чуть личной историиПомнится, лет десять назад, программировали на С используя Borland С++, славные были времена.
Сейчас что не более-менее новый язык — так сразу плагины для него к многим IDE и т.п., автодополнения строк\функций и т.п…
… у нас в универе были контрольные работы по программированию: дают аркуш А4, и сиди пиши программу ) потом бумажку на проверку преподу и можешь переносить свой код в ПК и компилировать.
с одной стороны — бред, но с другой: функции, инструкции языка и т.п. прочно сидят в голове, а с этими автокомлитами человеку через год-другой сложно будет вспомнить с десяток самых нужных функций…
С давних времен — привычка похожая осталось, когда на серваке быстро чтото сделать\проверить — открывается nano, и пишешь) полезная практика.catsmile
29.01.2018 17:30Если вам надо «на серваке» быстро что-то сделать/проверить на C, то у меня для вас плохие новости.
KirEv
29.01.2018 17:39Если читаете по диагонали и отвечаете не понимая контекста — у меня для вас плохие новости.
catsmile
29.01.2018 17:43-1Если вы додумываете за собеседника то, чего он не делал и не писал — у меня для вас плохие новости.
/* Я этим до вечера могу заниматься. */MacIn
29.01.2018 20:53Но человек реально не писал, будто ему нужно что-то сделать/проверить на С, вы эту часть действительно додумали (специально или невольно — неважно).
VioletGiraffe
29.01.2018 17:47ИМХО только С++.
После С++ голый С кажется языком, подходящим только для отстреливания себе ног.Sencho_Pens
29.01.2018 20:03+2ИМХО только Rust.
После Rust голый C++ кажется языком, подходящим только для отстреливания себе ног.
Не подвергайте себя и других опасности, используя небезопасные языки. Ваш код может и убить кого-нибудь.
0xd34df00d
29.01.2018 22:13+1ИМХО только Haskell.
После Haskell голый Rust кажется языком, подходящим только для отстреливания себе ног.
Не подвергайте себя и других опасности, используя нечистые языки. Ваш код может и убить кого-нибудь.
Да что там…
ИМХО только Idris.
После Idris голый Haskell кажется языком, подходящим только для отстреливания себе ног.
Не подвергайте себя и других опасности, используя неверифицируемые языки без проверки тотальности и с неразрешимой проверкой типов. Ваш код может и убить кого-нибудь.
LeonidY
29.01.2018 23:54-1С++? О, да — замечательный язык!
…
myprint(a);
b = a;
myprint(b);
…
0x00143020
0x00285040
…
Я был в полном… «восторге»! Operation overload!VioletGiraffe
30.01.2018 00:12Ничего не понял, кроме того, что С++, как и С — непростой инструмент, перед использованием нужно прочитать инструкцию.
LeonidY
30.01.2018 03:54-1Скажите, если не секрет — вам приходилось адаптировать под новую платформу некую, систему на C++ размером в двоичном коде от 10MB до 16MB кода и числом строчек исходного кода за 200000?
Мне пришлось, и она тупо падала неизвестно где и откуда. Я потратил дня 3-4 прежде чем понял, что результат присвоения не гарантирован. Инструкцию к языку я конечно прочел годы назад. Но не был готов, что на C++ надо проверять каждый шаг и если упустил перезагрузку оператора в 200тыс строк кода для этого типа данных, то увы…
sumanai
30.01.2018 16:25То есть кто-то перезагрузил оператор, явно не документировав это, а виноват С++?
LeonidY
30.01.2018 23:32О! Документированые перезагрузки. Извините, не встречал, ни разу. Комментарии около текста, где определяется перезагрузка еще могут быть, но их еще найти надо в коде на тысячи строк и сотен файлов. А чтобы искать, надо ЗНАТЬ, что они есть и какие есть, между прочим.
sumanai
31.01.2018 18:07Комментарии около текста, где определяется перезагрузка еще могут быть, но их еще найти надо в коде на тысячи строк и сотен файлов.
IDE обычно позволяет перейти к определению и реализации метода.LeonidY
31.01.2018 21:02Ну IDE не всегда доступен, если это работает на голом железе да еще и хитро собирается, то никак.
Hokum
30.01.2018 01:07Я так понимаю, что Вам ближе языки где нет перегрузки функций/методов и запрещено не явное приведение типов? Но тогда причем тут C++, такой пример можно написать много на чем.
LeonidY
30.01.2018 03:55-1Здесь идет речь про С vs С++, так что про другие языки не стоит толковать как оправдание кривостей C++.
Nick_Shl
30.01.2018 05:57У нас есть класс для возвращаемых ошибок. Он может содержать одну ошибку. Иногда возникает необходимость вызова подряд нескольких функций, каждая может вернуть ошибку. Без перегрузки операторов пришлось бы иметь два объекта, в первый получать результат функции и если во втором нет ошибки приравнивать второй к первому.
С перегрузкой же это реализуется элементарно и перегрузив оператор |= вызываем функции подряд, а в конце получаем первую возникшую ошибку.
P.S. все ошибки фатальные, важно получить первую возникшую и не замаскировать ее успешным выполнением следующей функции.LeonidY
30.01.2018 07:57Извините, но это несерьезный аргумент в пользу overloading. Он может работать на небольшой программе, но в случае комплексов на сотни тысяч строк кода поиск ошибок слишком дорого обходится.
RomanArzumanyan
30.01.2018 10:03С++ кажется языком, подходящим для отстреливания чужих ног.
А Perl просто отстреливает всех, кто пытается прочесть исходники.tBlackCat
30.01.2018 13:55Да не помянем язык ADA всуе :)
Про него неплохо написал (раскритиковал) в 1994 году Мэлор Стуруа.
saterenko
30.01.2018 11:31Вы сильно ошибаетесь, в плюсах не меньше способов отстрелить себе ногу, а может даже больше, учитывая, что он сильно сложнее голого си…
VioletGiraffe
30.01.2018 11:55Тогда на ассемблере таких способов меньше, а меньше всего — в машинных кодах?
saterenko
30.01.2018 12:23Вы умеете вести диспут без гипербол и доведения до абсурда?
0xd34df00d
30.01.2018 19:21Доведение до абсурда помогает увидеть, когда в логических высказываниях пропущены какие-то предикаты. Отличный метод, на самом деле, как доказательство от противного.
Error1024
29.01.2018 18:21Embarcadero Rad Studio (C++Bulder) — по прежнему — один из лучших инструментов для написания C кода :)
tronix286
29.01.2018 20:08И это хорошо! Потому что я знаю, что могу в Си запросто отстрелить себе ногу 1000 способами. Свобода! А вот в явах всяких и прочих похапе попробуй-ка? Шаг в сторону — и… и ничего. Скукота и тошнота, прям как бейсик.
MacIn
29.01.2018 20:54+1Шаг в сторону — и… и ничего. Скукота и тошнота, прям как бейсик.
Я попрошу не оскорблять Бейсик! В нем тоже есть возможность стрелять по ногам — POKE, например.tBlackCat
30.01.2018 14:02Несмотря на то, что Basic считался учебным языком (в моё время им Фортран заменили в ВУЗе), существует приличный вариант DarkBASIC Professional, который теперь позволяет всем желающим поковыряться в своих исходниках.
volkoff_roman
30.01.2018 11:50Переходите на плотное использование JNI в Java и жизнь станет немного ярче.
Gryphon88
30.01.2018 15:37Попробовал на Rust сделать 1 << 65, а он мне не дал. Я сел и заплакал: как же без этого? Или целочисленное переполнение… Куча милых фич недоступна. В Сях выстрел в ногу ценен и сам по себе, и удовольствием, когда ногу успел отдёрнуть.
lain8dono
31.01.2018 04:22А что вы имели ввиду под
1 << 65? Что оно вообще должно делать? При компиляции результат не влезает в 64 бита, о чём компилятор и говорит.
Или целочисленное переполнение…
Там оно есть. Просто по умолчанию считается, что эта фигня не должна происходить и debug-сборка паникует на этом. release-сборка паниковать не будет.
Если же нам требуется переполнение, как часть того, чего мы хотим достичь, то есть удобные варианты сказать "здесь должно быть переполнение". Все эти
checked_,saturating_,wrapping_,overflowing_версии позволяют задокументировать сей процесс. https://doc.rust-lang.org/std/primitive.i64.html (для остальных типов тоже самое). Плюс тип std::num::Wrapping.
Куча милых фич недоступна.
В Сях выстрел в ногу ценен и сам по себе, и удовольствием, когда ногу успел отдёрнуть.Всё там есть. Нужны UB? Есть их там. Так что спортивная стрельба по ногам тоже присутствует. Можно ставить у всего
unsafeи радоваться. К вашим услугам нестабильная функциональность. Там тоже изредка можно в биатлон поиграть. В том числе и с компилятором.
Или вам не нравится, что подобное можно найти в коде простым grep? Хочется творить какую-то магию, которая by design нечитаема? Тогда да, rust не для вас.
WinPooh73
31.01.2018 19:18Интересно, что в рамках этой метафоры можно сделать с ногами, например, в Хаскеле…
0xd34df00d
31.01.2018 20:52Ну, единственный раз, когда мне в хаскеле нужно было работать с битами, я ноги себе чуточку отстрелил, по своей глупости (Word32 не в том месте конвертировался в Word64).
К счастью, quickcheck эту ошибку поймал сразу после написания кода.
potan
01.02.2018 01:32Сделать ленивую структуру зависимой от самой себя
let a = a ++ [1] in a
Воспользоваться функцией (!!) и удивиться изменению в типе второго аргумента.
Написать let n1 = n+1 in… и внутри перепутать значения n и n1.
На моей практике пожалуй самые заметные проколы.
Amomum
29.01.2018 22:35(покашливает) Как насчет С99?
Hokum
29.01.2018 23:22А почему не спрашиваете о С11?
Amomum
29.01.2018 23:27Потому что С11 от С99 отличается не так существенно. А вот С89 с его объявлениями только в начале функций, отсутствием однострочных комментариев, отсутствием stdbool.h, отсутствием нормального inline, отсутствием designated-initializer'a для структур и т.д. довольно сильно раздражает.
Nick_Shl
30.01.2018 05:48Как говорил один мой преподаватель в университете(в который мы пришли после колледжа) "В колледже учат КАК сделать, а в университете учат КАКУЮ КНИГУ взять с полки, что бы прочитать как сделать".
Помнить наизусть все библиотечные функции языка — далеко не главное в программировании.
impwx
30.01.2018 15:51Тоже на первых курсах предпочитал писать код в Far Manager, без подсветки и автокомплита, воспринимая это как тренировку памяти и доказательство превосходства над одногруппниками. Разумеется, как только дело дошло до более-менее серьезных проектов, детская бравада закончилась.
Во-первых, автокомплит экономит огромное количество времени. Это особенно заметно на примере Javascript, где даже лучшие среды разработки предоставляют его постольку-поскольку.
Во-вторых, память в голове не бесконечна. Лучше потратить ее на что-то важное, а тонкости API оставить компьютеру.
В-третьих, может и вообще не нужно запоминать функции на случай, если они понадобятся только через год. Что это за ситуация, в которой не будет ни того же автокомплита, ни интернета, но необходимо срочно что-то написать?
potan
31.01.2018 18:47Что, кроме нежелание учить что-то новое и унаследованный код, мешает заменить C и C++ на Rust или Ivory?
interprise
29.01.2018 16:57Надеюсь раст будет готов заменить этот «отличный язык». А то он такой замечательный, но только написать на нем код без уязвимостей практически невозможно, по крайней мере еще никому не удалось это сделать (в большом проекте)
Hokum
29.01.2018 17:51Был бы «талант», а написать уязвимости можно на любом языке. :) Программист никогда не сможет до конца предвидеть как будет использоваться его продукт, для чего и как его будет применять пользователь. А программист это обычный пользователь со своими потребностями и желаниями, когда речь заходит о компиляторе. Раньше попадались байки, как «баги» компилятора использовались «во благо», а на пустом месте байки редко рождаются. :)
BogdanF
29.01.2018 18:01+1Очень сомнительно, что это произойдёт в ближайшие 10 (если не больше) лет. Даже если это случится, Rust займёт какую то полку, в лучшем случае вытеснит от туда какой нибудь язык (или просто слегка подвинет) и всё на этом закончится. Си ему не заменить.
PsyHaSTe
29.01.2018 19:13Си ему не заменить.
Какие-нибудь аргументы будут? Ну кроме «на нем столько всего написано». Как показывает опыт какого-нибудь COBOL'а, это не карт-бланш.RomanArzumanyan
30.01.2018 10:13Чтобы заменить С, нужен язык с малой стандартной библиотекой + компилятор, который за короткое время пробежит 40 лет эволюции для достижения лучшей скорости и / или меньшего размера бинарника.
Как вы сами оцениваете вероятность появления такого языка общего назначения и чудо-компилятора под него?red75prim
30.01.2018 16:22Скоростью и размером бинарника занимается LLVM. Ему почему-то не понадобилось 40 лет, чтобы догнать GCC. Или вы про какой-то другой компилятор говорили?
RomanArzumanyan
30.01.2018 16:40-1Не будем забывать, что llvm начался в 2000 году, 18 лет назад. Кроме того, llvm является бэк-эндом, который работает не с синтаксисом языка напрямую, а с ассемблером виртуальной risc машины. При создании нового языка нужно ещё написать фронт-энд для него, что тоже небыстро и недешёво (индустрия любит стандарты, а комитеты быстро ничего не решают).
Кроме того, в новом языке нужно заинтересовать производителей железа, потому что именно они являются основными contributor'ами таких проектов, как gcc.
Наконец, по данным Phoronix, в конце 2017 года связка clang + llvm всё-таки немного отставала от gcc по производительности.0xd34df00d
30.01.2018 19:23Я, конечно, не Phoronix, и публичных бенчмарков у меня нет, но в моей практике clang/llvm опережает gcc, иногда существенно.
OYTIS
30.01.2018 13:18Например огромный недостаток по сравнению с C — отсутствие стандарта. Пока что стандарта языка не только нет, он даже не планируется: постоянно подкачивать новые фичи языка с гитхаба — это модно, молодежно, динамично, но не годится для индустрии.
Еще есть проблема со стандартной библиотекой. Насколько я смог понять, там большие проблемы с модульностью. Если в С, например, я пишу под микроконтроллер, я могу использовать урезанную стандартную библиотеку без тредов хэш-мапов и всего такого, и все еще иметь возможность вызывать printf или memcpy. Даже нажористую плюсовую библиотеку, кажется (см. Christopher Kormanyos «Real-time C++») можно использовать на системах без динамической памяти подсовывая кастомные аллокаторы.
Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.PsyHaSTe
30.01.2018 17:35+1Например огромный недостаток по сравнению с C — отсутствие стандарта. Пока что стандарта языка не только нет, он даже не планируется: постоянно подкачивать новые фичи языка с гитхаба — это модно, молодежно, динамично, но не годится для индустрии.
По-моему ничем не отличается от переизобретения в каждой компании своего си-подобного языка при помощи макросов. Точнее, отличается, но в лучшую сторону
Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.
Кто вас так жестоко обманул?PsyHaSTe
30.01.2018 17:50+1Прошу прощения, перечитал еще раз. Да, много чего завязано на std, но вообще в планах это починить: internals.rust-lang.org/t/refactoring-std-for-ultimate-portability/4301. Подключаем отдельные крейты и готово.
Microsoft распилил дотнет на кучу мелких пакетов, сотни, возможно тысячи, сделать то же в расте ничего особо не мешает, если будет желание.
OYTIS
30.01.2018 19:02Про «ultimate portability» — интересно, спасибо. Надеюсь, у них получится.
Аналогии с макросами я не понял, честно говоря. Я вот о чем: для C сейчас существует множество компиляторов. С открытым кодом, с закрытым кодом, оптимизированные под конкретный процессор, со встроенным theorem-prover'ом, компилирующие в прошивку для FPGA и т.д. — полный зоопарк под любую бизнес-модель и область применения.
Все это стало возможным благодаря тому, что язык С стандартизирован, любой может взять стандарт и написать под него компилятор. С Rust же это невозможно в принципе, просто потому что стандарта нет и не планируется. По сути Rust = rustc, и это достаточно серьезное ограничение для языка, который хочет захватить мир.
BogdanF
31.01.2018 13:57Ну, например, кроме крохотной кучки энтузиастов, увидевших в Rust будущее индустрии, на него нужно пересадить еще производителей железа, огромное сообщество Linux и игровую индустрию (последнее — C++, но это дела не меняет). И так далее, дополнять можно еще долго. Каков процент вероятности, что это произойдёт?
Akon32
29.01.2018 18:47Rust какой-то "инопланетный" и многословный, что ли. Хорошо, если он "взлетит", но сейчас попытки его использования оставляют странные впечатления. Он почему-то отпугивает больше, чем любой из C, C++, Java, Scala, Python, Lua, Delphi, R, Haskell.
PsyHaSTe
29.01.2018 19:16Засунуть в одну копилку R, Hashell, Delphi и скриптовые языки это сильно :)
Хаскель отпугивает намного сильнее, моё мнение. По крайней мере его я освоить так и не мог, а с растом спокойно подружился — достаточно прочитать растбук. Из сложных концепций можно разве что лайфтаймы назвать, но стоит понять, что это просто декларативный способ указания отношений «Х живет дольше У» и все становится очевидно.0xd34df00d
29.01.2018 22:15Хаскель отпугивает намного сильнее, моё мнение.
А поделитесь вашим опытом! Сам язык-то простой как дуб, просто подход к написанию программ как к составлению графа уравнений — не самый классический, пожалуй.PsyHaSTe
29.01.2018 23:50Да особо рассказывать нечего. Поставил IDE, начал смотреть примеры, книжки, статьи. Не сказать, что что-то непонятно: опыт F# у меня, например, уже был, как и лиспов всяких. Но как-то не зашло. Хотя я как раз хотел проникнуться всей мощью IO монад и прочих методов гамбургера. Мб попробую еще раз позже. Сейчас приоритет — научиться писать на расте :)
0xd34df00d
30.01.2018 19:24Может, от статей-книжек зависит. Мне в своё время по Real World Haskell отлично зашло. Сейчас уже всякие Haskell From The First Principles рекомендуют.
lain8dono
29.01.2018 19:19попытки его использования оставляют странные впечатления
Надо ли полагать, что это из-за его главной фичи? Которая ownership. Такого действительно нет в других ЯП.
potan
31.01.2018 18:58По сравнению с C++ Rust не многословен. И там и там приянто полностью прописывать пространства имен, но в библиотеках Rust они организованы более продумано и лучше работает вывод типов.
KirEv
29.01.2018 18:12Меня смущает, что допускают публиковать дубликаты.
И кстати, это не первый перевод, мягко говоря, давней статьи.
тоже самое
PS: искал инфу про С, случайно напоролся.
maisvendoo
29.01.2018 22:36Это вам нельзя. А тем кто ведет корпоративный блог, наверное, можно. Вообще-то надоели эти статьи в духе КО от крупных контор, которые на самом деле просто пиарятся
tangro Автор
29.01.2018 23:22+1Вот бы движок хабра позволял искать по урл оригинала или имени автора — не было бы и дубликатов. Способ «случайно напоролся» — единственно возможный вариант найти уже существующий перевод.
Akon32
29.01.2018 18:38+1Имхо, почти про любой язык из TOP-10 Tiobe Index (ладно, TOP-5) можно сказать, что он "управляет миром". У них нет многих преимуществ C, но есть масса других преимуществ.
Какая-то односторонняя статья. Создаёт впечатление, что других языков почти нет, или они не работают.SeriousAlexej
29.01.2018 23:23+1Имхо, есть неиллюзорная вероятность того, что рантайм и интерпретаторы тех языков в Топ10 написаны на С.
Какой-то односторонний отзыв. Создает впечатление, что С почти ничего не стоит, или он легко заменим.
;)
geher
29.01.2018 19:34Embedded-разработка
Замечаю, что в этом деле все больше набирает обороты С++.
Часто не используются классы, но код все же именно на С++ (используются фишки именно этого языка).
Да и классы тоже частенько стали пользовать.
Даже ардуина программируется на С++ (даром что Wiring, но это всего лишь библиотека-обертка).Nick_Shl
30.01.2018 06:02А чему удивляться? C++ — это структуры данных + функции обработки данных в этих структурах с неявным указателем this… ну и ещё немного приятных мелочей.
vagran
29.01.2018 20:36Оверхед C++ всё же отключается, и да, при системной и embedded разработке на C++ стандартная библиотека заменяется специально спроектированной под нужную среду. В целом на сегодняшний день нет смысла что-либо писать на си, любую задачу, выполнимую на си можно выполнить и на плюсах (каком-то его подмножестве, но в любом случае это будет удобнее). Проблема обычно только в наличии специалистов с нужной компетенцией, для таких задач все особенности языка и его рантайма нужно знать досконально.
ilmarin77
29.01.2018 21:26В советские времена слышал высказывание «Язык C придуман западными программистами для борьбы с капиталистическими эксплуататорами»… а в 90х видел комментарий в коде «на C писать — идиотом стать»
zenkz
29.01.2018 21:38А я не люблю C. В нём нет защиты от дурака и он стар. А бы писал на нём только для embedded решений, где каждый байт на счету. Хотя я уверен, что если бы был процедурный язык, который устранил бы недостатки С и добавил бы синтаксического сахара, то C «умер» бы очень быстро…
Free_ze
30.01.2018 11:13+1От дурака никакая защита не спасет. Чем ниже порог вхождения в технологию, тем более бестолковые люди придут в IT.
zenkz
31.01.2018 17:48Ну в ИТ уже много бестолковых пришло, но от этого толковых меньше не стало, а их ценность только повысилась. А про защиту от дурака могу сказать одно — "=" в условиях. Кому нужно присваивать что либо в условиях?! Почему разработчики языка сразу не заблокировали этот источник ошибок?! А таких вещей в С очень много… И именно поэтому я его и не люблю…
Free_ze
31.01.2018 18:03+1Кому нужно присваивать что либо в условиях?!
Ну, сишники любят лаконичные циклы, например
илиwhile ((nbytes = getline(&buffer, &bufsiz, fp)) != -1) {...}
if ( B *b = dynamic_cast<B*>(a) ) {...}
Честно говоря, на практике никогда не сталкивался с подобными ошибками. Тем более, что современные статические анализаторы умеют отыскивать потенциальные ошибки с присваиванием.
potan
31.01.2018 19:05Откуда мысль, что защита от дурака сильно снижает порог вхождения? Вот скажем хорошо защищенный язык ATS сможет освоить не каждый плюсовик и ембедщик. Да и Rust все-таки сложнее чистых C.
Free_ze
31.01.2018 19:09Очевидный вывод из того, что при прочих равных снижается количество факторов, которые необходимо учитывать.
Alexeyslav
30.01.2018 12:29-2Этот язык просто попал в классическую ловушку — для него написано слишком много библиотек чтобы от него можно было отказаться и в то же время по этой же причине никто не будет писать аналогичные библиотеки для других языков. ИМХО лучше было бы чтобы победил именно паскаль. Если бы его развивали, сейчас по свойствам был бы на том же уровне что и С но более выразительный. Просто видимо изначально кому-то не понравилось много писать begin-end и подкупили краткие скобочки {} языка С, но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек.
sumanai
30.01.2018 16:57но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек
(Чувствую (на (лиспе (вы (не (писали))))))
zenkz
31.01.2018 17:56Скобочки это хорошо и намного более короче и нагляднее, чем begin-end. А вот настоящий ад C — это всё что связано с указателями (*, ^ и т.д.), а также особая любовь к _ в названиях переменных и функций, а также разбавление кода знаками вроде <>, # и % Из-за этого код C выглядит как набор символов. Добавьте к этому не очень явное наименование стандартных функций вроде scanf или puts и получится мощный язык, на котором не очень-то хочется писать…
MacIn
31.01.2018 23:14Скобочки это хорошо и намного более короче и нагляднее, чем begin-end.
Короче — да. Нагляднее — ничуть. Обозначение блока словами создает «отчеркивание» сверху и снизу, это визуально выделяет блок, причем много сильнее, чем со скобками.
potan
31.01.2018 19:11Паскаль гораздо конвервативнее, чем C.
Так разделение statement/expression в нем заметно более выраженое, а современная тенденция как раз в сторону expression-based языков.
На тот момент все-таки C был лучшим выбором, просто не надо было делать его окончательным.
stDistarik
29.01.2018 22:06Язык С не так сложно выучить, а вот польза от этого может быть существенная.
Наверное стоило бы добавить — «однако писать на нём очень не просто».
tgz
29.01.2018 22:26Прадед мой лопухом подтирался.
Дед мой лопухом подтирался.
Отец мой лопухом подтирался.
Я сам лопухом всю жизнь подтирался.
И тебе, сынок, придется.
saw_tooth
29.01.2018 22:30Спят подружки вредные
Безмятежным сном.
Снятся мышкам хлебные
Крошки под столом,
Буратинам — досточки,
Кошкам — караси,
Всем собакам — косточки,
Программистам — Си.
quwy
30.01.2018 02:43Помнится, первая (а может и вторая) версия Windows была написана на Pascal. От него осталась соответствующая конвенция вызова функций Win16 API.
red75prim
30.01.2018 06:27Кроме того, большинство пользуется раскладкой клавиатуры QWERTY. Вот только не потому, что эта раскладка лучше всех прочих предотвращает сцепление рычагов в пишущих машинках или наиболее удобна для печати, а потому что так сложилось исторически.
Впрочем, не все довольны возможностями, предоставляемыми C. Microsoft использует SAL (source-code annotation language) в драйверах, API и, надо полагать, в ядре. SAL позволяет в машиночитаемой форме сказать что-то вроде: "Этот параметр — не просто указатель, а указатель на массив, длина которого содержится вот в этом параметре", а также многое другое.
red75prim
30.01.2018 06:37Дополнение. QWERTY не предотвращает сцепление рычагов (клавиши E и R для часто встречающегося в английском "er" расположены рядом) и не самая удобная раскладка для печати.
TheKnight
01.02.2018 11:58Емнип, ходит легенда про то, что на высокой скорости печати соответствующие узлы ломались/стопорились и для этого сделали искусственное замедление скорости печати.
Но мне больше нравится легенда о том, что это сделано было в рекламных целях — что бы название конторы, выпускающей первые машинки с QWERTY раскладкой можно было напечатать используя символы одного ряда клавиатуры.
Barabek
30.01.2018 08:46Описание утра порадовало. Перед гаражом с пультом не хватает еще утренней пробежки с плеером на Си, а потом душа, подогретого умным домом на Си.
А я утром встал, сходил в туалет, умылся — и уже опаздываю (с)
malishich
30.01.2018 11:50Более того, все промышленные «вещи» спроектированы в CAD системах, написанных на С/С++. Думаю С/С++ на сегодня самый лучший язык.
Evgen52
31.01.2018 00:04А что за мифический язык "C/C++" такой? Это C или C++? Или что-то другое? Прошу прощения, наверное глупый вопрос, но слишком давно мучает, много где встречается подобная формулировка. Не придираюсь, и не стеб, правда интересно, что вкладывают люди в этот термин.
Alexeyslav
31.01.2018 14:21То что большие проекты не пишут на одном языке, обычно используют связку С и С++. С — для низкоуровневого функционала, где нужна скорость и компактность а на С++ более высокий уровень — основной GUI, бизнес-логику и т.д. где распыляться на мелочи нет времени.
Durimar123
30.01.2018 13:36tBlackCat
30.01.2018 14:14Все языки хороши, которыми владеешь. Это даёт гибкость в написании проектов и изучение нового здесь представляется необходимым.
udattsk
www.youtube.com/watch?v=cdX8r3ZSzN4
Простите, не удержался :)
KirEv
я подсел на Научно-технический рэп )
Error1024
Они еще те кидалы, на Chaos Constructions 2017 кинули всех(не уверен точно, но вроде как на $$$), в первую очередь посетителей, отказавшись выступать в последний момент, из-за «неправильного» звука на площадке.
<ИМХО>Поэтому, я только убедился в том, что реперы, в большинстве своем — мрази.</ИМХО>
Evgen52
Ну тогда уж вот ещё: https://youtu.be/1S1fISh-pag