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

1.Вступ

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

За минулі 15 років у методології написання програм для комп'ютерів відбулася радикальна зміна. Вона полягає в тому, що розробники перейшли від мов програмування системного рівня, таких як. С і. С + +, до мов опису сценаріїв, прикладами яких можуть служити Purl Tell. Хоча в цю зміну виявилося залучено величезну кількість людей, лише деякі з них усвідомлюють, що насправді відбувається, і ще менше знайдеться таких, хто б зміг пояснити причини.

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

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

2. Мови програмування системного рівня.

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

До кінця 50-х років почали з'являтися мови програмування більш високого рівня, такі як Lisp, Fortran, ALGOL. У них вже не було точної відповідності між мовними конструкціями і машинними командами. Перетворення рядків вихідного коду в послідовності двійкових команд здійснювалося компілятором. Згодом їхня кількість поповнилася мовами PL/1, Pascal, C, C + +, Java. Всі вони менш ефективно використовують апаратуру в порівнянні з мовами асемблера, але дозволяє швидше створювати додатки. У результаті їм вдалося практично цілком витиснути мови асемблера при створенні великих додатків.

Мови програмування високого рівня.

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

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

Послідовності виклику процедур генеруються автоматично; програмісту немає необхідності описувати приміщення аргументів функції в стек і їх вилучення звідти;

Для опису структур управління програміст може використовувати також ключові слова, як if, while; послідовності машинних команд, які відповідають цим описам компілятор генерує динамічно.

4. Типізація.

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

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

На противагу цьому для сучасних мов програмування характерна строга типізація. Кожна змінна в мові програмування системного рівня повинна бути оголошена із зазначенням конкретного типу, такого як ціле число або покажчик на рядок символів, і потім використовуватися тільки відповідними цього типу способами.

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

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

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

На малюнку 1 представлено розподіл ряду мов програмування за потужністю і ступеня строгості типізації.

5. Мови опису сценаріїв.

Мови опису сценаріїв, такі як Perl, Python, Rexx, Tcl, Visual Basic і мови оболонок UNIX, припускають стиль програмування, вельми відмінний від характерного для мов системного рівня. Вони призначаються не для написання програми з "нуля", а для комбінування компонентів, набір яких створюється заздалегідь за допомогою інших мов. Наприклад, Tcl, Visual Basic можуть використовуватися для побудови користувацьких інтерфейсів з наявних елементів керування, а мови опису сценаріїв для оболонок UNIX застосовуються для формування "конвеєрів" обробки потоків даних з набору стандартних фільтрів. Мови опису сценаріїв часто застосовуються і для доповнення готових компонентів новими можливостями; однак ця діяльність рідко охоплює створення складних алгоритмів або структур даних, які вже звичайно бувають вже закладені в компоненти. Іноді мови опису сценаріїв навіть називають сполучними або мовами системної інтеграції.

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

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

Select | grep scripting | WC

Програма select зчитує текст, виділений в даний момент на екрані, і виводить його свої вихідний потік; фільтр grep зчитує вхідний потік і пропускає на вихід рядки, що містять слово "scripting", а програма wc підраховує кількість рядків у своєму потоці. Будь-який з таких компонентів може знайти застосування в безлічі різних ситуації, вирішуючи кожен раз іншу загальну задачу. Сильна типізація мов програмування системного рівня ускладнює повторне використання коду. Вона заохочує програмістів до створення великої кількості несумісних один з одним інтерфейсів, кожен з яких вимагає застосування об'єктів свого типу. Компілятор не дозволяє об'єктам інших типів взаємодіяти з цим інтерфейсом, не дивлячись на те, що результат, міг би виявитися і досить корисним. Таким чином, щоб використовувати новий об'єкт із існуючому інтерфейсом, програмісту доводиться писати "перехідник", що перетворить об'єкт до типу, на який розрахований інтерфейс. А застосування "перехідника" вимагає, у свою чергу, перекомпіляції частини чи навіть всього програми цілком. Домінуючий в даний час спосіб розповсюдження ПЗ у вигляді двійкових файлів робить цей підхід неможливим.

Щоб оцінити переваги біс типового мови програмування, розглянемо наступний приклад на мові Tcl:

Button. b-text Hello! -font (Times 16) - command (puts hello).

Ця команда створює на екрані нову кнопку з написом на ній Hello! шрифтом Times 16 пунктів, при натисканні, на яку виводиться коротке повідомлення hello. В одному рядку тут вмістилося шість елементів різних типів: Назва команди (button), назва кнопки (. B), ідентифікатори атрибутів (-text,-font,-command), прості рядки (Hello! Hello), специфікація шрифту (Times 16) , що складається з назви накреслення (Times) і розміру в пунктах (16), а також цілий Tcl-сценарій (puts hello). Всі елементи представляються одноманітно - у вигляді рядків. У даному прикладі атрибути могли бути перераховані в довільному порядку, а неупомянутим атрибутами (їх налічується більше 20) будуть присвоєні значення за замовчуванням.

