Что делает C таким популярным в эпоху ООП? [закрыто]

Я много пишу на C и C ++, но не ожидал, что C будет вторым по популярности языком, немного уступая Java.

Индекс сообщества программистов TIOBE

Мне любопытно, почему в этом веке ООП C все еще так популярен? Обратите внимание, что 4 из 5 популярных языков программирования являются «современными» объектно-ориентированными языками.

Теперь, я согласен, что вы можете использовать ООП в C в некоторой степени, но это довольно болезненно и не элегантно (по крайней мере, по сравнению с C ++, я думаю). Итак, что делает C таким популярным? Это эффективность; быть на низком уровне; Подавляющее большинство библиотек, которые уже существуют или что-то еще?

Несколько факторов, которые способствуют:

• С вездесущ. Независимо от платформы, C, вероятно, доступен.
• С является портативным. Напишите кусок чистого C, и он компилируется с минимальными изменениями на других платформах - иногда он даже работает «из коробки».
• С был вокруг некоторое время. В те времена, когда UNIX завоевывал мир, C (выбранный язык программирования UNIX) разделял свое мировое господство и стал языком общения в мире программирования. Любой серьезный программист может ожидать , по крайней мере , сделать какой - то смысл куска C; то же самое нельзя сказать о большинстве других языков.
• C по-прежнему является языком по умолчанию для систем UNIX и UNIX. Если вы хотите, чтобы библиотека преуспевала на земле с открытым исходным кодом, у вас должны быть достаточно веские причины не использовать C. Это частично связано с традицией, но больше потому, что C - единственный язык, который вы можете смело предполагать, чтобы он поддерживал любой UNIX-подобный система. Написание вашей библиотеки на C означает, что вы можете минимизировать зависимости.
• С прост. Ему не хватает выразительности сложных ООП или функциональных языков, но его простота означает, что его можно быстро подобрать.
• С универсален. Он подходит для встраиваемых систем, драйверов устройств, ядер ОС, небольших утилит командной строки, больших настольных приложений, СУБД, реализации других языков программирования и практически всего, что вы можете себе представить.
• С быстро. Большинство реализаций C компилируются непосредственно в машинный код, и программист имеет полную власть над тем, что происходит на машинном уровне. Здесь нет интерпретатора, JIT-компилятора, виртуальной машины или среды выполнения - только код, компилятор, компоновщик и голый металл.
• C является «свободным» (как в пивном, так и в речевом смысле). Нет ни одной компании, которая владеет и контролирует стандарт, есть несколько реализаций на выбор, нет проблем с авторским правом, патентами или товарными знаками при использовании C, и некоторые из лучших реализаций - с открытым исходным кодом.
• C имеет большой импульс. Язык был популярен в течение десятилетий, поэтому существует огромное количество приложений, библиотек, инструментов и, прежде всего, сообществ для поддержки языка.
• С зрелый. Последним стандартом, внесшим большие изменения, является C99, и он в основном обратно совместим с предыдущими стандартами. В отличие от более новых языков (скажем, Python), вам не нужно беспокоиться о том, что в ближайшее время могут произойти изменения.
• С совместим. У большинства языков есть привязки для общения с C. Это означает, что можно разработать библиотеку на C, используя стандартные соглашения о вызовах, и быть уверенным, что почти любой другой язык может ссылаться на эту библиотеку. Чтобы назвать несколько популярных языков: C #, Java, Perl, Python, PHP могут без проблем связываться с библиотеками C.
• C мощный: если язык не может что-то сделать, все популярные компиляторы позволяют встраивать ассемблерный код, который может делать все, что может аппаратное обеспечение. Переходно сочетаясь с вышеупомянутым пунктом о совместимости, это означает, что C может служить связующим звеном между языками более высокого уровня и «голым металлом» сборки.

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

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

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

Объект в физике - это все, что поддерживает узнаваемую согласованность во времени. Это, в свою очередь, позволяет таким простым существам, как мы, с легкостью представлять объект, используя лишь небольшое количество битов, не подвергая опасности свое выживание. Но с точки зрения физики в целом, число вещей, которые вы должны сделать совершенно правильно, чтобы сделать такое упрощение простым и распространенным, удивительно велико. Как люди, мы не думаем обо всем этом, потому что, честно говоря, нас бы здесь не было, если бы это было не так.

