Історичний огляд, класифікація та характеристика мов програмування

Існує мову з дуже гарною реалізацією об'єктно-орієнтованості, не є надбудовою ні над яким іншим мовою. Це мова Eiffel (1986). Будучи чистою мовою об'єктно-орієнтованого програмування, він, крім того, підвищує надійність програми шляхом використання <�контрольних тверджень>.

Мови паралельного програмування

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

Мова Оccam був створений в 1982 році і призначений для програмування транспьютеров - багатопроцесорних систем розподіленої обробки даних. Він описує взаємодію паралельних процесів у вигляді каналів - способів передачі інформації від одного процесу до іншого. Відзначимо особливість синтаксису мови occam - в ньому послідовний і паралельний порядки виконання операторів рівноправні, і їх необхідно явно вказувати ключовими словами PAR і SEQ.

У 1985 році була запропонована модель паралельних обчислень Linda. Основним її завданням є організація взаємодії між паралельно виконуються процесами. Це досягається за рахунок використання глобальної кортежних області (tuple space). Процес може помістити туди кортеж з даними (тобто сукупність кількох, можливо різнорідних, даних), а інший процес може очікувати появи в кортежних області деякого кортежу і, після його появи, прочитати кортеж з можливим подальшим його видаленням. Зауважимо, що процес може, наприклад, помістити кортеж в область і завершитися, а інший процес може через деякий час скористатися цим кортежем. Таким чином забезпечується можливість асинхронного взаємодії. Очевидно, що за допомогою такої моделі може бути симулювати і синхронне взаємодія. Linda - це модель паралельних обчислень, вона може бути додана в будь-яку мову програмування. Існують досить ефективні реалізації Linda, які оминають проблему існування глобальної кортежних області з потенційно необмеженим обсягом пам'яті.

Логічні мови програмування

На початку 70-х років Роберт Ковальський, в той час працював в Единбурзі, і Алан Колмерое з Марселя розробляли подібні ідеї і навіть працювали разом протягом одного літа. В результаті були сформульовані основні положення логічного програмування, в 1972 році описаний і реалізована перша мова логічного програмування - Пролог ( "програмування на мові логіки" - PROgramming in LOGic).

Функціональні мови програмування

Теорія, покладена в основу функціонального підходу народилася в 20-х - 30-х роках XX століття. У числі розробників математичних основ функціонального програмування можна назвати Мозеса Шёнфінкеля (Німеччина та Росія) і Хаскелл Каррі (Англія), які розробили комбінаторних логіку, а також Алонзо Черча (США) - творця -ісчісленія.

Теорія так і залишалася теорією, поки в 1958 році Джон Маккарті не розроблена мова Lisp, який став першим функціональним мовою програмування. Хоча Lisp все ще використовується, він вже не задовольняє деяким сучасним запитам, які змушують розробників програм звалювати якомога більшу ношу на компілятор, полегшивши тим самим свій непосильна праця. Необхідність в цьому, звичайно ж, виникла через все більш зростаючої складності програмного забезпечення.

У зв'язку з цією обставиною все більшу роль починає грати типізація. В кінці 70-х - початку 80-х років XX століття інтенсивно розробляються моделі типізації, які підходять для функціональних мов. З'являється безліч типізованих функціональних мов: ML (Робін Мілнер, 1979, з нині використовуваних діалектів відомі Standard ML і Objective CAML), Scheme (1975), Hope, Miranda (Девід Тернер, 1985), Clean і багато інших. До того ж постійно збільшується число діалектів.

В результаті вийшло так, що практично кожна група, що займається функціональним програмуванням, використовувала власну мову. Це перешкоджало подальшому поширенню цих мов і породжувало численні більш дрібні проблеми. Щоб виправити ситуацію, об'єднана група провідних дослідників в області функціонального програмування вирішила відтворити гідності різних мов в новому універсальному функціональному мовою. Перша реалізація цієї мови, названого Haskell в честь Хаскелл Каррі, була створена в 1990 році. В даний час дійсний стандарт Haskell-98.

Нижче наведемо схему «Еволюція мов програмування».

4. Характеристики мов програмування

4.1 Елементи об'єктної моделі

Кожен стиль програмування має свою концептуальну базу. Кожен стиль вимагає свого умонастрої і способу сприйняття розв'язуваної задачі. Для об'єктно-орієнтованого стилю концептуальна база - це об'єктна модель. Вона має чотири головні елементи:

