Що робить C настільки популярним в епоху OOP? [зачинено]

Я багато кодую і на C, і на C ++, але не очікував, що C стане другою за популярністю мовою, трохи відстаючи від Java.

Індекс спільноти програмування TIOBE

Мені цікаво, чому в цьому віці ООП Ц все ще користується такою популярністю? Зауважте, що 4 з 5 популярних мов програмування - це "сучасні" об'єктно-орієнтовані мови.

Тепер я погоджуюся, що ви можете використовувати OOP в C певною мірою, але це наче болісно і неелегантно (ну, принаймні, порівняно з C ++, я думаю). Отже, що робить C настільки популярним? Чи це ефективність; бути низьким рівнем; переважна більшість бібліотек, які вже існують, чи щось інше?

Кілька факторів, які сприяють:

• С є всюдисущим. Незалежно від платформи, C, ймовірно, доступний.
• C портативний. Напишіть шматок чистого C, і він збирається з мінімальними модифікаціями на інших платформах - іноді він навіть працює нестандартно.
• C вже деякий час був навколо. Ще в ті часи, коли UNIX завоював світ, C (мова вибору програмування UNIX) поділилась у своєму світовому пануванні та стала мовою франкінгу світу програмування. Будь-який серйозний програміст може очікувати хоча б певного сенсу шматка С; те ж саме не можна сказати про більшість інших мов.
• C як і раніше є мовою за замовчуванням для систем із ароматом UNIX та UNIX. Якщо ви хочете, щоб бібліотека мала успіх у відкритих джерелах, вам потрібні досить вагомі причини не використовувати C. Це частково пов’язано з традицією, але більше тому, що C є єдиною мовою, яку можна сміливо вважати підтримкою на будь-якій схожій на UNIX система. Запис бібліотеки на C означає, що ви можете мінімізувати залежності.
• C проста. Їй не вистачає виразності складних OOP або функціональних мов, але її простота означає, що її можна швидко підібрати.
• C універсальний. Він підходить для вбудованих систем, драйверів пристроїв, ядер ОС, невеликих утиліт командного рядка, великих додатків для настільних ПК, СУБД, впровадження інших мов програмування та багато іншого, що ви можете придумати.
• С швидко. Більшість реалізацій C збираються безпосередньо до машинного коду, і програміст має повну владу над тим, що відбувається на машинному рівні. Немає ні перекладача, ні компілятора JIT, ні VM чи часу виконання - лише код, компілятор, лінкер та голий метал.
• C "вільний" (і в пивному, і в мовному сенсі). Не існує жодної компанії, яка володіє та контролює стандарт, є кілька варіантів реалізації, на вибір, немає проблем з авторським правом, патентуванням або товарними знаками на використання C, а деякі найкращі реалізації - з відкритим кодом.
• У C відбувається багато імпульсу. Мова користується популярністю десятиліттями, тому для підтримки мови існує величезна кількість додатків, бібліотек, інструментів і, насамперед, спільнот.
• С - зрілий. Останній стандарт, який запровадив великі зміни, - це C99, і він здебільшого сумісний із зворотним рівнем з попередніми стандартами. На відміну від нових мов (скажімо, Python), вам не доведеться хвилюватися про порушення змін найближчим часом.
• C сумісний. Більшість мов мають зв'язок спілкуватися з C. Це означає, що можна розвивати бібліотеку в C, використовуючи стандартні умови викликів, і впевнений, що майже будь-яка інша мова може зв’язатися з цією бібліотекою. Щоб назвати кілька популярних мов, які широко використовуються: C #, Java, Perl, Python, PHP можуть без особливих проблем посилатися на бібліотеки C.
• C потужний: якщо мова не може щось зробити, всі популярні компілятори дозволяють вбудовувати код асемблера, який може робити все, що може зробити обладнання. Перехідно поєднаний із вищезгаданим моментом щодо сумісності, це означає, що C може діяти як зв’язок між мовами вищого рівня та "голим металом" складання.

