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

Языки програмування.

1.Введение.

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

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

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

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

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

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

К кінцю 1950;х років почали з’являтися мови програмування вищого рівня, такі як Lisp, Fortran, ALGOL. Вони не було точної відповідності між мовними конструкціями і машинними командами. Перетворення рядків вихідного коду в послідовності двійкових команд здійснювалося компілятором. Згодом їх кількість поповнилось мовами PL /1, Pascal, З, З++, 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 — x років, та його продуктивність продовжує подвоюватись приблизно кожні 18 місяців. Сьогодні низку додатків може бути реалізовано мовами описи сценаріїв при тим щонайменше чудової продуктивності. Наприклад, TCL — сценарії дозволяє маніпулювати тисячами об'єктів за збереження високого рівня інтерактивності. Принаймні того як комп’ютери будуть ставати швидше і швидще, застосування мов описи сценаріїв ставатиме на місце реалізації дедалі масштабніших додатків.

10. Інші мови.

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

11. Укладання.

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