Підвищення продуктивності комп'ютерів і зміни в складі використовуваного ПЗ роблять роль мов опису сценаріїв у створенні додатку майбутнього все більш і більш важливою. Ці мови відрізняються від мов програмування системного рівня тим, що їх основне призначення - пов'язувати різні компоненти і додатки один з одним. виконуючи роль свого роду клею. У них знаходять застосування Безтипові підходи до опису даних, що дозволяє вивести програмування на більш високий рівень і прискорити процес розробки в порівнянні з мовами системного рівня.
За минулі 15 років у методології написання програм для комп'ютерів відбулася радикальна зміна. Вона полягає в тому, що розробники перейшли від мов програмування системного рівня, таких як. З і. С ++, до мов опису сценаріїв, прикладами яких можуть служити PurlTell. Хоча в цю зміну виявилося залучено величезну кількість людей, лише деякі з них усвідомлюють. що в дійсності відбувається. і ще менше знайдеться таких. хто б зміг пояснити причини.
Ці мови створювалися для різних цілей, що зумовило ряд фундаментальних відмінностей між ним. Системні розроблялися для побудови структур даних і алгоритмів "з нуля", починаючи від таких примітивних елементів. як слово пам'яті комп'ютера. На відміну від цього. мови опису сценаріїв створювалися для зв'язування готових програм. Їх застосування має на увазі наявність достатнього асортименту потужних компонентів. які потрібно тільки об'єднати між собою. Мови системного рівня використовують строгий контроль типів, що допомагає розробникам додатку справлятися зі складними завданнями; мови ж опису сценаріїв не використовують поняття типу, що спрощує встановлення зв'язків між компонентами і прискорює розробку прикладних систем.
Мови цих двох типів є взаємодоповнюючими. і більшість комп'ютерних платформ ще з середини 60-х років оснащуються як тими. так і іншими. У компонентних інфраструктурах вони застосовуються. як правило. спільно компоненти створюються на мовах програмування системного рівня. а для їх зв'язку між собою використовуються мови опису сценаріїв. Однак ряд сучасних тенденції. включаючи появу більш швидких машин і більш досконалих мов опису сценаріїв. підвищення значущості графічного інтерфейсу користувача і компонентних архітектур. а також зростання популярності Internet, надзвичайно розширили сферу застосовності мов описи сценаріїв .Развитие цих тенденції продовжитися і в наступному десятилітті. внаслідок чого все більше додатку буде створюватися цілком і повністю на мовах опису сценаріїв. а роль мов програмування системного рівня зведеться майже виключно до створення компонентів.
2. Мови програмування системного рівня.
Щоб усвідомити різницю між мовами опису сценаріїв і системними. корисно згадати історію розвитку останніх. Вперше вони з'явилися в якості альтернативи мов асемблера, що дозволяє використовувати в програмі практично всі особливості конкретної апаратної підсистеми. Кожному твердженням такої мови відповідає рівно одна машинна команда, і програмісту доводиться мати справу з такими низько рівневим деталями, як розподіл регістрів і послідовності виклику процедур. В результаті написання і супроводження великих програм на мові асемблера виявляється надзвичайно складною справою.
До кінця 50-х років почали з'являтися мови програмування більш високого рівня, такі як Lisp, Fortran, ALGOL. У них уже не було точної відповідності між мовними конструкціями і машинними командами. Перетворення рядків вихідного коду в послідовності двійкових команд здійснювалося компілятором. Згодом їх число поповнилося мовами PL / 1, Pascal, C, C ++, Java. Всі вони менш ефективно використовують апаратуру в порівнянні з мовами асемблера, але дозволяє швидше створювати додатки. В результаті їм вдалося практично повністю витіснити мови ассемблера при створенні великих додатків.
Мови програмування високого рівня.
Мови програмування системного рівня відрізняються від ассемблеров, по-перше, тим, що вони є більш високорівневими, і, по-друге, використовують більш строгий контроль типів. Термін "високорівнева" означає наступне: багато деталей обробляються автоматично, а програмісту для створення свого застосування доводиться писати меншу кількість рядків. Зокрема:
Розподілом регістрів займається компілятор, так що програмісту не треба писати код, що забезпечує переміщення даних між регістрами і пам'яттю;
Послідовності виклику процедур генеруються автоматично; програмісту немає необхідності описувати приміщення аргументів функції в стек і їх вилучення звідти;
Для опису структур управління програміст може використовувати також ключові слова, як if, while; послідовності машинних команд, що відповідають цим описам компілятор генерує динамічно.
На противагу цьому для сучасних мов програмування характерна сувора типізація. Кожна змінна в мові програмування системного рівня повинна бути оголошена із зазначенням конкретного типу, такого як ціле число або покажчик на рядок символів, і потім використовуватися тільки відповідними цього типу способами.
Дані і програмний код розділені; створення нового коду по ходу виконання програми утруднено, якщо взагалі можливо. Змінні можуть об'єднуватися в структури або об'єкти з чітко визначеною Субструктура і методами маніпулювання своїми компонентами. Об'єкт одного типу не може бути використаний в ситуації, де наказано застосування об'єкт іншого типу.
Мови опису сценаріїв створювалися для зв'язування готових програм. Їх застосування має на увазі наявність достатнього асортименту потужних компонентів, які потрібно тільки об'єднати між собою.
Типізація дає ряд переваг. По-перше, великі програми стають завдяки їй більш керованими. Чіткість системи типів робить для програміста ясним, для чого призначені ті або інші дані; він легко може розрізняти їх між собою і відповідно використовувати. По-друге, компілятори використовують інформацію про типах для виявлення деяких видів помилок, таких як спроба, використовувати число з плаваючою комою в якості покажчика. По-третє, типізація підвищує продуктивність програми, дозволяючи компіляторам генерувати більш спеціалізований код. Наприклад, якщо компілятору відомо, що деяка змінна завжди містить цілочисельні значення, він може генерувати для маніпулювання нею цілочисельні інструкції; якщо ж тип зміною компілятору невідомий, то приходиться вставляти додаткові інструкції для перевірки типу під час виконання.
На малюнку 1 представлено розподіл ряду мов програмування за проектною потужністю і ступеня строгості типізації.
5. Мови опису сценаріїв.
Мови опису сценаріїв, такі як Perl, Python, Rexx, Tcl, VisualBasic та мови оболонок UNIX, припускають стиль програмування, вельми відмінний від характерного для мов системного рівня. Вони призначаються не для написання програми з "нуля", а для комбінування компонентів, набір яких створюється заздалегідь за допомогою інших мов. Наприклад, Tcl, VisualBasic можуть використовуватися для побудови призначених для користувача інтерфейсів з наявних елементів управління, а мови опису сценаріїв для оболонок UNIX застосовуються для формування "конвеєрів" обробки потоків даних з набору стандартних фільтрів. Мови опису сценаріїв часто застосовуються і для доповнення готових компонентів новими можливостями; однак ця діяльність рідко охоплює створення складних алгоритмів або структур даних, які вже зазвичай бувають вже закладені в компоненти. Іноді мови опису сценаріїв навіть називають сполучними або мовами системної інтеграції.
Для мов опису сценаріїв характерна відсутність типізації, яка тільки ускладнила б завдання з'єднання компонентів. Всі елементи в них виглядають і функціонують однаково і є повністю взаємозамінними. Наприклад, в Tcl або VisualBasic змінна може містити в одній точці програми рядок, а в іншій - ціле число. Код і дані також часто бувають взаємозамінні. Наприклад, Tcl, VisualBasic змінна може містити в одній точці програми рядок, а в іншій - ціле число. Код і дані також часто бувають взаємозамінні, так що програма може генерувати іншу програму - і відразу ж запускати її виконання. Зазвичай мови опису сценаріїв використовують змінні строкових типів, які забезпечують однаковий механізм подання для різних сутностей.
Відсутність в мові поділу змінних на типи спрощує з'єднання компонентів між собою. Ні апріорних обмежень на те, яким чином може використовуватися той чи інший елемент, а всі компоненти значення представляються в єдиному форматі. Таким чином, компонент або значення можуть бути використані в будь-якій ситуації; будучи спроектовані для одних способів застосування, вони можуть виявитися задіяні зовсім іншими, про які їх творець ніколи не думав. Наприклад, в UNIX - оболонках робота будь-якої програми - фільтра включає читання даних з вхідного потоку і запис їх у вихідний потік. Будь-які дві такі програми можуть бути пов'язані шляхом призначення вихідного потоку одній в якості вхідного потоку інший. Наступна команда оболонки являє систему з трьох фільтрів, підраховують у виділеному фрагменті тексту рядки, що містять слово "scipting":
Select | grep scripting | WC
Програма select зчитує текст, виділений в даний момент на екрані, і виводить його свої вихідний потік; фільтр grep зчитує вхідний потік і пропускає на вихід рядки, що містять слово "scripting"; а програма wc підраховує кількість рядків у своєму потоці. Будь-який з подібних компонентів може знайти застосування в безлічі різних ситуації, вирішуючи кожен раз іншу загальну задачу. Сильна типізація мов програмування системного рівня ускладнює повторне використання коду. Вона заохочує програмістів до створення великої кількості несумісних один з одним інтерфейсів, кожен з яких вимагає застосування об'єктів свого типу. Компілятор не дозволяє об'єктам інших типів взаємодіяти з цим інтерфейсом, не дивлячись на те, що результат, міг би виявитися і дуже корисним. Таким чином, щоб використовувати новий об'єкт з існуючому інтерфейсом, програмісту доводиться писати "перехідник", що перетворює об'єкт до типу, на який розрахований інтерфейс. А застосування "перехідника" вимагає, в свою чергу, перекомпіляції частини або навіть всього програми цілком. Домінуючий в даний час спосіб поширення ПО як двійкових файлів робить цей підхід неможливим.
Щоб оцінити переваги біс типового мови програмування, розглянемо наступний приклад мовою Tcl:
Button .b -text Hello! -font - command.Ця команда створює на екрані нову кнопку з написом на ній Hello! шрифтом Times 16 пунктів, при натисканні, на яку виводиться короткий повідомлення hello. В одному рядку тут вмістилося шість елементів різних типів: назва команди (button), назва кнопки (. B), ідентифікатори атрибутів (-text, -font, -command), прості рядки (Hello! Hello), специфікація шрифту (Times 16) , що складається з назви накреслення (Times) і розміру в пунктах (16), а також цілий Tcl-сценарій (putshello). Всі елементи представляються одноманітно - у вигляді рядків. В даному прикладі атрибути могли бути перераховані в довільному порядку, а незгаданих атрибутам (їх налічується понад 20) будуть присвоєні значення за замовчуванням.
У разі реалізації на Java той же самий приклад зажадав б семи рядків коду, що складають два методи. Для С ++ з використанням бібліотеки MicrosoftFoundationClasses (MFC) масштаби збільшилися приблизно до 25 рядків коду, що утворюють три процедури. Один тільки вибір шрифту вимагає декількох зверненні до функціямMFC
Cfont * fontPtr = new Cront ();
fontPtr-> Crete Font (16, 0, 0, 0, 700,
0, 0, 0, ANSI_CHARSET,
"Times New Roman");
Мови опису сценаріїв на підйомі
Мови опису сценаріїв існують вже тривалий час, однак, в останні роки в результаті поєднання низки факторів істотно підвищилася їх актуальність. Найбільш важливий з цих факторів - спрямованість у бік додатку, що збираються з готових компонентів, Як трьох ілюстрації його прояви можна назвати графічні інтерфейси користувача, Internet і компонентні інфраструктури розробки.
7. Графічні інтерфейси користувача
Перші графічні інтерфейси користувача з'явилися на початку 1980 року і набули широкого поширення до кінця десятиліття. Сьогодні на опис цієї частини програми в багатьох проектах йде більше половини всіх зусиллі розробників. GUI за своєю природою є складовою компонентної системою. Мета його створення полягає не в реалізації нових функціональних можливостей, а в тому, щоб налагодити зв'язки між графічними елементами управління і функціями внутрішніх частин програми.
Деякі з систем забезпечені дуже зручними графічними засобами для побудови екранів, які приховують складності що лежить в основі мови, проте, як тільки виникає необхідність в написанні додаткового коду, наприклад, щоб розширити спектр варіантів поведінки елементів інтерфейсу, у розробника відразу виникають труднощі. Всі кращі середовища прискореної розробки засновані на мовах опису сценаріїв: VisualBasic, HyperCard, TCL / TK.
8. Компонентні інфраструктури
Третій приклад застосування мов опису сценаріїв - компонентні інфраструктури, такі як ActiveX, JavaBeans. Хоча мови програмування системного рівня з успіхом використовуються для створення компонентів, завдання збірки з них додатків зручніше вирішуються за допомогою сценаріїв. Без хорошого мови опису сценаріїв, призначеного для маніпулювання компонентами інфраструктури, втрачається значна частина її переваг. Цим можна пояснити почасти, чому компонентні інфраструктури домоглися більшої популярності в світі ПК, де існує таке зручне сполучна засіб, як VisualBasic, ніж на інших платформах, таких як Unix / Cobra, компонентні інфраструктури, для яких позбавлені мов опису сценаріїв.
9.Технологія сценаріїв
Крім того, технологія сценаріїв багато виграла від підвищення продуктивності комп'ютерного обладнання. Ще не так давно, щоб домогтися прийнятної швидкості роботи програми будь-якого рівня складності, необхідно було звертатися до мов системного рівня. У деяких випадках навіть їх ефективність виявлялася недостатньою і програму доводилося писати на асемблері. Сучасні машини працюють в 100 - 500 разів швидше комп'ютерів 80 - х років, і їх продуктивність продовжує подвоюватися приблизно кожні 18 місяців. Сьогодні цілий ряд програм може бути реалізований на мовах опису сценаріїв при тим не менш чудовою продуктивності. Наприклад, TCL - сценарії дозволяє маніпулювати тисячами об'єктів при збереженні високого рівня інтерактивності. У міру того як комп'ютери будуть ставати швидше і швидше, застосування мов опису сценаріїв буде ставати привабливим для реалізації все більш і більш масштабних програм.
10. Інші мови
Мови опису сценаріїв засновані на трохи іншому наборі компромісів, ніж мови системного рівня. У них швидкість виконання і строгість контролю типів ставляться у шкалі пріоритетів на більш низьке місце, але зате вище цінуватися продуктивність праці програміста і повторне використання. Це співвідношення цінностей виявляється все більш виправданим у міру того, як комп'ютери стають швидкодіючими і менш дорогими, чого не можна сказати про програмістів. Мови системного програмування добре підходять для створення компонентів, де основна складність полягає в реалізації алгоритмів і структур даних, тоді як мови опису сценаріїв краще пристосовані для побудови додатку з готових компонентів, де складність полягає в налагодженні межкомпонентних зв'язків. Завдання останнього роду отримують все більше поширення, так що роль парадигми сценаріїв буде зростати і в майбутньому столітті.
Реферати суперські! Зроби паузу, студент, ось розважся: На іспиті з фізики професор намагається витягнути на позитивну оцінку недбайливого студента: - Ви можете назвати прізвище хоча б одного видатного фізика? - Звичайно, ви - професор. До речі, анекдот узятий з chatanekdotov.ru