Я завжди схильний звинувачувати популярність C у необхідності універсальної мови складання. Це поєднання специфіки на машинному рівні, стандартизація та надзвичайна портативність дозволяють C функціонувати як фактично універсальна мова складання, і тому я підозрюю, що її роль там буде тривати нескінченно.

Я мушу зазначити, що я завжди трохи здивований, коли OOP представлений на курсах програмування як своєрідна «фінальна модель», яка є єдиною можливою кінцевою точкою хорошого програмування. Як і багато інших аспектів програмування, цінність OOP - це компроміс між багатьма конкуруючими факторами, включаючи те, як людський мозок організовує інформацію, як суспільні групи підтримують програмне забезпечення на тривалий термін, а у випадку об'єктно-орієнтованого програмування - деякі досить глибокі аспекти того, як працює сам Всесвіт.

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

Об'єктом фізики є все, що підтримує впізнавану узгодженість у часі. Це в свою чергу дозволяє таким простим істотам, як ми, відмовлятися від представлення об'єкта, використовуючи лише невелику кількість біт, не загрожуючи занадто сильному виживанню. Але з точки зору фізики в цілому, кількість речей, які ви повинні отримати точно, щоб зробити таке спрощення легким і поширеним, надзвичайно велике. Як люди, ми не думаємо про все так багато, тому що, відверто кажучи, ми не були б тут, якби не правда.

Звучить занадто абстрактно? Це насправді не так. Уявіть, наприклад, що намагаєтеся пройти дорогу до будинку свого друга, якщо замість автомобілів ви зіткнулися з швидко коливаються плазмовими полями та миттєвими конденсаціями речовини, що рухається з величезним діапазоном швидкостей. Такий сценарій може досить глибоко вирізати можливості соціалізації, так? Нам потрібні об’єкти, ми - об’єкти, а існування об'єктів забезпечує нам величезний і критично важливий рівень спрощення навколишнього середовища.

Тож давайте все це повернемо назад до програмного забезпечення. Що об'єкти в реальному світі повинні сказати про об'єкти з точки зору програмування?

Ну, з одного боку, це означає, що те, що визначає "хороший" об'єкт у програмному забезпеченні, дійсно має полягати в тому, чи тип даних, якими ви обробляєтесь, легко підтримує ідею впізнаваної стійкості з часом .

За допомогою визначення легко розпізнати найпростіші форми ООП. Це ті, хто витягує трохи, використовуючи лише ті дані, які вже "прикріплені" або визначені якимсь реальним, справді фізичним об'єктом, таким як людина, будинок чи машина. Навіть сьогодні це занадто часто є єдиним визначенням об'єктів, які люди отримують на курсах програмного забезпечення. Це дуже погано, адже навіть тривіальні об'єктно-орієнтовані програми потребують більш широкого визначення, ніж це.

Друга і набагато цікавіша категорія об'єктів складається з того, що я назву увічненими подіями реального світу . Під "увічненою" я маю на увазі речі, які принаймні коротко існують як чітко визначена сутність або колекції, що знаходяться в реальному світі, але які потім розсіюються і перестають існувати як фізично значущі колекції. Симпозіум - прекрасний приклад: симпозіум існує недовго, як гідно чітко визначена колекція місць та людей. Але, на жаль, навіть найкращі конференції повинні закінчитися, а окремі частини, що їх створили, переходять до інших заходів.

Але за допомогою комп'ютерів і мереж, ми можемо зробити такий перехідний симпозіум , здається , як довгостроковий об'єкт шляхом захоплення і збереження пам'яті про нього як об'єкт програмного забезпечення. Дуже багато речей, які ми робимо з комп’ютерами та базами даних, є таким видом увіковічнення перехідних подій, завдяки якому ми насправді намагаємось зробити наш справжній Всесвіт багатшим шляхом захоплення та розширення його способами, які фізично неможливо існувати. Наприклад, ви бачили справжню Пандору останнім часом? Такі захоплення та розширення творів реального світу допомагають збагатити та розширити наше власне життя, економіку та вибір чудовими способами. Це для мене серце серця об'єктно-орієнтованого програмування, місце, де воно мало і продовжує мати найвизначніші впливи.