Звучит слишком абстрактно? Это действительно не так. Представьте себе, например, попытку проложить дорогу к дому вашего друга, если вместо автомобилей вы столкнулись с быстро колеблющимися плазменными полями и мгновенными сгущениями вещества, движущимися с огромным диапазоном скоростей. Такой сценарий может довольно сильно сократить возможности социализации, да? Нам нужны объекты, мы являемся объектами, и существование объектов предоставляет нам огромный и критически важный уровень упрощения окружающей нас среды.

Итак, давайте вернемся к программному обеспечению. Что объекты в реальном мире говорят об объектах с точки зрения программирования?

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

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

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

Но используя компьютеры и сети, мы можем сделать так, чтобы такой переходный симпозиум казался долгосрочным объектом, захватывая и поддерживая память о нем как программный объект. Очень многое из того, что мы делаем с компьютерами и базами данных, сводится к такого рода иммортализации переходных событий, когда мы фактически пытаемся сделать нашу настоящую вселенную более богатой, захватывая и расширяя ее таким образом, что физически не может существовать. Например, ты видел настоящего Пандору в последнее время? Такие захваты и расширения реальных произведений помогают удивительным образом обогатить и расширить нашу собственную жизнь, экономику и выбор. Для меня это является сердцем объектно-ориентированного программирования, местом, где оно оказало и продолжает оказывать наиболее значимые воздействия.

Последняя категория ООП состоит из объектов, которые не имеют тесной связи с внешними событиями, но вместо этого являются инфраструктуройнеобходимо поддержать наше продолжающееся расширение реальности, используя увековеченные объекты из реального мира. Здесь вы можете спуститься до (полу) металла компьютера, создавая части постоянной реальности, которые подобно химическим элементам реального мира можно быстро и интересным образом комбинировать для создания новых внутренних миров. Мобильные вычисления помогли стимулировать развитие такого высоко рекомбинаторного подхода, который во многом повторяет рекомбинаторные особенности физического мира. Это также сложно: то, что может показаться хорошим выбором, может со временем оказаться неожиданно плохим, обычно потому, что оно блокирует разнообразие и расширение, а не поддерживает его.

Эта последняя категория также указывает на риски использования только одной модели для программирования, поскольку, как и в реальном мире, в программируемых мирах также нужны процессы, которые нехорошо соответствуют относительно неизменным объектам. Земля полна объектов, но солнце наполнено высокодинамичными потоками энергии, которые, в конечном счете, необходимы для "вождения" объектов и деятельности на Земле с более низкой энергией. Аналогично, при создании вычислительных миров существуют случаи, когда вам приходится иметь дело с потоками, преобразованиями и быстро меняющимися контекстами, которые, хотя и не очень объектно-подобны сами по себе, тем не менее абсолютно важны для включения более простых, более дружественных человеку объектов, используемых на более высоких уровнях. , Не случайно, что большая часть программирования, выполняемого на уровне ядра, не является явно объектно-подобной или что она в значительной степени опирается на языки типа C, которые более ориентированы на обработку. Это более глубокие области, которые дополняют увлекательное разнообразие, которое мы видим выше в мире, созданном компьютером.

Другая область, в которой ООП может пойти наперекосяк, - это слишком большое внимание к старым объектным концепциям.

Объекты в реальном мире, и особенно живые объекты, обладают абсолютно удивительным уровнем способности взаимодействовать со своей средой сложными и тонкими способами. Композиционные виджеты, которые просматривают друг друга, выполняют некоторые проверки совместимости и работоспособности и, возможно, даже находят новые способы взаимодействия, намного ближе к реальной биологической концепции объектов, чем простые структуры и простые схемы наследования, к которым мы стремимся. сосредоточиться на (обычно по необходимости!) на уровне кода. Это одна из областей роста объектов в кибер-мире, более «агентоподобные» подходы, где реактивность к среде является нормой даже внутри самого программирования.

И так много для моей "критики" ООП! Тем не менее, я надеюсь, что я указал, почему создание более богатого кибермира означает охватывать разнообразие стилей программирования, а не предполагать, что «только один» - это все, что нужно. Я чувствую, что действительно интересные вещи еще впереди, независимо от того, насколько обыденным является то, что мы делаем сейчас!