· Абстрагування;

· Інкапсуляція;

· Модульність;

· Ієрархія.

Ці елементи є головними в тому сенсі, що без будь-якого з них модель не буде об'єктно-орієнтованої. Крім головних, є ще три додаткові елементи:

· Типізація;

· Паралелізм;

· Збереженість.

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

Без такої концептуальної основи ви можете програмувати на мові типу Smalltalk, Object Pascal, C ++, CLOS, Eiffel або Ada, але з-під зовнішньої краси буде виглядати стиль FORTRAN, Pascal або С. Виразна здатність об'єктно-орієнтованої мови буде або втрачена, або спотворена . Але ще більш істотно, що при цьому буде мало шансів впоратися зі складністю вирішуваних завдань.

абстрагування

Абстрагування є одним з основних методів, використовуваних для вирішення складних завдань.

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

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

Вибір правильного набору абстракцій для заданої предметної області являє собою головне завдання об'єктно-орієнтованого проектування.

На думку Сейдвіца і Старка "існує цілий спектр абстракцій, починаючи з об'єктів, які майже точно відповідають реаліям предметної області, і закінчуючи об'єктами, які не мають право на існування". Ось ці абстракції:

Абстракція фокусується на суттєвих з точки зору спостерігача характеристики об'єкта.

інкапсуляція

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

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

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

Інкапсуляцію можна визначити наступним чином:

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

Інкапсуляція приховує деталі реалізації об'єкта.

модульність

На думку Майерса "Поділ програми на модулі до деякої міри дозволяє зменшити її складність... Однак набагато важливішим є той факт, що всередині модульної програми створюються безлічі добре визначених і документованих інтерфейсів. Ці інтерфейси неоціненні для вичерпного розуміння програми в цілому ". У деяких мовах програмування, наприклад в Smalltalk, модулів немає, і класи складають єдину фізичну основу декомпозиції. В інших мовах, включаючи Object Pascal, C ++, Ada, CLOS, модуль - це самостійна мовна конструкція. в цих мовах класи і об'єкти становлять логічну структуру системи, вони поміщаються в модулі, що утворюють фізичну структуру системи. Це властивість стає особливо корисним, коли система складається з багатьох сотень класів.

Згідно Барбарі Лісков "модульність - це поділ програми на фрагменти, які компілюються окремо, але можуть встановлювати зв'язки з іншими модулями". Ми будемо користуватися визначенням Парнасу: "Зв'язки між модулями - це їхні уявлення один про одного". У більшості мов, що підтримують принцип модульності як самостійну концепцію, інтерфейс модуля відділений від його реалізації. Таким чином, модульність і інкапсуляція ходять рука об руку. У різних мовах програмування модульність підтримується по-різному. Наприклад, в C ++ модулями є відокремленими компільовані файли. Для C / C ++ традиційним є приміщення інтерфейсної частини модулів в окремі файли з розширенням .h (так звані файли-заголовки). Реалізація, тобто текст модуля, зберігається в файлах з розширенням с (в програмах на C ++ часто використовуються розширення .її, .ср і .срр). Зв'язок між файлами оголошується директивою макропроцесора #include. Такий підхід будується виключно на угоді і не є суворою вимогою самої мови. У мові Object Pascal принцип модульності формалізований кілька суворіше. У цій мові визначено особливий синтаксис для інтерфейсної частини і реалізації модуля (unit). Мова Ada йде ще на крок далі: модуль (званий package) також має дві частини - специфікацію і тіло. Але, на відміну від Object Pascal, допускається роздільне визначення зв'язків з модулями для специфікації і тіла пакета. Таким чином, допускається, щоб тіло модуля мало зв'язку з модулями, невидимими для його специфікації.

Правильне поділ програми на модулі є майже такою ж складним завданням, як вибір правильного набору абстракцій.

Модулі виконують роль фізичних контейнерів, в які поміщаються визначення класів і об'єктів при логічному проектуванні системи. Така ж ситуація виникає у проектувальників бортових комп'ютерів. Логіка електронного обладнання може бути побудована на основі елементарних схем типу НЕ, І-НЕ, АБО-НЕ, але можна об'єднати такі схеми в стандартні інтегральні схеми (модулі), наприклад, серій 7400, 7402 або 7404.

Модульність дозволяє зберігати абстракції окремо.

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

Модульність - це властивість системи, яка була розкладена на внутрішньо зв'язкові, але слабо пов'язані між собою модулі.

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

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