Кінцева категорія ООП складається з об'єктів, які не мають тісного зв’язку із зовнішніми подіями, але натомість є інфраструктуроюнеобхідний для підтримки нашого постійного розширення реальності з використанням увічнених предметів із реального світу. Тут ви можете спуститися аж до (напів) металу комп’ютера, створюючи шматки стійкої реальності, які, як хімічні елементи реального світу, можна швидко поєднувати і цікавими способами будувати нові внутрішні світи. Мобільні обчислення допомогли сприяти зростанню цього виду високо рекомбінаторного підходу, який знову багато в чому імітує рекомбінаторні особливості фізичного світу. Також важко: те, що може здатися хорошим вибором, може виявитись з часом несподівано поганим, як правило, тому, що воно блокує різноманітність та розширення замість того, щоб підтримувати його.

Ця остання категорія також вказує на ризики використання лише однієї моделі для програмування, оскільки, як і в реальному світі, запрограмовані світи також потребують процесів, які недобре відповідають відносно незмінним об'єктам. Земля повна предметів, але Сонце сповнене сильно динамічних потоків енергії, які в кінцевому підсумку необхідні для "руху" об'єктів і діяльності на землі з нижчою енергією. Аналогічно, у створенні обчислювальних світів трапляються випадки, коли ви маєте мати справу з потоками та перетвореннями та швидко мінливими контекстами, які, хоча самі по собі не є подібними до об'єктів, є абсолютно критичними для забезпечення простіших, більш зручних для людини об'єктів, що використовуються на вищих рівнях . Не випадково велика частина програмування, виконаного на рівні ядра, не є помітним як об'єктне, або що воно, як правило, покладається на мови, такі як 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, сміттєзбірники тощо, можуть полегшити деяку складність у вашому авторському коді, але тоді ця складність стає частиною самої мови, де ви майже не маєте ніякого контролю над нею . Ви можете закінчити триваліші строки складання (дратівливі, але терпимі), більший слід пам’яті для виконання (може бути, а може і не бути терпимим) або більш низькою продуктивністю. У C ви можете урізати деякі з цієї складності , поки ви не залишилися з функціональністю вам потрібно .

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

Вбудовані системи та драйвери, як правило, запрограмовані на C. Крім того, там є багато застарілих систем C, які все ще підтримуються та розширюються.

Те саме, що робить ручний молоток популярним у епоху пневматичних молотків (повітряних молотків): C все ще є правильним інструментом для певних робіт.

Простота, послідовність і акуратність.

Це просто - вам не потрібно складне середовище розробки, великі бібліотеки або віртуальна машина.

Це послідовно - більшість С, написаних 10 років тому, могла скласти сьогодні.

Точність - це дозволяє вам перейти до рівня машини, знаючи місця пам'яті, як потрібно. Це чудово підходить для продуктивності та вбудованого обладнання.

Це не для всього, біт це все-таки корисний інструмент.

Я наводжу два моменти з іншої відповіді, тому що вони чітко враховують причини, чому я все-таки час від часу використовую C (хоча це не моя основна мова вибору):

• C проста. Їй не вистачає виразності складних OOP або функціональних мов, але її простота означає, що її можна швидко підібрати.
• С - зрілий. Останній стандарт, який запровадив великі зміни, - це C99, і він здебільшого сумісний із зворотним рівнем з попередніми стандартами. На відміну від нових мов (скажімо, Python), вам не доведеться хвилюватися про порушення змін незабаром.

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

З C ++ у мене був інший досвід. Я дізнався це близько 1995 року, і це означало перехід великої парадигми від імперативу до ООП. Чудово! Я використовував його для декількох проектів до 1999 року. Кілька років я не використовував C ++, і коли я знову взяв його в дію (2008), я знайшов безліч нових функцій вже на мові, а ще більше запланованих (тим часом, представлених на C ++ 11). У мене з’явилося відчуття, що я повинен знову вивчити мову.