У разі реалізації на Java той же самий приклад зажадав б семи рядків коду, що складають два методи. Для С + + з використанням бібліотеки Microsoft Foundation Classes (MFC) масштаби збільшилися приблизно до 25 рядків коду, що утворюють три процедури. Один тільки вибір шрифту вимагає декількох зверненні до функціямMFC

Cfont * fontPtr = new Cront ();

fontPtr-> Crete Font (16, 0, 0, 0, 700,

0, 0, 0, ANSI_CHARSET,

OUT_DEFAULT_PRECIS,

CLIP_DEFAULT_PRECIS,

DEFAULT_QUALITY,

DEFAULT_PITCH |

FF_DONTCARE,

"Times New Roman");

buttonPtr-> SetFont (fontPtr);

Можна було б обійтися без значної частини цього коду, якщо б не строга типізація. Щоб задати шрифт для кнопки, необхідно звернутися до методу Set Font; проте він вимагає передачі як аргумент покажчика на об'єкт Cfont. Доводиться оголошувати і ініціалізувати новий об'єкт. Ініціалізація об'єкту Cfont виконує його метод Create Font, який має жорсткий інтерфейс, що вимагає завдання 14 різних аргументів. У TCL істотні характеристики шрифту (накреслення Times і кегль 16 пунктів) можуть бути зазначені безпосередньо без будь-яких оголошень або перетворення. Більш того, TCL дозволяє описати і поведінку кнопки безпосередньо в тілі створює її команди, тоді як в С + + або Java для цього необхідний окремий метод.

Мови опису сценаріїв на підйомі

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

7. Графічні інтерфейси користувача

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

Деякі з систем забезпечені дуже зручними графічними засобами для побудови екранів, які приховують складності що лежить в основі мови, проте, як тільки виникає необхідність у написанні додаткового коду, наприклад, щоб розширити спектр варіантів поведінки елементів інтерфейсу, у розробника відразу виникають труднощі. Усі найкращі середовища прискореної розробки базуються на мовах опису сценаріїв: Visual Basic, HyperCard, TCL/TK.

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

8. Компонентніінфраструктури

Третій приклад застосування мов опису сценаріїв - компонентні інфраструктури, такі як ActiveX, Java Beans. Хоча мови програмування системного рівня з успіхом використовуються для створення компонентів, завдання збірки з них додатків зручніше вирішуються за допомогою сценаріїв. Без гарного мови опису сценаріїв, призначеного для маніпулювання компонентами інфраструктури, втрачається значна частина її переваг. Цим можна пояснити почасти, чому компонентні інфраструктури домоглися більшої популярності в світі ПК, де існує таке зручне сполучна засіб, як Visual Basic, ніж на інших платформах, таких як Unix/Cobra, компонентні інфраструктури, для яких позбавлені мов опису сценаріїв.

9. Технологія сценаріїв

Ще одна причина зростання популярності мов опису сценаріїв - розвиток їх технології. Такі сучасні представники цієї категорії, як TCL, Perl мало чим нагадують своїх далеких попередників на зразок JCL. Так, JCL не передбачав навіть найпростіших форм інтерактивної взаємодії, а ранні UNIX - оболонки не підтримували процедур. Дана технологія ще й сьогодні залишається відносно незрілої. Наприклад, Visual Basic не є в повному розумінні мовою опису сценаріїв. Спочатку він був розроблений в якості спрощеного мови системного рівня, а потім - модифікований так, щоб його було зручніше застосовувати до опису сценаріїв. Таким чином, у майбутніх мов подібного роду є великий простір для вдосконалення.

Крім того, технологія сценаріїв багато виграла від підвищення продуктивності комп'ютерного обладнання. Ще не так давно, щоб домогтися прийнятної швидкості роботи програми будь-якого рівня складності, необхідно було звертатися до мов системного рівня. У деяких випадках навіть їх ефективність виявлялася недостатньою і програму доводилося писати на асемблері. Сучасні машини працюють у 100 - 500 разів швидше комп'ютерів 80 - х років, і їх продуктивність продовжує подвоюватися приблизно кожні 18 місяців. Сьогодні цілий ряд програм може бути реалізований на мовах опису сценаріїв при тим не менш чудовою продуктивності. Наприклад, TCL - сценарії дозволяє маніпулювати тисячами об'єктів при збереженні високого рівня інтерактивності. У міру того, як комп'ютери будуть ставати швидше і швидше, застосування мов опису сценаріїв буде ставати привабливим для реалізації все більш і більш масштабних програм.

10. Інші мови

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

11. Висновок

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