Інтерв’ю з Страуструпом, C / C + +, Програмування, статті

Пер. А.І. Легальний, CodeNet

Загальні відомості

У цьому інтерв’ю, Бьерн Страуструп, творець C + +, говорить про об’єктно-орієнтованої революції, особливості реальної розробки програмного забезпечення, безперервному розвитку C і C + +, та деяких поповнення до стандарту C + +, які він хотів би побачити.

Бьерн Страуструп – творець C + +, одного з найбільш широко використовуваних мов, що підтримує об’єктно-орієнтоване програмування. Він також автор таких книг як “Мова програмування C + +” [Страуструп] і “Дизайн і еволюція C + +” [Страуструп2000]. Страуструп, в даний час очолює відділ програмування дослідницької лабораторії AT & T в штаті Нью-Джерсі. Його наукові інтереси включають розподілені системи, операційні системи, моделювання, проектування програмного забезпечення та програмування.

LinuxWorld.com: Об’єктно-орієнтовані мови відомі з кінця 1960-их. Однак, об’єктно-орієнтована революція відбулася через два десятиліття. Як Ви пояснюєте цю затримку і які висновки ми можемо зробити з цього?

Бьерн Страуструп: Частина причин в тому, що що зміни в свідомості і поведінці людей завжди займають набагато більше часу, ми думаємо. Інша причина в тому, що деякі люди мали (і мають) необгрунтовані очікування щодо “революцій”. В докорінно невірною є думка, що є тільки один правильний спосіб, щоб вирішити будь-яку проблему для будь-якого користувача. Я – великий фанатик об’єктно-орієнтованого програмування, а також методів і принципів проектування (розробки), спираються на використання алгоритмічної мови Симула 67. Однак, ця техніка не являетсяеффектівной. Багато чого в програмуванні краще зробити методами, які не поміщаються всередині вузької смужки методів, іменованих “об’єктно-орієнтованими”. І якщо Ви не виходите за кордон “об’єктно-орієнтованих” методів, щоб залишитися в рамках “Хорошого програмування і проектування “, Ви отримуєте щось, що є в основному безглуздим. Див мою статтю, “Чому C + + не тільки об’єктно-орієнтована мова програмування “.

Інша причина полягає в тому, що люди, пов’язували з поняттями “Справжня об’єктна орієнтованість ” або “Чиста об’єктна орієнтованість “таке, що вело до величезних непродуктивною затратам навіть при вирішенні простих задач, якщо порівняти отриманий код з кодом на C + + і C.

Висновок, який я зробив (в 1980 або близько того), полягав в тому, що універсальна мова програмування повинен спиратися на кілька парадигм і що кожна парадигма повинна бути підтримана добре: з близькою до оптимальної просторової і тимчасової ефективністю. Підводячи підсумок, я знаходжу, що прийняття нових ідей було серйозно загальмовано консерватизмом, що спирається на міфи про складність і непродуктивних витратах.

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

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

LinuxWorld.com: Які важливі тенденції в програмуванні ми побачимо в найближчому майбутньому? Яка роль функціонального програмування, програмування на основі правил, узагальненого програмування, і інших парадигм в світі програмування завтрашнього дня? Може щось із них стати панівною тенденцією або вони – прості академічні пустушки?

Бьерн Страуструп: я не є хорошим провісником майбутнього, так що я не буду цим займатися, замість цього скажу, що зазвичай майбутнє в більшій мірі, ніж ми думаємо, є вчорашнім днем. Зауважте, що Кобол, ФОРТРАН, і C – все ще великі мови. Узагальнене програмування – реальність (панівна тенденція).

Ви можете також бачити, як витончено і ефективно в стандартній бібліотеці шаблонів (STL) замствована техніка функціонального програмування, використовувана при цьому в контексті C + +. Програмування на основі правил (див. посилання на ресурси з R + +) має в своєму активі список невдач і успіхів, який не веде до висновку про можливе панує положенні. Це, звичайно, сумно, але я не хочу називати цю парадигму “академічним дрібницею “. Багато з ідей, які ми сьогодні бачимо в окремих мовами, проявляться як панівні тенденції, засоби і методи, при впровадженні в панівний мова, типу C + +. Майбутнє побачить багато мультіпарадігм програмування і різні багатомовні системи.

LinuxWorld.com: З утвердженням C99 (нового стандарту C), C / C + + сумісність здається менш досяжною ніж будь-коли колись. Чи є сумісність вниз з C все ще одна з цілей C + +? Якщо так, то що було зроблено, щоб відвернути від прірви, що встає між двома мовами?

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