ієрархія

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

Ієрархія - це впорядкування абстракцій, розташування їх за рівнями.

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

типізація

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

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

Ідея узгодження типів займає в понятті типізації центральне місце. Наприклад, візьмемо фізичні одиниці виміру. Ділячи відстань на час, ми очікуємо отримати швидкість, а не вагу. У множенні температури на силу сенсу немає, а в множенні відстані на силу - є. Все це приклади сильної типізації, коли прикладна область накладає правила і обмеження на використання та поєднання абстракцій.

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

Поліморфізм означає, що різні об'єкти можуть описувати різні реалізації одного і того ж методу.

Сувора типізація запобігає змішуванню абстракцій.

паралелізм

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

Паралелізм - це властивість, що відрізняє активні об'єкти від пасивних.

Паралелізм дозволяє різним об'єктам діяти одночасно.

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

· "Проміжні результати обчислення виразів.

· Локальні змінні у виклику процедур.

· Власні змінні, глобальні змінні і динамічно створювані дані.

· Дані, що зберігаються між сеансами виконання програми.

· Дані, які зберігаються при переході на нову версію програми.

· Дані, які взагалі переживають програму ".

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

Мови програмування, як правило, не підтримують поняття зберігання; примітним винятком є ​​Smalltalk, в якому є протоколи для збереження об'єктів на диску і завантаження з диска. Однак, записувати об'єкти в неструктуровані файли - це підхід, придатний тільки для невеликих систем.

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

Визначимо збереженість наступним чином:

Збереженість - здатність об'єкта існувати в часі, переживаючи породив його процес, і (або) в просторі, переміщаючись зі свого первісного адресного простору.

Збереженість підтримує стан і клас об'єкта в просторі і в часі.

4.2 Характеристики мов програмування з точки зору елементів об'єктної моделі

Наведемо характеристики об'єктно-орієнтованих мов програмування з точки зору семи основних елементів об'єктної моделі.

Табл.1 Основні характеристики Smalltalk

Табл.2 Основні характеристики Object Pascal.

Табл.3.Основние характеристики C ++.

Табл.4 Основні характеристики CLOS (Common Lisp Object System).

Табл. 5 Основні характеристики Ada

Табл. 6 Основні характеристики Eiffel.

додаток

Таблиця «популярності мов програмування» (TIOBE Programming Community Index for December 2006)

висновок

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

Метою даного огляду була спроба дати уявлення про всьому різноманітті існуючих мов програмування. Серед програмістів часто побутує думка про загальну застосовності тієї чи іншої мови (C, C ++, Pascal і т.п.). Ця думка виникає з кількох причин: брак інформації, звичка, інертність мислення. Справжній професіонал повинен постійно прагнути підвищувати свої професійну кваліфікацію. А для цього потрібно не боятися експериментувати. Зрозуміло, перш ніж братися використовувати нову мову, потрібно уважно вивчити всі його особливості, включаючи наявність ефективної реалізації, можливості взаємодії з існуючими модулями і т.п., і тільки після цього приймати рішення. Звичайно, завжди є ризик піти не тим шляхом, але не помиляється лише той, хто нічого не робить.

Часто проводяться дискусії виду <�мову A краще, ніж мова B>. Прочитавши цей огляд, можна переконається в безглуздості таких суперечок. Максимум, про що може йти мова - це про переваги однієї мови над іншим при вирішенні того чи іншого завдання в тих чи інших умовах. Ось тут дійсно іноді є про що посперечатися. І рішення часом аж ніяк не очевидно.

Цей огляд мов програмування замислювався як відповідь тим, хто кричить <�мову X MUST DIE>. Сподіваюся, що відповідь вийшла досить адекватним і переконливим.

література

1.Інформатіка під редакцією Є. К. Хеннера, М., Академія, 2004 р.

2.Інформатіка.Базовий курс під ред. С. В. Симоновича, С.-П «Пітер» 2005р.

3.Язикі програмування. Огляд-лікнеп. Хакер №4, С.36-40.

4.Р.Богатирев, Природа і еволюція сценарних мов, Світ ПК, №11,2001

5.Г.Буг, Об'єктно-орієнтований аналіз і проектування

6.http: //citforum.ru

7. http: // school.keldysh.ru / sch444 / MUSEUM / LANR / evol.htm

8. http://ru.wikipedia.org

9. http://www.levenez.com/lang

10. http://tiobe.com