Во-первых, вам не нужен ООП для всего, несмотря на то, что догмы об этом были популяризированы. В отличие от Java, C допускает указатели на функции и даже замыкания, которые открывают двери для функционального программирования и решают довольно большую часть проблемных OOP-дескрипторов пространства, потому что он предоставляет средства для внедрения зависимостей. Также осторожное использование макросов может на самом деле создавать очень хорошие вещи, как доказывает sglib .

Странным образом можно увидеть C как хороший компромисс между Java и C ++. Обратите внимание, я не говорю, что C в любом случае является смесью обоих. Но в отличие от Java это довольно мощный язык, в то время как в отличие от C ++ он имеет управляемую сложность.

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

C имеет ABI (двоичный интерфейс приложения), а C ++ - нет. Это делает C более полезным, чем C ++, в некоторых случаях. Если я собираюсь написать библиотеку и иметь возможность поставлять двоичные файлы для использования другими людьми, C ++ - неподходящий инструмент для работы. Если я собираюсь написать библиотеки, которые будут использоваться другим языком снова, C - правильный инструмент для работы. Я никогда не слышал о языке, который бы не поддерживал FFI (интерфейс внешних функций) для C, с другой стороны, C ++ не будет работать с библиотеками, написанными на C ++, если используются разные компиляторы.

По сути, это сводится к тому, что C выполняет роль, для которой C ++ не подходит.

Одно из преимуществ использования C над такими языками, как C ++ или Java, заключается в том, что под капотом не происходит много магии. Конструкторы не запускаются при выделении элементов, а деструкторы не запускаются, когда объекты выходят из области видимости. Там нет названия искажения и нет vtables. Производительность легче прогнозировать; вам не нужно беспокоиться о том, что сборщик мусора прервет рутину и сместит время.

Конструкторы, деструкторы, искажение имен, vtables, сборщики мусора и т. Д. Могут облегчить некоторые сложности в написанном вами коде, но затем эта сложность становится частью самого языка, где вы практически не можете его контролировать . Вы можете столкнуться с более длительным временем сборки (раздражающим, но допустимым), большим объемом памяти во время выполнения (может или не может быть терпимым) или более низкой производительностью. С C вы можете избавиться от некоторых из этих сложностей, пока не останетесь с необходимой вам функциональностью .

Например, с stringтипом данных C ++ легче работать со световыми годами, чем со строками в стиле C, но это довольно тяжелый кусок кода, который добавляет некоторый вес вашему размеру изображения. Я редко видел, чтобы кто-нибудь в полной мере использовал stringвозможности какой-либо одной программы. Строки в стиле C, с которыми труднее работать, налагают меньше штрафов с точки зрения времени выполнения и размера изображения, и для конкретной проблемы могут быть более привлекательными по этой причине.

Встроенные системы и драйверы обычно программируются на C. Помимо этого, существует множество устаревших систем C, которые все еще поддерживаются и расширяются.

То же самое, что делает ручной молот популярным в эпоху пневматических молотков (пневматических молотков): C по-прежнему является подходящим инструментом для определенных задач.

Простота, последовательность и точность.

Это просто - вам не нужна сложная среда разработки, обширные библиотеки или виртуальная машина.

Это согласуется - большинство C, написанных 10 лет назад, могут компилироваться сегодня.

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

Это не для всех, но это все еще полезный инструмент.

Я привожу два момента из другого ответа, потому что они точно отражают причины, по которым я все еще время от времени пользуюсь Си (хотя это не мой основной язык выбора):

• С прост. Ему не хватает выразительности сложных ООП или функциональных языков, но его простота означает, что его можно быстро подобрать.
• С зрелый. Последним стандартом, внесшим большие изменения, является C99, и он в основном обратно совместим с предыдущими стандартами. В отличие от более новых языков (скажем, Python), вам не нужно беспокоиться о том, что в ближайшее время могут произойти изменения.

Я думаю, что это очень верно. Я выучил C в начале ночных сороковых: это было просто, мало ключевых слов и конструкций, большая часть работы выполнялась библиотеками. Тогда я не использовал C в течение нескольких лет. Примерно в 2002 году мне понадобилась быстрая реализация алгоритма, я установил компилятор C и реализовал его. Я знаю язык, знаю, для чего он хорош, для чего он не годится (я бы никогда не реализовал веб-приложение на C!), И это как раз там, когда мне это нужно. Без сюрпризов.