Мій ідеал: залишаються все ще загальними частини C + + і C99 можна з’єднати в єдиний когерентний мову. Я думаю, що така мова міг би об’єднати загальні раціональні технічні вимоги. Однак, я не впевнений, що політично це буде зроблено. Для запуску процесу, потрібно злиття комітетів стандартів з C і C + +. Неможливо мати дві різних групи людей, що розвивають дві мови паралельно. Кожен комітет притягує людей, хто не можуть використовують ідеали більшості з іншої групи, і які ненавидять можливостей компромісу з цим більшістю. У той час як кожен окремий комітет сприяє об’єднанню своєї спільноти, обидва комітету забезпечують расходимость мов і ігнорування незручних пропозицій і думок. Особисто, я думаю, що комітети повинні виробити угоду, щоб з’єднатися, а потім і злитися, але перш, ніж з’явиться новий стандарт ISO C + +. Результатом були б більш хороший мова і набагато більш сильне співтовариство.

LinuxWorld.com: Чи є елементи або концепції в інших мовах, наприклад Python або Ada95, які б Ви хотіли бачити доданими до C + +? Взагалі, чи потребує C + + в будь-яких додаткових елементах або бібліотеках?

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

Розглянемо “основні” засоби мови, часто пропоновані для внесення в C + +:

Зауважте, що ці розширення перш за все є доповненнями до стандартної бібліотеці і можуть бути реалізовані без нових витрат під час виконання програми або додаткових вимог до ресурсів. Таким чином, вони можуть бути додані без порушення принципу “нульового перекриття”. Між іншим, C + + – хороший мову для програмування апаратного ядра вбудованих систем та повинен залишатися таким. Також, всі ресурси повинні бути правильно інтегровані з поточними стандартними бібліотечними засобами, такими як рядки і контейнери.

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

LinuxWorld.com: здається, що C + + зазнав невдачу на одному важливому фронті: захист мови. Багато людей все ще по помилку вважають, що C + + по суті повільніше ніж C, а середа часто відмовляється підтверджувати, що C + + найбільш широко використовуваний універсальна мова програмування, фокусуючись натомість на інших широко роздутих мовами. Де ми йшли не так, як треба і що може бути зроблено, щоб зафіксувати все, як треба?

Бьерн Страуструп: C + + не потребував ефективному захисту, з самого початкового моменту: його відразу стали використовувати мільйони програмістів. Дивно те, що це було досягнуто без спеціальної організації і використання будь-яких додаткових ресурсів. Це, можливо, зробило співтовариство C + + умиротвореним, що, безумовно, привілля до уразливості з боку ворожої пропаганди. Я припускаю, що реальне завдання в те, що хороший код є невидимим, навіть його користувачам. Розгляньте програми на C + + типу Netscape і Internet Explorer. Корпорації, які виробляють програмне забезпечення для вирішення завдань в реальному масштабі часу: управління передачею даних, автоматичне управління, і моделювання, не рекламують мови, якими вони користуються. До жаль, іміджмейкерами програм та інструментальних засобів є продавці і академіки.

C + + ніколи не мав підтримку великого виробника. Кожен великий виробник поміщає (і завжди поміщав) деякий приватний мова над C + +. C + + ніколи не використовував великого маркетингу, а там, де маркетинг був зроблений, він звичайно здійснювався організаціями, що продають дещо ще (типу середовища програмування). Це, дещо, сталося, включало і C + +. Крім того, співтовариство C + + страждає від самого успіху C + +: Абсолютно ясно “Треба бити поодинці” і в сьогоднішньому, сильно комерціалізованому світі, чесна боротьба – рідкість.

Спільнота C + + ніколи не мало чіткого центру з фінансуванням, щоб брати участь у популяризації C + +. Хто агітує за C + +? І як ця агітація досягає програмістів, педагогів, і адміністраторів? Вже на цьому тижні, я чув про професора, вселяє його студентам, що не є, однак, стандарту C + +! Сумно чути таке через два роки після затвердження стандарту, це – загальне неправильне уявлення.

Так, що ж спільнота C + + може зробити тепер? Досягнуто певні успіхи іізвестни успішні методи. Статті та конференції – це можливі місця зустрічі, але для найбільш зайнятих програмістів, простий опис на Web сторінках – більш реалістична можливість. Забезпечення високоякісного коду, відкриття сайтів з вихідними кодами – можливо найбільш дієвий спосіб показати людям, що може робити C + + (поточні приклади – SGI, STL і Boost.org). Так чи інакше, ми повинні створити широко відому “портал” до інформації, пов’язаної з C + +.

Комерційні організації могли б поліпшити роботу за переказами гласності їх успіхів у використанні C + + особливо, якщо він забезпечує можливість зосередитися на приватних аспектах їх виробів. Різноманітні постачальники, стандартизований характер – велика причина для багатьох користувачів вибрати C + +.

C + + повинен вивчатися краще, разом зі стандартною бібліотекою і засобами абстракції, що грають центральну роль. Навчанні C + + як розширення до C марнотратно і заплутано. Див “Вивчення Стандартного C + + як нової мови ” в ресурсах.

Комітет стандартів повинен робити його роботу, забезпечуючи стандартні версії доступними для критики, але нестандартними, бібліотеками. Це може бути зроблено, але зробити це буде не просто.

Ресурси

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*