Это скрипт или программа? Как их отличать и зачем
Немного матчасти для тех, кто хочет глубже понимать программирование
⚠️ Минутка матчасти! Эта статья создана для расширения кругозора и повышения разрешения в мире компьютерных технологий. В ней мало практической пользы кроме развития вашего интеллекта.
Здесь мы говорим о двух типах компьютерных языков: условно говоря, языков скриптования (интерпретируемые языки) и языков программирования (компилируемые языки). Это деление — не самое верное и не самое полное с точки зрения опытных программистов, но статья рассчитана на тех, кто только начинает.
Скриптовые, или интерпретируемые, языки
Обычно примеры кода в наших статьях работают по такому принципу:
Браузер берёт наш код, проверяет его на ошибки и, если ошибок нет, — выполняет команды по очереди в нужной последовательности. Или даже выполняет без проверки, а если в процессе появится ошибка — остановится.
Чтобы такие скрипты работали, нужна какая-то программа, которая будет выполнять команды скрипта, — их называют интерпретаторами. В нашем случае это браузер: Chrome, Safari, Firefox, Яндекс-браузер и т. д. Отсюда и название — интерпретируемые языки.
Пример скриптового языка, который вы уже знаете, — JavaScript. На скриншоте ниже он вписан внутрь веб-страницы. Сам код из одной строки прописан между тегами : браузер будет рисовать страницу, в какой-то момент увидит этот скрипт, выполнит его и пойдёт дальше рисовать страницу.
Ещё один популярный пример интерпретируемого языка — Python. Он работает по тому же принципу, только вместо браузера Python использует собственный интерпретатор команд. Когда мы в среде разработки запускаем скрипт на питоне, то интерпретатор шаг за шагом выполняет команды.
👉 В интерпретируемых языках сам скрипт — это и есть готовая программа, но для её запуска и работы нужен внешний интерпретатор, который выполнит команды. Без интерпретатора скрипт не запустится.
Программные, или компилируемые, языки и машинный код
Другой подход к разработке: программные, или компилируемые, языки. Они устроены так: программист пишет исходный код программы, а потом прогоняет её через компилятор. Компилятор берёт исходный код целиком, анализирует его и создаёт машинный код.
Компиляция — это превращение программного кода в исполняемый код для процессора: на входе было то, что могли прочитать вы, а на выходе — то, что может прочитать и исполнить компьютер. Если скрипт — это сценарий для актёра на сцене, то компиляция — это отснятый фильм на киноленте.
Машинный код — последовательность байтов, которая даёт инструкции напрямую процессору. Для человека такой код выглядит как просто набор знаков, но компьютер его понимает.
Чтобы вы понимали, чем исходный код отличается от машинного, держите пример. Вот исходный код на Swift, который выводит сообщение «Hello, world»:
А вот так выглядит фрагмент машинного кода, который получился после работы компилятора:
Как так получилось: компьютер взял исходный код из двух строк и преобразовал его в набор символов на несколько тысяч строк. Размер машинного кода вырос за счёт того, что компилятор добавил в него много нужных и обязательных функций: научил выводить сообщения на экран, рассказал, как обращаться к памяти и что делать после запуска. Кода стало больше, зато теперь он работает без посторонней помощи.
Примеры компилируемых языков: С, С++, Pascal, Swift и ещё десятки других. Ассемблер, кстати, тоже компилируемый язык — процессор не умеет понимать его исходный код без посторонней помощи.
👉 Результат работы компилятора — самостоятельная программа в виде машинного кода, которая потом может работать сама, без компилятора. Один раз скомпилировал — и потом можно запускать её самостоятельно, без внешних программ.
Особенности компилируемых языков
У машинного кода есть один недостаток: он работает только с определёнными процессорами и компьютерами. Если программа написана для Виндоус, запустить на макбуке без специальных ухищрений не получится. Программа для телефона на компьютере заработает только при особых условиях — например, поддержка приложений Android появилась только в Windows 11, а приложения iOS научили запускаться на MacOS только в 2020 году.
Дело в том, что у разных компьютеров разный тип процессора, а машинный код знает, как работать только со своим типом. Чтобы запустить приложение iOS на Mac OS, операционка должна «обернуть» приложение в эмулятор мобильного устройства, и только потом — запустить.
Снова про снобизм
Некоторые любители программных языков считают скриптовиков ненастоящими программистами. Мол, они пишут программы, которые сами по себе не работают и которым нужен интерпретатор. Если вы такое слышите, то знайте, что перед вами — программист-сноб.
Настоящие разработчики знают, что главное — решить задачу. Если она скриптом решается лучше, чем машинным кодом, значит, в этой ситуации лучше сработает скрипт, и наоборот.
Теория правильных скриптов
Чем различается скрипт и программа? Вовсе не используемым языком или наличием интерфейса.
Скрипт же, в строго обратном смысле: он предназначен для решения конкретной проблемы «здесь и сейчас». Никто не ожидает от скрипта, который отсылает статистику, способности делать это одновременно на solaris’е, freeBSD и windows embedded standard с cygwin’ом на борту.
По математико-программистким представлениям, между скриптами администрирования и программами нет разницы. Они работают по одинаковым принципам, вообще говоря, выполняют почти одно и то же.
Разница между скриптом и программой — административная.
Давайте подробнее об этих составляющих…
1) Алгоритм. У любой программы есть во-первых некая идея (что, собственно, делает программа), во-вторых — обвязка. Чтение конфигов, вывод в сислог, оповещение по почте и ещё тысяча не связанных с основной задачей операций. Но программу используют не ради чтения конфигов и записи в лог, а ради того, что она ДЕЛАЕТ. Соответственно, обычно идея заключается в выполнении каких-то действий по какому-то алгоритму. Нетривиальная идея. В фактическом коде это может быть меньше, чем чтение xml-конфига, но при этом именно рабочий алгоритм — суть программы. Он может быть или «обрабатывающим данные» (вроде SQL’я), или математическим (вроде md5sum), или работающим с конкретными особенностями конкретной железки (формата файла) — но он всегда требует высокой квалификации в предметной области для адекватного понимания принципов работы. Понятно, что код OpenSSL может читать любой программист. Понятно, что алгоритм работы OpenSSL может понять только хороший математик.
Но мы пишем не о программах — о скриптах. Так вот, скрипт не должен реализовывать нетривиальные алгоритмы. Если вы у себя в скрипте пишите аналог base64 — это плохой скрипт. Если вы у себя в скрипте пишите отправку сообщений по smtp методом «открыли сокет, записали» — это омерзительный скрипт. Если вы у себя в скрипте ловите данные с ком-порта и пишите туда ответ (для управления УПСом) — это писец какой-то, а не скрипт.
Скрипт НЕ ДОЛЖЕН содержать в себе алгоритма в терминах «предметной области». У скрипта нет предметной области, скрипт — обвязка вокруг программ, которые уже работают с предметными областями. В некоторых случаях скриптовый язык может предоставлять весь инструментарий:
Это скрипт. Просто скрипт. Не смотря на то, что он реализует офигенный объём работы. А вот если у вас md5 — класс, объявленный в скрипте 5 строчками выше с имплементацией md5 (или url, или open, или smtp, etc) — это уже потуга на программу. Но программа — это много сложнее, чем алгоритм, её составляющий — и подобное не должно реализовываться в скриптах. НИКОГДА.
2) Любая программа должна обладать известным поведением. Математики предлагают описывать поведение программы в всеобъемлющих терминах; практика же говорит, что обычно кроме алгоритма программа ещё содержит баги и фичи, которые влияют на её поведение, к которым надо адаптироваться. Адаптироваться к ним куда проще, когда есть некоторая практика использования программы.
«KDC has been valid once but invalid now» — если это сообщение от скрипта — всё, хоронить. Прямо тут, на месте. У программы это вполне разумное сообщение по которому можно гуглить и выяснять, что именно не так. Это прямое следствие наличия в программе некой предметной логики, специфичной и требующей от пользователей не изучать её насквозь, а принять бехивиористически. То бишь как набор утверждений о поведении программы. «Данная версия программы не понимает файлы больше 2Гб в размере». Это не укладывается в алгоритм (а если уложится — будет занимать этак с том дискретной математики) — но это нужно знать в практическом смысле. «Данная программа плохо себя ведёт в условиях симметричной нагрузки на аплоад/даунлоад, лучше запустить две копии, каждая из которых будет работать в свою сторону симметрично» — понимание _ПОЧЕМУ_ потребует титанических усилий, проще принять это как данность. Чем сложнее алгоритм, тем больше жизни нужно потратить на его исследование, адаптацию и глубокое изучение. На всё жизни не хватит, значит, проще принять как данное и сконцентрироваться на важном.
Скрипт же, обратно, должен быть кристально понятен каждому, кто его посмотрит (с поправками на знание скриптового языка). Никаких (if every in self.__datarange__ is not in any map(__systable__.lang, __localtable__.map, lambda (a,b):[a in b or b in a for every __sys__.pair(a,b)])) raise «Missed i18n constitution».
3) Скрипт решает задачу _ЗДЕСЬ_И_СЕЙЧАС_. Программа решает задачу _ТАМ_И_ВСЕГДА_ (с поправкой на опыт эксплуатации из п.2). Когда вы пишите скрипт, вы делаете так, чтобы оно работало в вашей системе. Оно не годится для свободного использования в других системах (хотя может быть ЛЕГКО (см п.1) адаптировано). Программа должна быть адаптируема к куче вариантов применения, реализация этой адаптации в скрипте приводит к потере его простоты и превращению его, собственно, в программу. Кроме того (увы и ах), но знание КАК ПРАВИЛЬНО писать программу не эквивалентно написанию правильного алгоритма. Вы можете написать потрясающую библиотеку, но если вы не сможете запустить её на машине, у которой понедельник первый день недели (или второй — кому как повезёт), то грош цена вашей библиотеке. Необходимость думать об этом — это уже написание программ — скрипту такое допустимо (хотя и не желательно).
Ну и ещё важное отличие между скриптами и программами. Программы (в форме библиотек) могут «наслаиваться» друг на друга. Этой программе нужен libYYY, которая использует libZZZ и libAAA, при этом libAAA использует libZZZ и libc. Это нормально.
Скрипты же НЕ ДОЛЖНЫ ЗАВИСЕТЬ ДРУГ ОТ ДРУГА. Ситуация, когда скрипт зависит от сервисов другого скрипта, который зависит от третьего — ненормальная.
Заметим, речь идёт о зависимости. Вполне можно представить себе скрипт, который вызывает другие скрипты и выдаёт обобщённый результат по ним, но это уже грань. Чуть сложнее (например, «запустить скрипт А если скрипт Б не отработал») — уже за гранью фола. Нехорошо. А если скрипт А не отработал но не сообщил об этом? Или чуть-чуть отработал, но потом отвалился так, что скрипту Б не получится доделать (а мы, как авторы скрипта А, и подумать не могли о подобном)?
Что же вообще должен делать хороший скрипт? Сращивать несколько программ в конкретную систему. Можете считать программы за детали конструктора. А сам конструктор — за скрипт. Вам НЕ СЛЕДУЕТ нарезать винтовую нарезку на шпинделе — возьмите шпиндель с нарезкой. Вам не следует делать эллиптический валик из этой резинки — оно всё равно будет плохо работать. Если у вас в конструкторе нет квадратной пластинки с дырками по краям, то это проблема нехватки деталек. Вы можете попытаться сделать квадратную пластину из пары прямоугольных, но не следует делать её и сотни длинных полосок.
Бывает так, что скрипты перерождаются в программы. Внезапно в скрипте появляется некая логика (алгоритм), которая становится нетривиальна (и полезна). В этот момент нужно поймать это — и не полениться потратить в три раза больше времени, но сделать её программой. Обеспечить её «мясом», которое отличает программу от скрипта. Добавить сотню проверок условий, заменить все константы на конфигурируемые переменные, приготовить её для работы в «непривычных» условиях. Желательно сделать её публичной (тогда может наработаться практика использования).
Обычный пайп представляет из себя практически идеальный инструмент для конструирования простых программ:
Грань, в которой заканчивается скрипт найти сложно. Скажем так, цикл — ещё терпимо. Проверка условия — нормально. Но вот проверка условия в цикле (больше, чем выход из цикла) — это уже плохо. Если же у вас цикл, в котором по проверке условия запускается цикл — это 100% программа. Если у неё нет всего того, что должно быть у программы, значит это просто очень плохая программа. Но никак не скрипт.
Когда я смотрю на сборники «полезных скриптов» (вот тут (forum.sysadmins.ru), например), я понимаю, что это программы. Ужасные программы без сопроводительной документации, процедуры установки, без проверки условий… Так нельзя.
Применение подобных скриптов — признак крайней куцести рабочей среды. Я одно время пробовал с ними ужиться, но пришёл к выводу, что это ошибка. Куда правильнее иметь набор тулкитов (т.е. полноценных программ, реализующих конкретные вещи полностью и хорошо), чем набор аналогичных скриптов (повторю ещё раз — программа может быть написана на том же скриптовом языке — разница между скриптом и программой в непрограммерской обвязке: документации и приспособленности к жизни в широком спектре систем).
Применение копипастнутых скриптов — подобие ранне-досового копирования на дискетках полезных программулин. Работает — радуемся, не работает — пофигу, сломало всё — злимся. В условиях выбора между копипастнутым скриптом и программой (и минимальной обвязкой) следует выбирать программы. Даже если внедрение программы потребует дополнительных усилий по изучению, налаживанию и т.д. Наладив программу, вы получите программу. Отладив скрипт вы получите лишь костыль, прочность и долговечностью которого не знает даже автор.
Каждый раз, когда возникает подобная ситуация: делать скрипт или искать программу, следует начать с поиска программы. Потому что программирование увлекает (да нафига нам nagios, мы и сами напишем пачку скриптов мониторинга), а изучение чужого — утомляет (ну хрена она работает не так как я ожидаю?). Но последствия «недопрограммирования» — отсутствие документации к тому «дымоходу», который вы сделали. А последствие внедрённого решения — система, которая умеет работать сама по себе.
Разница между script и программой?
В чем разница между script и программой? Большую часть времени, когда я слышу, что работает script, это не программа? Я немного озадачен, кто-нибудь может это понять?
ОТВЕТЫ
Ответ 1
Для меня основное отличие состоит в том, что script интерпретируется, тогда как выполняется программа (т.е. исходный файл сначала компилируется, и результат этого ожидается компиляция).
Википедия, похоже, со мной согласна:
«Скрипты» отличаются от основного код приложения, который обычно написанные в другом языка и часто создаются или минимально измененный конечным пользователем. Скрипты часто интерпретируются из исходный код или байт-код, тогда как приложения, которые они контролируют, традиционно составляется на машинный код.
Программа имеет исполняемую форму что компьютер может использовать выполните инструкции.
Тот же программы в своем человеко-читаемом источнике код, из которого исполняемый файл программы производятся (например, скомпилированы)
Ответ 2
Я использую другое представление.
Сценарии часто интерпретируются, но не всегда. Программы часто компилируются, но не всегда.
Ответ 3
A Script также является программой, но без непрозрачного слоя, скрывающего (исходный код), тогда как программа имеет одежду, вы не можете видеть ее исходным кодом, если она не декомпилируется.
Сценарии нуждаются в других программах, чтобы выполнять их, пока программы не нуждаются в них.
Ответ 4
Как правило, script представляет собой легкий, быстро построенный, возможно, одноразовый инструмент. Он обычно интерпретируется, а не компилируется. Python и bash являются примерами используемых языков для создания скриптов.
Ответ 5
«Программа» в целом, последовательность инструкций, написанных так, что компьютер может выполнить определенную задачу.
Фактически языки программирования имеют два типа:
б. Скомпилированный язык
Ответ 6
Сценарии обычно интерпретируются (другим исполняемым файлом).
Обычно программа представляет собой самостоятельный скомпилированный исполняемый файл (хотя он может иметь зависимости от библиотеки), состоящий из машинного кода или байтовых кодов (для компилируемых программ «точно в момент времени» )
Ответ 7
Согласно моей перспективе, основное различие между script и программой:
Сценарии могут использоваться с другими технологиями. Пример: скрипты PHP, Javascripts и т.д. Могут использоваться в HTML.
Программы представляют собой автономные фрагменты кода, которые никогда не могут быть встроены в другие технологии.
Если я ошибаюсь в любом месте, пожалуйста, исправьте меня. Я буду восхищаться вашей коррекцией.
Ответ 8
В сценарии и реальности программы существуют два аспекта:
Является ли язык достаточно мощным, особенно со строковыми операциями, конкурировать с макропроцессором, таким как оболочка posix, и особенно bash? Если это не лучше, чем bash для запуска некоторой функции, ее использование не так много.
OTOH, Perl, Python и Ruby все быстро запускаются и имеют мощные операции обработки строк (и в значительной степени все-остальные-операции), поэтому они имеют тенденцию занимают порой «унизительный», но не-легко-посягающий «мир сценариев». Оказывается, они хорошо справляются с запуском целых традиционных программ.
Ответ 9
Структура или другая аналогичная схема будет запускать/интерпретировать script для выполнения задачи. Программа компилируется и запускается машиной для выполнения задачи
Ответ 10
Ответ 11
script: он содержит набор команд «скриптовый язык», которые управляют, запускают другие системные программы, приложения также могут быть запланированы.
Программа: содержит набор инструкций, выполняющих определенную задачу при компиляции программы с компилятором.
Какая разница между «script» и «приложением»?
Я имею в виду различия, такие как этот ответ:
Как программист, который работал на многих языках, это, по-видимому, C, Java и другой скомпилированный язык. Я не ищу улучшения моего мнения или ручных волнистых ответов. Скорее, я искренне хочу знать, о каких технических различиях.
(И я использую C в своей дневной работе, поэтому я не просто защищаюсь.)
Традиционно программа компилируется и интерпретируется script, но это уже не так важно. Вы можете сгенерировать скомпилированную версию большинства сценариев, если вы действительно этого хотите, и другие “скомпилированные” языки, такие как Java, фактически интерпретируются (на уровне байтового кода.)
Более современное определение может заключаться в том, что программа предназначена для использования клиентом (возможно, для внутреннего) и, следовательно, должна включать документацию и поддержку, а script предназначена в первую очередь для использования автором.
Интернет – интересный пример встречного. Нам всем нравится искать вещи в поисковой системе Google. Основная часть кода, который идет на создание “базы данных”, ссылается на него только его авторами и сопровождающими. Это делает его script?
Я бы сказал, что приложение, как правило, используется в интерактивном режиме, где script будет работать, подходит для пакетной работы. Я не думаю, что это конкретное различие.
Обычно это “script” по сравнению с “программой”.
Я с вами, что это различие в основном “скомпилированное языковое снобизм” или процитировать Ларри Уолла и взять другую сторону забора, “a script – это то, что есть у актеров, программа предоставляется аудитории”.
Джон Оустерхаут (изобретатель TCL) имеет хорошую статью в http://www.tcl.tk/doc/scripting.html, где он предлагает различие между языками системного программирования (для реализация строительных блоков, акцент на правильность, безопасность типов) и языки сценариев (для объединения строительных блоков, акцент на реагирование на изменяющиеся среды и требования, легкое преобразование в текстовые представления и из них). Если вы идете с этой системой категоризации, то 99% программистов выполняют задания, которые более подходят для языков сценариев, чем для языков системного программирования.
Это интересная тема, и я не думаю, что есть очень хорошие рекомендации по дифференциации “script” и “приложения”.
Давайте взглянем на некоторые статьи в Википедии, чтобы получить представление о различии.
Script (Википедия → Язык сценариев):
Язык сценариев, язык script или язык добавочного языка, является языком программирования, который управляет программным приложением. “Сценарии” часто рассматриваются как отличные от “программ”, которые выполняются независимо от любого другого приложения. В то же время они отличаются от основного кода приложения, которое обычно написано на другом языке, и, будучи доступным для конечного пользователя, они позволяют адаптировать поведение приложения к потребностям пользователя.
Application (Википедия → Прикладное программное обеспечение → Терминология)
В информатике приложение представляет собой компьютерную программу, предназначенную для того, чтобы помочь людям выполнять определенный тип работы. Таким образом, приложение отличается от операционной системы (которая запускает компьютер), утилиты (выполняющей операции обслуживания или общего назначения) и языка программирования (с помощью которого создаются компьютерные программы). В зависимости от работы, для которой она была разработана, приложение может манипулировать текстом, цифрами, графикой или комбинацией этих элементов.
Чтение вышеуказанных записей, по-видимому, предполагает, что различие заключается в том, что script “размещается” другим программным обеспечением, а приложение – нет. Я полагаю, что это можно утверждать, например, сценарии оболочки, контролирующие поведение оболочки, и perl-скрипты, управляющие поведением интерпретатора для выполнения желаемых операций. (Я чувствую, что это может быть немного растянуто, поэтому я не могу полностью согласиться с ним.)
Когда дело доходит до этого, я считаю, что разговорное различие может быть сделано с точки зрения шкалы программы. Скрипты обычно меньше по сравнению с приложениями.
Кроме того, с точки зрения цели, script обычно выполняет задачи, которые необходимо выполнить, скажем, например, скрипты сборки, которые создают несколько версий выпуска для определенного программного обеспечения. С другой стороны, приложения ориентированы на обеспечение функциональности, которая более совершенна и ориентирована на конечного пользователя. Например, Блокнот или Firefox.
A script имеет тенденцию быть серией команд, которые запускаются, запускаются и завершаются. Это часто не требует никакого человеческого взаимодействия. Приложение является “программой”… оно часто требует взаимодействия с человеком, оно, как правило, больше.
Script для меня подразумевается поэтапная интерпретация кода. Вы можете открыть script и просмотреть его читаемое программистом содержимое. Приложение подразумевает автономный скомпилированный исполняемый файл.
A script обычно работает как часть большего приложения внутри механизма сценариев
например. JavaScript → Браузер
Это противоречит традиционным статическим типизированным скомпилированным языкам и динамическим языкам, где код предназначен для формирования основной части приложения.
Это часто просто семантический аргумент или даже способ очернения некоторых языков программирования. Насколько мне известно, “script” – это тип программы, и точное определение несколько неопределенно и зависит от контекста.
Я мог бы использовать термин “script” для обозначения программы, которая в первую очередь выполняется линейно, а не с множеством последовательных логических или подпрограмм, подобно “script” в Голливуде, представляет собой линейную последовательность инструкций для актер для исполнения. Я мог бы использовать его для обозначения программы, написанной на языке, встроенном в большую программу, с целью запуска этой программы. Например, автоматизация задач под старой Mac OS с помощью AppleScript или управление программой, которая каким-то образом раскрывается со встроенным интерфейсом TCL.
Но во всех этих случаях a script является типом программы.
Термин “язык сценариев” используется для динамически интерпретируемых (иногда скомпилированных) языков, обычно у них есть много общих функций, таких как инструкции на высоком уровне, встроенные хэши и списки произвольной длины и другие структуры данных высокого уровня и т.д. Но эти языки способны к очень крупным, сложным, модульным, хорошо продуманным программам, поэтому, если вы думаете о “script” как о чем-то отличном от программы, этот термин может вас смутить.
Приложение представляет собой набор скриптов, направленных на общий набор проблем.
A script – это немного кода для выполнения одной довольно конкретной задачи.
ИМО, разница не имеет ничего общего с используемым языком. Можно написать сложное приложение с bash, и можно написать простой script с С++.
Прежде всего, я хотел бы подчеркнуть, что a script – это программа. Другими словами, script представляет собой набор инструкций.
Программа:
Набор команд, которые собираются компилироваться, называется программой.
Script:
Набор инструкций, который будет интерпретироваться, известен как Script.
Взяв perl в качестве примера, вы можете писать perl-скрипты или perl-приложения.
A script будет означать один файл или одно пространство имен. (например, updateFile.pl).
Приложение является большим и будет использоваться много раз и может быть продано клиенту.
A script начинается с малого, остается маленьким, если вам повезет, редко продается клиенту и может либо запускаться автоматически, либо выходить из употребления.
Script:
A script – это текстовый файл (или набор текстовых файлов) программных операторов, написанных на языке, который позволяет записывать на нем отдельные написанные на нем операторы для машинного исполняемого > code непосредственно перед выполняется каждый и с целью этого.
Применение:
приложение – это любая компьютерная программа, основная функция которой заключается в предоставлении услуги персоналу-человеку.
Программа на основе script, написанная на языке сценариев, может, теоретически, изменять свои текстовые выражения при выполнении script (конечно, с большим риском). Аналогичная ситуация для скомпилированных программ заключается в переводе бит в память.
Лично я считаю, что разделение – это шаг назад от фактической реализации.
По моей оценке, приложение планируется. Он имеет несколько целей, он имеет несколько результатов. Есть задачи, отложенные во время разработки до кодирования, которое приложение должно выполнить.
A script, однако, просто сбрасывается вместе, как подходит, и мало планирования.
Отсутствие надлежащего планирования не переносит вас на script. Возможно, это делает ваше приложение плохо организованной коллекцией плохо спланированных скриптов.
Кроме того, приложение может содержать сценарии, которые агрегированы, содержат целое. Но script может ссылаться только на приложение.
@Jeff – это хорошо. Мое любимое объяснение
Многие (большинство?) языков сценариев интерпретируются, а некоторые скомпилированные языки считаются скриптовыми языками, но вопрос скомпилированных против интерпретируемых только слабо связано с вопросом “сценариев” и “серьезных” языков.
Большая проблема заключается в том, что “скриптинг” довольно расплывчатый обозначение – это язык, удобный для написания скриптов, в отличие от написания “полномасштабных программ” (или Приложения). Но как отличить сложный script от простое приложение? Это по существу неоспоримый вопрос. Как правило, script представляет собой ряд команд, применяемых к некоторому набору данных, возможно, в пользовательском порядке… но тогда можно было бы растянуть это описание применимо к Photoshop, которое, несомненно, является основным выражение. Скрипты обычно меньше, чем приложения, do некоторые четко определенные вещи и “проще” использовать, и, как правило, могут разложить на четкую серию подопераций, но все эти вещи субъективны.
Я думаю, что вообще неважно, компилируется или интерпретируется код.
Истинное различие заключается в основной логике кода:
Если код создает новые функции, которые не реализованы в других программах в системе – это программа. Его даже можно манипулировать с помощью script.
Если код ОСНОВНО манипулирует действиями других программ, а итоговым результатом является ОСНОВНО результаты работы управляемых программ – это script. Буквально script действий для некоторых программ.
На самом деле разница между script (или языком сценариев) и приложением заключается в том, что script не требует компиляции в машинный язык.. Вы запускаете источник script с помощью интерпретатор. Приложение компилирует исходный код в машинный код, чтобы вы могли запускать его как отдельное приложение.
Я бы сказал, что script обычно представляет собой набор команд или команд, написанных простым текстом, которые выполняются хостинговым приложением (браузер, командный интерпретатор или оболочка,…).
Это не значит, что он не был бы мощным или не скомпилирован каким-то образом, когда он фактически выполнен. Но script не может ничего сделать сам по себе, это просто текст.
По своей природе это может быть только фрагмент, который необходимо объединить для создания программы или приложения, но расширенные и полностью разработанные сценарии или набор сценариев можно считать программами или приложениями при их запуске хостом, как и куча исходных файлов может стать приложением после компиляции.
Язык сценариев не имеет стандартной библиотеки или платформы (или не много). Он маленький и легкий, предназначенный для встраивания в более крупное приложение. Bash и Javascript – отличные примеры языков сценариев, потому что они полностью полагаются на другие программы для своей функциональности.
Используя это определение, script – это код, предназначенный для управления большим приложением (пакетом). Javascript может вызвать Firefox, чтобы открыть окна или манипулировать DOM. A Bash script выполняет существующие программы или другие скрипты и соединяет их вместе с каналами.
Вы также спрашиваете, почему не скриптовые языки, поэтому:
Существуют ли какие-либо инструменты для тестирования модулей для скриптовых языков? Это кажется очень важным инструментом для “реальных” приложений, которые полностью отсутствуют. И редко какие-либо реальные привязки библиотек для языков сценариев.
В большинстве случаев скрипты могут быть заменены реальным, легким языком, например Python или Ruby.