С C ++ у меня был другой опыт. Я узнал об этом примерно в 1995 году, и это означало большой переход парадигмы с императива на ООП. Большой! Я использовал его для нескольких проектов до 1999 года. В течение нескольких лет я не использовал C ++, и когда я снова поднял его (2008), я обнаружил множество новых функций уже в языке, и даже более запланированных (в то же время введенных в C ++). 11). У меня возникло ощущение, что я должен снова выучить язык.

Как разработчик, я предпочитаю зрелые, стабильные языки. Мне нравится изучать язык один раз, понять его принципы дизайна, для чего он нужен, и использовать его, когда я считаю, что это правильный инструмент для работы. Мне также нравится изучать разные языки и выбирать язык, который мне подходит (C, C ++, Java, Scala, Haskell и т. Д.). Что мне не нравится, так это снова и снова изучать один и тот же язык, потому что он развивается все дальше и дальше и никогда не достигает зрелости.

ИМХО, язык программирования должен иметь четкий, слаженный и стабильный дизайн. Мне нравится подход таких дизайнеров, как Никлаус Вирт: каждый раз, когда он чувствовал потребность в другом языке, он проектировал новый (Паскаль, Модула-2, Модула-3, Оберон). Мне не нравятся языки, которые подвергаются важным изменениям каждые 5-10 лет: они похожи на движущиеся цели, и я никогда не чувствую, что стоит потратить время на их глубокое изучение, потому что версия, которую я изучаю сейчас, вероятно, устареет через несколько годы в любом случае.

В этом смысле C является IMO победителем: это хорошо для некоторых приложений и менее подходит для других, но имеет то преимущество, что оно простое и относительно стабильное.

Я удивлен, что никто еще не упомянул, что Хуже лучше . На данный момент ему более 20 лет, но все еще стоит читать. Несмотря на то, что время от времени он немного издевается, он очень хорошо показывает, как и почему средство часто побеждает идеал, используя C (в сравнении с LISP) в качестве одного из центральных примеров.

Вы, вероятно, хотели спросить, почему люди используют C вместо C ++, несмотря на тот факт, что когда у вас есть компилятор C, у вас также обычно есть компилятор C ++.

• Язык C намного проще, чем C ++. Я не знаю ни одной компании, которая использует полный стандарт C ++ в своем соглашении о кодировании. Взгляните на стиль кода Google C ++ в качестве примера: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• С гораздо быстрее компилируется. Благодаря отсутствию сложных для компиляции конструкций.

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

Много устаревшего программного обеспечения

Многие компании не могут изменить сразу весь свой код на C ++ или аналогичный.

Многие компании не могут позволить себе изменить свой код.

Многие компании могут позволить себе изменить свой код, но им все равно, или они «дешевы».

Многие компании находятся в процессе миграции, но еще не закончили.

Ориентация на поиск предметов

(Не объектно-ориентированный) Исходный код C, разработанный как объектно-ориентированный исходный код C, приложения, которые смоделированы с помощью Object Orientation и закодированы с использованием «чистого C», или инструменты, которые переводятся из «C ++» или других программных продуктов OO. Ланг в C.

Я слышал, что некоторые видеоигры сделаны таким образом. Некоторые кроссплатформенные инструменты, а также библиотека визуального интерфейса GTK (GObject, GLibrary) для дистрибутивов ОС Linux GNOME.

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

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

Паскаль был изобретен около 1970 года, С был изобретен около 1972 года, поэтому я думаю, что Паскаль был примерно так же долго, как С.

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

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

Кажется, C - это тот глобальный язык, но я бы хотел, чтобы это было что-то вроде Object Pascal. Почему Object Pascal, это более читаемый язык программирования, ООП-код, как правило, более пригоден для повторного использования и менее подвержен ошибкам (на мой взгляд), чем C.

Очень большими приложениями легче управлять с помощью Object Pascal, чем C / C ++.

Что касается языка программирования, существовавшего с 70-х годов, и не любящих языков, которые меняются каждые 5 или 10 лет. Со временем технологические достижения и методы программирования совершенствуются. Если языки меняются радикально каждые несколько лет, то, вероятно, это не было хорошо продумано разработчиком. Но с 1970 по 2012 год - это почти полвека, поэтому можно вносить изменения в язык в то время, чтобы включать в себя достижения, используемые в разработке программного обеспечения.

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

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

Что касается C ++, IMO сложнее в освоении. Более того, после 10-летнего опыта ООП я обнаружил, что это не всегда полезно, и часто вместо этого проще использовать процедурное программирование.