(Гэты артыкул апублікавана ў часопісе IEEE Computer, сакавік 1 8 гады)
Анатацыя
Мовы сцэнараў, такіх як Perl і Tcl уяўляюць вельмі розныя стыль праграмавання, чым сістэма моў праграмавання, такіх як C ці JavaTM. Мовы сцэнараў прызначаны для "склейвання" прыкладання, яны выкарыстоўваюць Бестиповое падыходаў да дасягнення больш высокага ўзроўня праграмавання і хутчэйшай распрацоўкі прыкладанняў, чым мовы праграмавання сістэмы. Павелічэнне хуткадзейнасці кампутара і змен у прыкладанне сумесі робяць скрыптовыя мовы ўсё больш і важнейшым для прыкладанняў будучыні.
Ключавыя словы: кампанент рамак, аб'ектна-арыентаванага праграмавання, скрыптоў, строгая тыпізацыя, сістэмнае праграмаванне.
За апошнія пятнаццаць гадоў фундаментальныя змены адбываюцца ў тым, як людзі пішуць кампутарныя праграмы. Змена пераход ад сістэмы моў праграмавання, такіх як C ці C + + для скрыптовых моў, такіх як Perl ці Tcl. Хоць шматлікія людзі бяруць удзел у змене, нешматлікія людзі разумеюць, што адбываецца, і яшчэ менш людзей ведаюць, чаму гэта адбываецца. Гэты артыкул з'яўляецца частка меркавання, што тлумачыць, чаму моў сцэнараў будзе апрацоўваць шматлікія задачы праграмавання наступнага стагоддзя лепш, чым мовы праграмавання сістэмы. Мовы сцэнараў прызначаны для выканання розных задач, чым мовы праграмавання сістэмы, і гэта прыводзіць да фундаментальныя адрозненні ў мовах. Мовы праграмавання сістэмы былі распрацаваны для пабудовы структур дадзеных і алгарытмаў "з нуля", пачынальна з самых прымітыўных элементаў кампутара, такіх як колькасць слоў у памяці. У адрозненне ад моў сцэнараў прызначаны для склейвання: яны мяркуюць існаванне набор магутных кампанентаў і прызначаны галоўным чынам для падлучэння кампанентаў разам. Мовы праграмавання сістэмы з'яўляюцца строга тыпізаванымі, каб дапамагчы кіраваць складанасці, у той час скрыптовых моў Бестиповое спрасціць злучэнні паміж кампанентамі і забяспечвае хуткую распрацоўку прыкладанняў.
Мовы сцэнараў і моў праграмавання сістэмы з'яўляюцца ўзаемадапаўняльнымі, і большасць асноўных вылічальных платформаў з 1 60-х гадоў падалі абодвух выглядаў моў. Мовы, як правіла, выкарыстоўваюцца разам у рамках кампанента, дзе кампаненты ствараюцца з мовамі праграмавання сістэмы і склейваюцца з мовамі сцэнараў. Аднак, некалькі апошніх тэндэнцый, такіх, як хутчэй машыны, лепш скрыптовых моў, нарастальнае значэнне графічнага інтэрфейсу карыстача і кампанентных архітэктур, і рост Інтэрнэт, значна павялічылі ўжыванне моў сцэнараў. Гэтыя тэндэнцыі будуць працягвацца на працягу наступнага дзесяцігоддзя, усё больш і больш новых прыкладанняў, цалкам напісаны на мовах сцэнараў і моў праграмавання сістэмы выкарыстоўваюцца галоўным чынам для стварэння кампанентаў.
Для таго каб зразумець адрозненні паміж мовамі сцэнараў і моў праграмавання сістэмы, важна зразумець, як мовы праграмавання, сістэма эвалюцыянавала. Мовы праграмавання сістэмы былі ўведзены ў якасці альтэрнатывы зборкі мовах. У зборку моў, практычна кожны аспект машына знаходзіць сваё адлюстраванне ў праграме. Кожная інструкцыя ўяўляе адну каманду машыны і праграмісты павінны мець справу з нізкім узроўнем дэталі, такія як размеркаванне рэгістраў і паслядоўнасці выкліку працэдур. Як вынік, цяжка пісаць і падтрымліваць вялікія праграмы на асэмблеры. Да канца 1 50-х гадоў больш высокім узроўні такія мовы, як Lisp, Fortran, і Алгол сталі з'яўляцца. У гэтых мовах заявы не адпавядаюць у дакладнасці машынных каманд; кампілятар перакладае кожны выступ у зыходнай праграме ў паслядоўнасці двайковых інструкцый. З часам шэраг моў праграмавання сістэмы эвалюцыянавалі ад Алгола, у тым ліку такія мовы, як PL / 1, Pascal, C, C + + і Java. Мовы праграмавання сістэмы меней эфектыўныя, то зборка мовах, але яны дазваляюць прыкладанням быць распрацаваны значна хутчэй. Як вынік, яны амаль цалкам заменены зборкі моў для развіцця вялікіх прыкладанняў.
Мовы праграмавання сістэмы адрозніваюцца ад зборкі мовах двума спосабамі: яны больш высокага ўзроўня, і яны з'яўляюцца строга тыпізаванымі. Тэрмін "высокі ўзровень" азначае, што шматлікія дэталі апрацоўваюцца аўтаматычна, так што праграмісты могуць пісаць менш кода, каб атрымаць той жа працу. Напрыклад:
У сярэднім, кожны радок кода ў сістэме мовы перакладаецца праграмавання да пяці інструкцый машыны, у параўнанні з адной інструкцыяй на лінію на асэмблеры (у неафіцыйным аналіз васьмі файлаў З пісьмовага пяццю рознымі людзьмі, я выявіў, што каэфіцыент вагаўся ад ад 3 да 7 Інструкцыі ў радку [7] ; у вывучэнні шматлікіх мовах каперсамі Джонс выявіў, што для дадзенай задачы, мантаж мовах запатрабуецца каля 3-6 разу больш радкоў кода, як мовы праграмавання сістэмы [3] ). Праграмісты могуць напісаць прыкладна такое ж колькасць радкоў кода ў год па-за залежнасцю ад мовы [1], так што мовы праграмавання сістэмы дазваляюць прыкладанням быць запісана значна хутчэй, чым на асэмблеры.
Другое адрозненне паміж мовай зборкі і мовы праграмавання сістэмы друку. Я выкарыстоўваю тэрмін "набраўшы" для пазначэння ступені, у якой сэнс інфармацыі, паказанай у загадзя яе выкарыстанні. У моцна тыпізаваных мовах праграміст заяўляе, якім чынам кожная частка інфармацыі будзе выкарыстоўвацца, і мова не дазваляе інфармацыі быць скарыстаны любым іншым спосабам. У слаба тыпізаваную мову Ёсць ніякіх апрыёрных абмежаванняў пра тое, як інфармацыя можа быць скарыстана: сэнс інфармацыі вызначаецца толькі, як яны выкарыстоўваюцца, а не любой пачатковай абяцанні. 1
Сучасныя кампутары з'яўляюцца прынцыпова Бестиповое: любое слова ў памяць можа захоўваць любыя каштоўнасці, такія як лік, лік з плывучай коскі, паказальнік ці інструкцыі. Сэнс значэнне вызначаецца тым, як ён выкарыстоўваецца: калі лічыльнік кропкі на слова памяці, то ён разглядаецца як інструкцыя, калі слова высылаецца цэлае дадаць інструкцыі, то ён разглядаецца як цэлае, і гэтак далей. То ж слова можа быць скарыстана па-рознаму ў розны час.
У супрацьлегласць гэтаму, сістэма сёння моў праграмавання з'яўляюцца строга тыпізаванымі. Напрыклад:
Typing мае шэраг пераваг. Па-першае, ён робіць вялікія праграмы больш кіраваным шляхам удакладнення, як рэчы выкарыстоўваюцца і адрозненні паміж рэчамі, якія павінны быць па-рознаму. Па-другое, кампілятары могуць выкарыстоўваць інфармацыю пра тыпы для выяўлення некаторых выглядаў памылак, такіх як спроба выкарыстоўваць значэнне з плывучай коскі ў якасці паказальніка. Па-трэцяе, набраўшы павялічвае прадукцыйнасць, дазваляючы кампілятарам генераваць спецыялізаваны код. Напрыклад, калі кампілятару вядома, што зменная заўсёды мае месца цэлы лік, то ён можа генераваць цэлыя інструкцыі маніпуляваць зменнай, калі кампілятар не ведае тып зменнай, то ён павінен генераваць дадатковыя інструкцыі для праверкі зменнай тыпу на выкананні. Такім чынам, у мовах праграмавання сістэмы прызначаны для працы з той жа задачы, як зборка моў, а менавіта стварэнне прыкладанняў з нуля. Сістэма мовах праграмавання высокага ўзроўня і шматлікае іншае, чым строга тыпізаваных моў асэмблера. Гэта дазваляе прыкладанням быць створаны хутчэйшае і лягчэйшае кіраваныя толькі невялікая страта ў прадукцыйнасці. Гл. малюнак 1 для графічнага параўнання асэмблеры і некалькі моў праграмавання сістэмы.
Мовы сцэнараў, такіх як Perl [ ], Python [4], Rexx [6], Tcl [8], Visual Basic і Unix снарады ўяўляюць вельмі розныя стыль праграмавання, чым мовы праграмавання сістэмы. Мовы сцэнараў мяркуецца, што ўжо існуе набор карысных
кампанентаў, напісаных на іншых мовах. Мовы сцэнараў не прызначаны для напісання прыкладанняў з нуля, яны прызначаны галоўным чынам для падлучэння разам кампаненты. Напрыклад, Tcl і Visual Basic могуць быць скарыстаны для арганізацыі калекцый кіравання карыстацкага інтэрфейсу на экране, і сцэнараў абалонкі UNIX выкарыстоўваецца для зборкі праграм-фільтраў у трубаправоды. Мовы сцэнараў часта выкарыстоўваюцца, каб пашырыць магчымасці кампанентаў, але яны рэдка выкарыстоўваюцца для складаных алгарытмаў і структур дадзеных, функцыі, як гэта звычайна падаецца кампанентаў. Мовы сцэнараў часам завуць як
клей моў ці
моў інтэграцыі сістэмы. Для таго, каб спрасціць задачу падлучэння кампанентаў, скрыптовых моў, як правіла, без тыпаў: усе рэчы выглядаюць і паводзяць сябе гэтак жа так, што яны ўзаемазаменныя. Напрыклад, у Tcl ці Visual Basic зменная можа ўтрымоўваць радок адзін момант і цэлыя наступнай. Код і дадзеныя часта ўзаемазаменныя, так што праграма можа напісаць яшчэ адну праграму, а затым выканаць яго на лёце. Мовы сцэнараў часта радок-арыентаваных, бо гэта забяспечвае аднастайнае ўяўленне для розных рэчаў.
Бестиповое мовы робіць яго значна лягчэй падлучыць разам кампаненты. Ёсць ніякіх апрыёрных абмежаванняў пра тое, як рэчы могуць быць скарыстаны, і ўсе кампаненты і значэнні прадстаўлены ў аднастайна. Такім чынам, любы кампанент ці значэнне могуць быць скарыстаны ў любой сітуацыі; кампанентаў, прызначаных для адной мэты можа быць скарыстаны для зусім розных мэт ніколі не прадугледжаных дызайнера. Напрыклад, у абалонках Unix, усё фільтра праграм чытаць струмень байтаў з уваходнага і напісаць радок байтаў у выходнай; любыя дзве праграмы могуць быць злучаны паміж сабой шляхам далучэння выйсце адной праграмы на ўваход іншай. Наступныя каманды абалонкі стэкі трох фільтраў разам, каб падлічыць колькасць радкоў у выбары, якія ўтрымоўваюць слова "сцэнараў":
абраць | GREP сцэнараў | туалет
Абярыце Праграма чытае тэкст, які абраны ў дадзены момант на дысплеі і выводзіць яе на сваю прадукцыю; select GREP праграма счытвае інфармацыю і выводзіць на выйсці радка, якія змяшчаюць "сцэнараў"; grep туалет праграма падлічвае колькасць радкоў на ўваходзе. wc Кожная з гэтых праграм можа быць скарыстаны ў шматлікіх іншых сітуацыях для выканання розных задач. Строга тыпізаваны характар моў праграмавання сістэмы перашкаджае паўторнаму выкарыстанню. Увод заклікае праграмістам ствараць розныя несумяшчальныя інтэрфейсы ("інтэрфейсы добрыя; некалькі інтэрфейсаў лепш"). Кожны інтэрфейс патрабуе аб'ектаў вызначанага тыпу і кампілятар прадухіляе любыя іншыя тыпы аб'ектаў ад выкарыстання з інтэрфейсам, нават калі гэта будзе карысна. Для таго каб выкарыстоўваць новы аб'ект з існым інтэрфейсам, пераўтварэнні код павінен быць запісаны на пераклад паміж тыпам аб'екта і тыпу чакаецца ў інтэрфейсе. Гэта, у сваю чаргу, патрабуе перакампілявання часткі ці ўсіх прыкладанняў, якія немагчымыя ў звычайным выпадку, калі прыкладанне распаўсюджваецца ў бінарным выглядзе.
Каб убачыць перавагі Бестиповое мова, разгледзім наступныя каманды Tcl:
кнопку. B-тэкст Прывітанне! -Шрыфт Times {16} {-каманды ставіць прывітанне}
Гэта каманда стварае новыя кнопкі кіравання, што адлюстроўвае тэкставы радок у 16-кропкавага шрыфта Times і друкуе кароткае паведамленне, калі карыстач пстрыкае на элеменце кіравання. Ён змешвае шэсць розных тыпаў рэчаў у адной інструкцыі: назва каманды (
button ), кнопкі кіравання (
.b (), імёны ўласцівасцяў
-text,
-font, і
-command ), простыя радкі (
Hello! і
hello ) назва шрыфта (
Times 16 ), што складаецца з імя шрыфта (
Times ) і памеру ў пунктах (
16 ), і скрыпт Tcl (
puts hello ). Tcl уяўляе ўсе гэтыя рэчы раўнамерна з радкамі. У гэтым прыкладзе ўласцівасці могуць быць паказаны ў любым парадку і нявызначанай уласцівасці прыведзены значэнні па змаўчанні, больш 20 аб'ектаў былі не паказаны ў прыкладзе.
Той жа прыклад патрабуе 7 радкоў кода ў двух метадаў пры рэалізацыі ў Java. З C + + і Microsoft Foundation Classes, ён патрабуе каля 25 радкоў кода ў трох працэдур (гл. [7] для кода для гэтых прыкладаў). Проста налады шрыфта патрабуе некалькіх радкоў кода ў Microsoft Foundation Classes робіць:
CFont * fontPtr = новы CFont ();
fontPtr-> CreateFont (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);
Вялікая частка гэтага кода з'яўляецца следствам строгай тыпізацыі. Для таго каб усталяваць шрыфт кнопку, яе SetFont метад павінен быць выкліканы, але гэты метад павінен быць перададзены паказальнік на CFont аб'екта. Гэта, у сваю чаргу, патрабуе новага аб'екта, які быў абвешчаны і ініцыялізаваны. Для таго, каб ініцыялізаваць CFont аб'екта яго CreateFont метад павінен быць выкліканы, але CreateFont мае цвёрды інтэрфейс, які патрабуе 14 розных аргументаў будзе вызначаны пазней. У Tcl, істотныя характарыстыкі шрыфта (шрыфт Times, памер 16 пунктаў) могуць быць скарыстаны неадкладна без якіх-небудзь заяў ці пераўтварэнні. Акрамя таго, Tcl дазваляюць паводзіны кнопкі павінны быць уключаны непасрэдна ў каманду, якая стварае кнопку, у той час як C + + і Java патрабуе ад яго быць змесцаваны ў асобна заяўленага спосабу. (На практыку, трывіяльны прыклад, як гэта, верагодна, будзе апрацоўвацца з графічным асяроддзем распрацоўкі, якая хавае складанасць асноўная мова: карыстач уводзіць значэнні ўласцівасцяў у форме і асяроддзі распрацоўкі выйсцяў код. Аднак, у больш складаных сітуацыях, такіх як умоўнае заданне значэнняў уласцівасцяў ці інтэрфейсы спароджаных праграмна, распрацоўнік павінен напісаць код у базавай мове.)
Можа здацца, што без тыпаў характару моў сцэнараў можа дазволіць памылкі застаюцца незаўважанымі, але на практыку скрыптовых моў, гэтак жа бяспечныя, як мовы праграмавання сістэмы. Напрыклад, памылка можа адбыцца, калі памер шрыфта, паказаны для кнопкі прыведзены вышэй прыклад не з'яўляецца цэлы лік радкоў, такіх як xyz. Розніца ў тым, што мовы сцэнараў рабіць памылак у самы апошні момант, калі значэнне выкарыстоўваецца. Строгая тыпізацыя дазваляе памылкі быць выяўлены падчас кампіляцыі, таму кошт падчас праверкі можна пазбегнуць. Тым не менш, кошты на аплату гэтага эфектыўнасць абмежавання на інфармацыю можа быць скарыстаны: гэта прыводзіць да больш код і меней гнуткіх праграм.
Яшчэ адно важнае адрозненне паміж скрыптовых моў і моў праграмавання сістэмы з'яўляецца тое, што мовы сцэнараў, якія звычайна тлумачацца ў той час як мовы праграмавання сістэмы, як правіла, складзены. Інтэрпрэтаваных моў забяспечваюць хуткі заваротак падчас развіцці шляхам ухілення час кампіляцыі. Перакладнікі таксама зрабіць прыкладанні больш гнуткай, дазваляючы карыстачам праграмы прыкладання падчас выканання. Напрыклад, шматлікія сінтэзу і аналізу для інтэгральных схем уключаюць Tcl перакладніка; карыстачоў праграмы напісаць Tcl скрыпт для іх канструкцыі і кіраванні працай прылады. Перакладнікі таксама дазволіць магутныя эфекты павінны быць дасягнуты да генерацыі кода на лёце. Напрыклад, Tcl на аснове вэб-браўзара можа аналізаваць вэб-старонкі шляхам перакладу HTML для старонкі ў Tcl скрыпт, выкарыстоўваючы некалькі рэгулярнай замены выраза. Затым ён выконвае Tcl скрыпт для адлюстравання старонкі на экране.
Мовы сцэнараў меней эфектыўныя, чым мовы праграмавання сістэмы, у прыватнасці, таму што яны выкарыстоўваюць перакладнікі замест кампілятараў, але і таму, што іх асноўныя кампаненты падабраны для магутнасці і прастаце выкарыстання, а не эфектыўнага адлюстравання на адпаведнай апаратуры. Напрыклад, мовы сцэнараў часта выкарыстоўваюць радкі зменнай даўжыні ў сітуацыях, калі мова праграмавання, сістэма будзе выкарыстоўваць двайковае значэнне, якое ўпісваецца ў адно слова машына, і моў сцэнараў, часта выкарыстоўваюць хэш-табліцы, дзе мовы праграмавання сістэмы выкарыстоўваюцца індэксаваныя масівы.
Да шчасця, выкананне сцэнараў мовы звычайна не галоўная праблема. Заяўкі на скрыптовых мовах, як правіла, менш, чым прыкладанняў для моў праграмавання сістэмы, і выкананне сцэнараў прыкладання, як правіла, дамінуюць прадукцыйнасці кампанентаў, якія звычайна рэалізаваны ў мове праграмавання сістэмы.
Скрыптовых моў высокага ўзроўня, чым мовы праграмавання сістэмы, у тым сэнсе, што адзін аператар робіць больш працы ў сярэднім. Тыповыя заява ў скрыптовую мову выконвае сотні і тысячы машынных каманд, у той час як тыповы заява, у мове праграмавання сістэмы выконвае каля пяці машынных інструкцый (гл. Малюнак 1 ). Частка гэтай розніцы ў тым, што мовы сцэнараў выкарыстання вусновых перакладнікаў, якія з'яўляюцца меней эфектыўнымі, чым скампіляваны код для моў сістэмнага праграмавання. Але вялікая частка розніцы ў тым, што прымітыўныя аперацыі ў мовах сцэнараў, маюць вялікую функцыянальнасць. Напрыклад, у Perl гэта прыкладна гэтак жа лёгка выклікаць рэгулярныя падстановы выраза, як гэта павінна выклікаць цэлае таго. У Tcl, зменная можа мець сляды, злучаныя з яго так, што ўсталёўка зменнай выклікае пабочныя эфекты, напрыклад, след можа быць скарыстаны для трымаць значэнне зменнай увесь час абнаўляецца на экране.
З-за апісаных вышэй, мовы сцэнараў дазваляюць вельмі хуткае развіццё для прыкладанняў, якія склейванні-арыентаванай. табліца 1 забяспечвае анекдатычных падтрымкі па гэтай прэтэнзіі. Ён апісвае некалькі прыкладанняў, якія былі рэалізаваны ў мове праграмавання сістэмы, а затым перавызначаны ў скрыптовую мову, ці наадварот.
У кожным выпадку сцэнараў версіі патрабуецца менш кода і час распрацоўкі, чым версія сістэмы праграмавання; розніца вар'іравалася ад 2 разу да 60 раз. Мовы сцэнараў пры ўмове менш выгод, калі яны былі скарыстаны для першай рэалізацыі; гэта кажа пра тое, што любой перавызначанай перавагі істотна адрозніваецца ад досведу першай рэалізацыі і што праўдзівае адрозненне паміж сцэнараў і сістэмнае праграмаванне больш падобна фактар 5-10x, чым крайнія кропкі табліцы. Перавагі сцэнараў таксама залежыць ад прыкладання. У апошнім прыкладзе з табліцы частка графічнага інтэрфейсу прыкладання склейвання-арыентаваны, але сімулятар частка не з'яўляецца, гэта можа растлумачыць, чаму прыкладанне карысць меней са сцэнараў, чым у іншых прыкладаннях.
Такім чынам, скрыптовых моў прызначаны для склейвання прыкладанняў. Яны забяспечваюць больш высокі ўзровень праграмавання, чым зборка ці сістэма моў праграмавання, значна слабей, чым уводзіць моў праграмавання сістэмы, і інтэрпрэтаваць асяроддзі распрацоўкі. Мовы сцэнараў ахвяру хуткасці выканання для паляпшэння развіцця хуткасці.
Скрыптовая мова не з'яўляецца заменай для мовы праграмавання сістэмы і наадварот. Кожны падыходзіць для розных набору задач. Для склейвання і сістэмнай інтэграцыі, прыкладанні могуць быць распрацаваны 5-10 раз хутчэй, з мовы сцэнараў; мовы праграмавання сістэмы патрабуюць вялікай колькасці шаблоннага і пераўтварэнні кода, каб звязацца штук, у той час як гэта можна зрабіць непасрэдна з мовы сцэнараў. Для складаных алгарытмаў і структур дадзеных, строгай тыпізацыі мовы праграмавання сістэмы робіць праграмы лягчэй кіраваць. Дзе хуткасць выканання з'яўляецца ключавы, мова праграмавання, сістэма можа часта працуюць 10-20 раз хутчэй, чым мова сцэнараў, паколькі яна робіць менш часу выканання праверак. Пры рашэнні пытання, ці варта выкарыстоўваць скрыптовую мову ці мова сістэмнага праграмавання для рашэння пэўнай задачы, разгледзець наступныя пытанні:
"Ды" Адказы на гэтыя пытанні дазваляюць выказаць здагадку, што мова сцэнараў будзе добра працаваць для прыкладання. З іншага боку, "так", адказы на наступныя пытанні паказваюць, што ўжыванне лепш падыходзіць для мовы праграмавання сістэмы: Большасць асноўных вылічальных платформаў на працягу апошніх 30 гадоў стварылі як сістэма праграмавання і моў сцэнараў. Напрыклад, адным з першых моў сцэнараў, хоць і грубіянскай, быў JCL (Job Control Language), які быў скарыстаны для крокаў задання паслядоўнасці ў OS/360. Асобных этапаў працы былі напісаны ў PL / 1, Fortran, ці на мове асэмблера, якія былі сістэмы моў праграмавання дзень. У Unix машыны 1 80-х гадоў, C быў скарыстаны для праграмавання сістэмы і абалонкі праграмы, такія як sh і csh для сцэнараў. У свеце персанальных кампутараў 1 0-х гадоў, C і C + + выкарыстоўваецца для сістэмнага праграмавання і Visual Basic для напісання скрыптоў. У свеце Інтэрнэту, якая складаецца цяпер, Java выкарыстоўваецца для сістэмнага праграмавання і такія мовы, як JavaScript, Perl, Tcl і выкарыстоўваюцца для напісання сцэнараў. Сцэнары і сістэмы праграмавання симбиотических. Выкарыстоўваецца разам, яны вырабляюць асяроддзі праграмавання вылучнай сілы: мовы праграмавання сістэмы выкарыстоўваюцца для стварэння захапляльных кампанентаў, якія затым могуць быць сабраны з выкарыстаннем моў сцэнараў. Напрыклад, вялікая частка прыцягненне Visual Basic з'яўляецца тое, што сістэма праграмісты могуць пісаць ActiveX кампанентаў у C і меней складаныя праграмісты могуць выкарыстоўваць кампаненты ў Visual прыкладанняў Basic. У Unix лёгка пісаць скрыпты, якія выклікаюць прыкладанні, напісаныя на C. Адна з чыннікаў папулярнасці Tcl з'яўляецца здольнасць да пашырэння мовы C, напісаўшы код, які рэалізуе новыя каманды.
Мовы сцэнараў існуюць ужо даўно, але ў апошнія гады некалькі фактараў у сукупнасці павелічэнне іх важнасці. Найболей важным фактарам з'яўляецца змена ў прыкладанне да сумесі склейвання прыкладанняў. Тры прыкладу гэтага зруху графічныя інтэрфейсы карыстача, Інтэрнэт, і кампанент рамак. Графічны інтэрфейс карыстача (GUI) упершыню пачалі з'яўляцца напачатку 1 80-х і атрымала шырокі распаўсюд да канца дзесяцігоддзя; ГПИ у наш час складаюць палову ці больш ад агульнага высілка ў шматлікіх праграмных праектах. ГПИ прынцыпова склейванні прыкладанняў: мэта складаецца не ў стварэнні новых функцыянальных магчымасцяў, але, каб зрабіць сувязь паміж набор графічных элементаў кіравання і ўнутраныя функцыі прыкладання. Я не ведаю ні хуткай распрацоўкі ўмоў для графічных інтэрфейсаў на аснове мовы праграмавання сістэмы. Будзь асяроддзю Windows, Macintosh Toolbox, ці Unix Motif, распрацоўкі GUI на аснове моў, як C ці C + + апынуліся цяжка вучыцца, нязграбныя ў выкарыстанні, і нягнуткімі ў вынікі, якія яны вырабляюць. Некаторыя з гэтых сістэм маюць вельмі прыемную графічную прыладу для стварэння экраннага якія хаваюць асноўную мову, але ўсё становіцца цяжка, як толькі дызайнер, каб напісаць код, напрыклад, каб забяспечыць паводзін для элементаў інтэрфейсу. Усё лепшае хуткай распрацоўкі GUI асяроддзі заснаваны на мовах сцэнараў: Visual Basic, HyperCard, і Tcl / Tk. Такім чынам скрыптовыя мовы выраслі ў папулярнасці, як важнасць графічнага інтэрфейсу ўзрасла.
Рост Інтэрнэт таксама папулярызаваць моў сцэнараў. Інтэрнэт гэта не больш чым прылада склейвання. Яна не стварае якіх-небудзь новых вылічэнняў ці дадзеных, ён проста робіць велізарную колькасць існых рэчаў лёгка даступныя. Ідэальнай мовай для большасці задач праграмавання Інтэрнэту, якая робіць магчымым для ўсіх складных кампанент працаваць разам, гэта значыць мова сцэнараў. Напрыклад, Perl стаў папулярным для напісання CGI скрыптоў і JavaScript папулярны для сцэнараў на вэб-старонках.
Трэці прыклад са сцэнараў-арыентаваных прыкладанняў з'яўляецца кампанентам структуры, такія як ActiveX, OpenDoc, і JavaBeans. Хоць мовы сістэмнага праграмавання добра падыходзяць для стварэння кампанентаў, задача зборкі кампанентаў у прыкладанні лепш падыходзіць для сцэнараў. Без добрай мовы сцэнараў для кіравання кампанентамі, вялікая частка магутнасці кампанент рамках губляецца. Гэта можа часткова растлумачыць, чаму кампанентам структуры былі больш паспяховымі на ПК (дзе Visual Basic падае зручная прылада сцэнараў), чым на іншых платформах, такіх як Unix / CORBA, дзе сцэнараў не ўваходзіць у рамкі кампанента.
Іншым чыннікам якая расце папулярнасці моў сцэнараў з'яўляецца паляпшэнне сцэнараў тэхналогіі. Сучасныя мовы сцэнараў, такія як Perl і Tcl з'яўляюцца далёка ад ранніх моў сцэнараў, такіх як JCL. Напрыклад, JCL нават не забяспечваюць асноўныя ітэрацыі і напачатку абалонак Unix не падтрымліваюць працэдур. Сцэнары тэхналогія ўсё яшчэ адносна няспелыя нават сёння. Напрыклад, Visual Basic насамрэч не скрыптовая мова, ён быў першапачаткова рэалізаваны ў выглядзе простай мовы праграмавання сістэмы, тая змена, каб зрабіць яго больш падыходным для сцэнараў. Будучыя мовы сцэнараў будзе нават лепш, чым тыя, якія даступныя сёння.
Сцэнары тэхналогіі таксама выгаду ад усё нарастальнай хуткасцю кампутарнага абсталявання. Раней лічылася, што адзіны спосаб атрымаць прымальную прадукцыйнасць у прыкладанні любой складанасці было выкарыстоўваць мову праграмавання сістэмы. У некаторых выпадках нават моў праграмавання сістэмы не былі досыць эфектыўнымі, так што прыкладанні павінны быць напісаны на асэмблеры. Тым не менш, машыны сёння 100-500 раз хутчэй, чым машыны 1 80 гады і яны па-ранейшаму ў два разу прадукцыйнасці кожныя 18 месяцаў. Сёння шматлікія прыкладанні могуць быць рэалізаваны ў інтэрпрэтаваную мову і ўсё яшчэ мець выдатную прадукцыйнасць, напрыклад, скрыпт Tcl можа маніпуляваць калекцыі некалькі тысяч аб'ектаў і па-ранейшаму забяспечваюць добрую інтэрактыўнага адказу. Бо кампутары становяцца хутчэй, сцэнараў стане прывабнай для вялікіх і вялікіх прыкладанняў.
Адзін апошні чыннік для шырэйшага выкарыстання моў сцэнараў з'яўляецца змена праграміст супольнасці. Дваццаць гадоў назад большасць праграмістаў былі складаныя праграмістаў, якія працуюць над буйнымі праектамі. Праграмісты з той эпохі, як чакаецца, правесці некалькі месяцаў асвоіць мову і яго асяроддзе праграмавання, мовы праграмавання і сістэмы былі распрацаваны для такіх праграмістаў. Аднак, бо прыход персанальны кампутар, усё больш і больш выпадковы праграмістаў далучыліся праграміст супольнасці. Для гэтых людзей, праграмаванне не з'яўляецца іх асноўнай функцыяй працу, гэта прылада, які яны часам выкарыстоўваць, каб дапамагчы з іх асноўнай працай. Прыклады выпадковых праграмавання простых запытаў да базы дадзеных і макрасаў для электронных табліц. Паўсядзённы праграмісты не жадаюць марнаваць месяцы на вывучэнне мовы праграмавання сістэмы, але яны могуць пазнаць досыць пра мову сцэнараў у некалькі гадзін, каб пісаць карысныя праграмы. Мовы сцэнараў лягчэй вучыцца, таму што яны маюць просты сінтаксіс, чым мовы праграмавання сістэмы і таму, што яны апускаць комплекс функцый, такіх як аб'екты і тэмы. Напрыклад, параўнаць Visual Basic з Visual C + +; некалькі выпадковых праграмісты будуць спрабаваць выкарыстоўваць Visual C + +, але шматлікія з іх былі ў стане пабудаваць карысных прыкладанняў з дапамогай Visual Basic.
Нават сёння лік прыкладанняў, напісаных на мовах сцэнараў значна больш, чым лік прыкладанняў, напісаных на мовах праграмавання сістэмы. У Unix сістэмах Ёсць яшчэ вельмі шмат скрыптоў, чым З-праграм, і пад Windows Ёсць яшчэ вельмі шмат Visual Basic праграмістаў і прыкладанняў, чым З ці З + +. Вядома, большасць з найбуйных і найболей шырока выкарыстоўваныя прыкладанні напісаны на мовах праграмавання сістэмы, так што параўнанне на аснове агульнага радкоў кода ці колькасць усталяваных дзід могуць па-ранейшаму карысць моў праграмавання сістэмы. Тым не менш, скрыптовых моў ужо асноўнай рухальнай сілай у распрацоўцы прыкладанняў і іх дзель на рынку будзе павялічвацца ў будучыні.
Мовы сцэнараў былі галоўным чынам ігнаруюцца экспертаў у мовах праграмавання і распрацоўкі праграмнага забеспячэння. Замест гэтага яны засяродзілі сваю ўвагу на аб'ектна-арыентаваных моў праграмавання сістэмы, такія як C + + і Java. Аб'ектна-арыентаванага праграмавання шырока распаўсюджанаму меркаванню, уяўляюць наступны важны крок у эвалюцыі моў праграмавання. Аб'ектна-арыентаванага праграмавання, такіх як строгая тыпізацыя і ўспадкоўванне часта сцвярджаў, скараціць час распрацоўкі, праграмнае забеспячэнне паўторнага павелічэння, і вырашыць шматлікія іншыя праблемы, у тым ліку тых, якімі займаліся моў сцэнараў. Колькі дапаможнік аб'ектна-арыентаванага праграмавання фактычна прадстаўленых? Нажаль, я не бачыў досыць колькасных дадзеных для адказу на гэта пытанне канчаткова. Па маім меркаванні аб'ектаў забяспечыць толькі сціплую перавагу: магчыма, 20-30% паляпшэнні ў прадукцыйнасці, але, вядома, не ў два разу, не кажучы ўжо 10 раз. C + +, зараз, падобна, бэсцілі гэтулькі, колькі гэта кахаюць, а некаторыя мова эксперты пачынаюць выступаць супраць аб'ектна-арыентаванага праграмавання [2]. Далей у гэтай частцы тлумачыцца, чаму аб'екты не падвышэнні прадукцыйнасці працы ў драматычнай выявай, што сцэнары робіць, і ён сцвярджае, што перавагі аб'ектна-арыентаванага праграмавання можа быць дасягнута ў скрыптовых мовах.
Чыннік аб'ектна-арыентаванага праграмавання не дае вялікага паляпшэння ў прадукцыйнасці, што яна не паднімае ўзровень праграмавання ці заахвочваць паўторнае выкарыстанне. У аб'ектна-арыентаваных моў, такіх як C + + праграмістаў, па-ранейшаму працаваць з малымі базавых велічынь, якія павінны быць апісаны і маніпуляваць у драбнюткіх падрабязнасцях. У прынцыпе, магутныя пакеты, бібліятэкі могуць быць распрацаваны, і калі гэтыя бібліятэкі шырока выкарыстоўваліся яны маглі б павялічыць узровень праграмавання. Аднак, не так шмат такіх бібліятэк прыйшоў у існаванне. Строгая тыпізацыя большасці аб'ектна-арыентаваных моў заклікае вузка пакеты, якія цяжка выкарыстоўваць паўторна. Кожны пакет патрабуе аб'екты вызначанага тыпу, калі два пакета, каб працаваць разам, пераўтварэнні код павінен быць запісаны на пераклад паміж тыпамі неабходных пакетаў.
Іншая праблема, з аб'ектна-арыентаваных моў з'яўляецца іх акцэнт на спадчыну. Успадкоўванне рэалізацыі, дзе адзін клас запазычае код, які быў напісаны для іншага класа, з'яўляецца дрэннай ідэяй, што робіць праграмнае забеспячэнне цяжэй кіраваць і паўторна выкарыстоўваць. Ён злучаецца рэалізацыі класаў разам так, што ні клас можа быць зразумета без іншага: падклас не можа быць зразумета не ведаючы, як успадкаваныя метады рэалізаваны ў яго суперкласса, і суперкласса не могуць быць зразуметы не ведаючы, як яго метады ўспадкоўваюцца ў падкласах. У складанай іерархіі класа, не асобнага класа могуць быць зразуметы без разумення ўсіх іншых класаў у іерархіі. Што яшчэ горш, клас не можа быць адлучана ад яго іерархіі для паўторнага выкарыстання. Множнае ўспадкоўванне робіць гэтыя праблемы яшчэ горш. Успадкоўванне рэалізацыі выклікае такое ж перапляценне і далікатнасць, якія назіраліся пры goto справаздачнасць марнатравіць. Як вынік, аб'ектна-арыентаваныя сістэмы часта пакутуюць ад складанасці і адсутнасці паўторнага выкарыстання.
Мовы сцэнараў, з іншага боку, насамрэч прыводзілі да істотных паўторнага выкарыстання праграмнага забеспячэння. Яны выкарыстоўваюць мадэль, у якой цікава кампаненты ўбудаваны ў мову праграмавання сістэмы, а затым склейваюцца ў прыкладанні з дапамогай мовы сцэнараў. Гэты падзел працы забяспечвае натуральную аснову для паўторнага выкарыстання. Кампаненты прызначаны для шматразовага выкарыстання, і Ёсць выразна вызначаныя інтэрфейсы паміж кампанентамі і скрыптоў, якія дазваляюць лёгка выкарыстоўваць кампаненты. Напрыклад, у Tcl кампанентаў карыстацкіх каманд рэалізаваны на мове З, яны выглядаюць як убудаваныя каманды, каб яны лёгка высылацца ў Tcl скрыптоў. У Visual Basic ActiveX кампаненты пашырэння, якія могуць быць скарыстаны шляхам перацягвання іх з палітры на форму.
Тым не менш, аб'ектна-арыентаванага праграмавання не прадугледжвае прынамсі дзве карысныя функцыі. Першы інкапсуляцыі: аб'екты аб'ядноўваюцца разам дадзеныя і код такім чынам, што хавае дэталі рэалізацыі. Гэта спрашчае кіраванне вялікімі сістэмамі. Другой карыснай функцыяй з'яўляецца ўспадкоўванне інтэрфейсу, які ставіцца да класаў, якія падаюць тыя ж метады і API, хоць яны і маюць розныя рэалізацыі. Гэта робіць класаў узаемазаменныя, што спрыяе паўторнаму выкарыстанню.
Да шчасця, выгады ад аб'ектаў можа быць дасягнута ў скрыптовых мовах, а таксама моў праграмавання сістэмы і практычна ўсе мовы сцэнараў ёсць падтрымка аб'ектна-арыентаванага праграмавання. Напрыклад, Python з'яўляецца аб'ектна-арыентаваная мова сцэнараў, Perl версіі 5 уключае падтрымку для аб'ектаў, аб'ектаў Rexx з'яўляецца аб'ектна-арыентаваная версія Rexx, і INCR Tcl з'яўляецца аб'ектна-арыентаванае пашырэнне для Tcl. Адно з адрозненняў з'яўляецца тое, што аб'екты ў мовах сцэнараў, як правіла, без тыпаў, у той час як аб'екты ў мовах праграмавання сістэмы, як правіла, строга тыпізаваным.
Гэты артыкул не прызначана як поўную характарыстыку ўсіх моў праграмавання. Ёсць шмат іншых атрыбутаў моў праграмавання, акрамя сілы і набраўшы ўзроўні праграмавання, а таксама Ёсць шмат цікавых мовах, якія не могуць быць ахарактарызаваны як чыста мовы праграмавання сістэмы ці мовы сцэнараў. Напрыклад, сямейства Lisp моў ляжыць дзесьці паміж і сістэмнага праграмавання сцэнараў, з некаторымі з атрыбутаў кожнага з іх. Lisp упершыню такія паняцці, як тлумачэнне і дынамічная тыпізацыя, якія цяпер распаўсюджаны ў мовах сцэнараў, а таксама аўтаматычнае кіраванне захоўваннем дадзеных і інтэграваных асяроддзяў распрацоўкі, якія цяпер выкарыстоўваюцца ў абодвух сцэнараў і моў праграмавання сістэмы. Мовы сцэнараў уяўляюць розны набор кампрамісаў, чым мовы праграмавання сістэмы. Яны даюць да хуткасці выканання і сілы набраўшы ў адносінах да моў праграмавання сістэмы, але забяспечваюць значна больш высокую прадукцыйнасць праграміста і праграмнае забеспячэнне паўторнага выкарыстання. Гэты кампраміс робіць усё больш і больш сэнсу, як кампутары становяцца хутчэй і танней у параўнанні з праграмістамі. Мовы праграмавання сістэмы добра падыходзяць для будаўнічых кампанентаў, дзе складанасць у структур дадзеных і алгарытмаў, у той час скрыптовых моў добра падыходзіць для склейвання прыкладанняў, дзе складанасць у сувязі. Склейванне задачы становяцца ўсё больш і больш распаўсюджанай, так сцэнараў стане яшчэ важнейшым парадыгма праграмавання ў наступным стагоддзі, чым яна з'яўляецца сёння. Я спадзяюся, што гэты артыкул будзе ўздзеянне кампутарная супольнасць трыма спосабамі:
- Я спадзяюся, што праграмісты лічаць адрозненні паміж сцэнарамі і сістэмнага праграмавання пры запуску новых праектаў і абраць найболей магутную прыладу для кожнай задачы.
- Я спадзяюся, што распрацоўнікі кампанента рамак прызнаюць важнасць сцэнара
ING і забяспечыць, каб іх рамкі складаюцца з не толькі сродкі для стварэння кампанентаў
а таксама сродкі для склейвання іх разам. - Я спадзяюся, што даследаванне мовы праграмавання супольнасць будзе перакласці частку сваёй увагі на скрыптовых мовах і дапамагаюць развівацца яшчэ больш магутныя мовы сцэнараў на будучыню. Падвышэнне ўзроўня праграмавання павінна быць самая важная мэта для мовы дызайнераў, бо яна мае найвялікі ўплыў на прадукцыйнасць працы праграміста, гэта не відавочна, што строгая тыпізацыя спрыяе дасягненню гэтай мэты.
У гэтым артыкуле былі скарыстаны матэрыялы са шматлікіх людзей каментары, у тым ліку Джоэл Бартлетт, Біл Элдридж, Джэфры Haemer, Марк Харысан, Падлога McJones, Дэвід Паттерсон, Стывен Улер, Хэнк Уолкер, Крыс Райт, IEEE Computer суддзяў, і дзясяткі іншых, якія ўдзельнічалі ў награваецца-навіны абмеркавання сетка ранняга праекта артыкула. Колін Стывенс піша версія MFC на кнопку напрыклад, Стывен Улер піша версіі Java. [1] В. Бем, інжынерна-эканамічны Software, Prentice-Hall, ISBN 0-138-22122-7, 1 81. [2] С. Джонсан, пярэчачы супраць аб'ектаў, Запрошаны даклад, USENIX тэхнічнай канферэнцыі, Сан-Францыска, Каліфорнія, студзень 1 4 гады.
[3] С. Джонса, "Мовы праграмавання табліцы, выпуск 8.2", сакавік 1 6 гады, http://www.spr.com/library/0langtbl.htm.
[4] М. Лутц, праграмавання Python, O'Reilly, ISBN 1-565 2-1 7-6, 1 6.
[5] Netscape Inc, "JavaScript у Navigator 3.0", http://home.netscape.com/eng/mozilla/3.0/handbook/javascript/atlas.html#taint_dg.
[6] Р. О'Хара і Д. Гомберг, сучаснага праграмавання Выкарыстанне REXX, Prentice Hall, ISBN 0-13-5 732 -5, 1 88.
[7] Дж. Ousterhout, Дадатковая інфармацыя для сцэнараў Белай кнізе, http://home.pacbell.net/ouster/scriptextra.html.
[8] Дж. Ousterhout, Tcl і Tk Інструментар, Addison-Wesley, ISBN 0-201-63337-X, 1 4.
[ ] Л. сцены, Т. Кристиансен, Р. Шварц, праграмавання Perl, другое выданне, O'Reilly Associates і, ISBN 1-565 2-14 -6, 1 6.
Сонца і Java з'яўляюцца гандлёвымі маркамі ці зарэгістраванымі гандлёвымі маркамі Sun Microsystems, Inc у Злучаных Штатах і іншых краінах.
1 больш дакладную характарыстыку будзе выкарыстоўваць тэрмін "статычнай тыпізацыі", дзе я кажу "строгая тыпізацыя" і "дынамічная тыпізацыя з аўтаматычным канвертаваннем" на мовах сцэнараў, якія я апісваю, як слаба тыпізаваны ці нетыпізаваны. Я выкарыстоўваю тэрмін "каманду" ўвогуле сэнсе, каб апісаць ступень, у якой выкарыстанне дадзеных абмежавана загадзя.