Як розробник я віддаю перевагу зрілим, стабільним мовам. Мені подобається один раз вивчити мову, зрозуміти її принципи дизайну, для чого це добре, і використовувати її, коли я вважаю, що це правильний інструмент для роботи. Мені також подобається вивчати різні мови та вибирати мову, яка відповідає моїм потребам (C, C ++, Java, Scala, Haskell тощо). Мені не подобається - це потрібно знову і знову вивчати одну і ту ж мову, оскільки вона розвивається все далі і далі, і ніколи не досягає зрілості.

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

У цьому сенсі C є переможцем IMO: він хороший для одних додатків і менш підходить для інших, але має перевагу в тому, що він простий і відносно стабільний.

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

Ви, напевно, хотіли запитати, чому люди використовують C замість C ++, незважаючи на те, що коли у вас є компілятор C, у вас також зазвичай є компілятор C ++.

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

Нічого. TIOBE - нікчемний показник. Якщо ви насправді дивитесь на їх вимірювання, то це в кращому випадку здогад.

Багато застарілого програмного забезпечення

Багато компаній не можуть змінити миттєво весь код на C ++ або подібний.

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

Багато компаній можуть дозволити собі змінити код, але все одно, або вони "дешеві".

Багато компаній перебувають у процесі міграції, але ще не завершені.

Прихована орієнтація на об'єкт

(Неорієнтований на об'єкт) C вихідний код, розроблений як об'єктно-орієнтований вихідний код C, програми, що моделюються за допомогою об'єктної орієнтації та кодовані "чистим C", або інструменти, що перекладаються з "C ++" або іншого OO progr. увійти в С.

Я чув, що деякі відеоігри робляться саме так. Деякі інструменти крос-платформ також і бібліотека візуальних інтерфейсів GTK (GObject, GLibrary) для дистрибутивів ОС GNome Linux.

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

Але те ж саме можна сказати і про інші мови, наприклад, безкоштовний Pascal - він безкоштовний і підтримується майже на всіх платформах.

Паскаль був винайдений близько 1970 року, C - винайдений приблизно в 1972 році, тому я думаю, що Паскаль існував так само, як і C.

Особисто я вважаю, що C - найпопулярніша мова, тому що там є просто більше відкритого коду, який може бути використаний будь-коли. І так, це нижчий рівень, ніж Паскаль, тому він наближається до складання, але його набагато читабельніше, ніж складання.

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

Здається, це глобальна мова, але я б хотів, щоб це було щось на зразок Object Pascal. Чому Object Pascal - це більш читана мова програмування, код OOP, як правило, є більш багаторазовим і менш схильним (на мою думку) помилок, ніж C.

Дуже великі програми легше керувати за допомогою Object Pascal, ніж C / C ++.

Щодо мови програмування, якою це було ще з 70-х, і не подобаються мови, які змінюються кожні 5 або 10 років. Із часом вдосконалення технології та вдосконалення методів програмування. Якщо мова різко змінюється кожні кілька років, то, мабуть, її продуманий дизайнер, мабуть, не продумав. Але з 1970 по 2012 рік майже півстоліття, нормально вносити зміни в мову в цей час, щоб включити досягнення, розроблені в розробці програмного забезпечення.

Сам C кілька разів переглядався. Отже, це не краще, ніж інші мови формують цю точку зору.

Тому що C має величезну базу користувачів. Так, це трохи привід-22, але коли я задаю питання про C over на StackOverflow, я отримую відповідь майже миттєво. На те саме питання щодо Python потрібні години, щоб отримати відповідь.

Що стосується C ++, то навчитися ІМО складніше. Крім того, після того, як я пробував OOP протягом 10 років, я вважаю, що це не завжди корисно, і часто натомість легше використовувати процедурне програмування.