Чем скрипт отличается от программы

Чем различается скрипт и программа? Вовсе не используемым языком или наличием интерфейса.

Главная разница — в наличии у программы обширнейшей оболочки, не связанной «содержимым» программы. В зависимости от платформы, это могут быть страницы руководства, поддержка нескольких языков, наличие функционала по установке/удалению, исполнение соглашений об интерфейсе (командной строки, или иных средств взаимодействия), интерфейсы в общем реестре и т.д… Программа должна уметь работать в любой документированной среде, предусматривать различные ситуации (круче всего с этим у программ под unix, которые используют ./configure для определения, собственно, где они, что можно, а что нельзя на этой (очередной) платформе).

Скрипт же, в строго обратном смысле: он предназначен для решения конкретной проблемы «здесь и сейчас». Никто не ожидает от скрипта, который отсылает статистику, способности делать это одновременно на solaris’е, freeBSD и windows embedded standard с cygwin’ом на борту.

Значение слова скрипт. Что такое скрипт.

По математико-программистким представлениям, между скриптами администрирования и программами нет разницы. Они работают по одинаковым принципам, вообще говоря, выполняют почти одно и то же.

Разница между скриптом и программой — административная.

• Нетривиальный алгоритм.
• Техподдержку, наработанные лучшие практики использования, типовые схемы внедрения и готовые конфигурации.
• Правильную интеграцию в рабочую среду в любой разрешённой (документированной) конфигурации.

Давайте подробнее об этих составляющих…

1) Алгоритм. У любой программы есть во-первых некая идея (что, собственно, делает программа), во-вторых — обвязка. Чтение конфигов, вывод в сислог, оповещение по почте и ещё тысяча не связанных с основной задачей операций. Но программу используют не ради чтения конфигов и записи в лог, а ради того, что она ДЕЛАЕТ.

Соответственно, обычно идея заключается в выполнении каких-то действий по какому-то алгоритму. Нетривиальная идея. В фактическом коде это может быть меньше, чем чтение xml-конфига, но при этом именно рабочий алгоритм — суть программы.

Он может быть или «обрабатывающим данные» (вроде SQL’я), или математическим (вроде md5sum), или работающим с конкретными особенностями конкретной железки (формата файла) — но он всегда требует высокой квалификации в предметной области для адекватного понимания принципов работы. Понятно, что код OpenSSL может читать любой программист. Понятно, что алгоритм работы OpenSSL может понять только хороший математик.

Но мы пишем не о программах — о скриптах. Так вот, скрипт не должен реализовывать нетривиальные алгоритмы. Если вы у себя в скрипте пишите аналог base64 — это плохой скрипт. Если вы у себя в скрипте пишите отправку сообщений по smtp методом «открыли сокет, записали» — это омерзительный скрипт. Если вы у себя в скрипте ловите данные с ком-порта и пишите туда ответ (для управления УПСом) — это писец какой-то, а не скрипт.

Урок 4. Что такое скрипт?

Скрипт НЕ ДОЛЖЕН содержать в себе алгоритма в терминах «предметной области». У скрипта нет предметной области, скрипт — обвязка вокруг программ, которые уже работают с предметными областями. В некоторых случаях скриптовый язык может предоставлять весь инструментарий:

if md5.md5sum (open.($check).read() ) != url.openurl($control).read(): smtp.sendmail($from, $to, «data check failed», «md5sum of $check does not match control sum form $contol.»).

Это скрипт. Просто скрипт. Не смотря на то, что он реализует офигенный объём работы. А вот если у вас 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, мы и сами напишем пачку скриптов мониторинга), а изучение чужого — утомляет (ну хрена она работает не так как я ожидаю?). Но последствия «недопрограммирования» — отсутствие документации к тому «дымоходу», который вы сделали. А последствие внедрённого решения — система, которая умеет работать сама по себе.

• скрипты
• администрирование

Источник: habr.com

Разница между script и программой?

В чем разница между script и программой? Большую часть времени, когда я слышу, что работает script, это не программа? Я немного озадачен, кто-нибудь может это понять?

ОТВЕТЫ

Ответ 1

Для меня основное отличие состоит в том, что script интерпретируется, тогда как выполняется программа (т.е. исходный файл сначала компилируется, и результат этого ожидается компиляция).

Википедия, похоже, со мной согласна:

«Скрипты» отличаются от основного код приложения, который обычно написанные в другом языка и часто создаются или минимально измененный конечным пользователем. Скрипты часто интерпретируются из исходный код или байт-код, тогда как приложения, которые они контролируют, традиционно составляется на машинный код.

Программа имеет исполняемую форму что компьютер может использовать выполните инструкции.
Тот же программы в своем человеко-читаемом источнике код, из которого исполняемый файл программы производятся (например, скомпилированы)

Ответ 2

Я использую другое представление.

«script» — это код, который действует на какую-либо систему внешним или независимым образом и может быть удален или отключен без отключения самой системы.

«Программа» — это код, который представляет собой систему. Программный код может быть написан модульным способом с хорошим разделением проблем, но код в корне является внутренним и зависит от, самой системы.

Сценарии часто интерпретируются, но не всегда. Программы часто компилируются, но не всегда.

Ответ 3

A Script также является программой, но без непрозрачного слоя, скрывающего (исходный код), тогда как программа имеет одежду, вы не можете видеть ее исходным кодом, если она не декомпилируется.

Сценарии нуждаются в других программах, чтобы выполнять их, пока программы не нуждаются в них.

Ответ 4

Как правило, script представляет собой легкий, быстро построенный, возможно, одноразовый инструмент. Он обычно интерпретируется, а не компилируется. Python и bash являются примерами используемых языков для создания скриптов.

Программа построена на скомпилированном языке, например C или С++, и обычно работает быстрее, чем script по этой причине. Большие инструменты часто пишутся как «программы», а не скрипты — более мелкие инструменты легче разрабатываются как скрипты, но скрипты могут стать громоздкими по мере их увеличения. Языки приложений и системы (те, которые используются для создания программ/приложений) имеют инструменты, облегчающие управление этим процессом.

Обычно вы можете просмотреть script в текстовом редакторе, чтобы узнать, что он делает. Вы не можете сделать это с помощью исполняемой программы — последние инструкции были скомпилированы в байт-код или машинный язык, что делает его очень трудным для понимания людьми без специальных инструментов.

Обратите внимание на количество «фортов» и «обычно» выше — термины туманны и иногда пересекаются.

Ответ 5

«Программа» в целом, последовательность инструкций, написанных так, что компьютер может выполнить определенную задачу.

A «script» — это код, написанный на языке сценариев. Язык сценариев — это не что иное, как тип языка программирования, в котором мы можем писать код для управления другим программным приложением.

Фактически языки программирования имеют два типа:

а. Язык сценариев

б. Скомпилированный язык

Ответ 6

Сценарии обычно интерпретируются (другим исполняемым файлом).

Обычно программа представляет собой самостоятельный скомпилированный исполняемый файл (хотя он может иметь зависимости от библиотеки), состоящий из машинного кода или байтовых кодов (для компилируемых программ «точно в момент времени» )

Ответ 7

Согласно моей перспективе, основное различие между script и программой:

Сценарии могут использоваться с другими технологиями. Пример: скрипты PHP, Javascripts и т.д. Могут использоваться в HTML.

Программы представляют собой автономные фрагменты кода, которые никогда не могут быть встроены в другие технологии.

Если я ошибаюсь в любом месте, пожалуйста, исправьте меня. Я буду восхищаться вашей коррекцией.

Ответ 8

В сценарии и реальности программы существуют два аспекта:

• Является ли язык достаточно мощным, особенно со строковыми операциями, конкурировать с макропроцессором, таким как оболочка posix, и особенно bash? Если это не лучше, чем bash для запуска некоторой функции, ее использование не так много.
• Является ли язык удобным и быстро начатым? Java, Scala, JRuby, Closure и Groovy — все мощные языки, но для Java требуется много шаблонов, а для JVM, которые все они требуют, требуется слишком много времени для запуска.

OTOH, Perl, Python и Ruby все быстро запускаются и имеют мощные операции обработки строк (и в значительной степени все-остальные-операции), поэтому они имеют тенденцию занимают порой «унизительный», но не-легко-посягающий «мир сценариев». Оказывается, они хорошо справляются с запуском целых традиционных программ.

Слева в limbo — такие языки, как Javascript, которые не используются для сценариев, но потенциально могут быть. Обновление: поскольку это было написано node.js, было выпущено на нескольких платформах. В других новостях вопрос был закрыт. «О, хорошо».

Ответ 9

Структура или другая аналогичная схема будет запускать/интерпретировать script для выполнения задачи. Программа компилируется и запускается машиной для выполнения задачи

Ответ 10

ММО Script — это вид инструкции, которую должна выполнять программа Программа — это вид инструкции, которую должно было выполнять аппаратное обеспечение

Хотя я думаю, что байты .NET/JAVA являются скриптами по этому определению

Ответ 11

script: он содержит набор команд «скриптовый язык», которые управляют, запускают другие системные программы, приложения также могут быть запланированы.

Программа: содержит набор инструкций, выполняющих определенную задачу при компиляции программы с компилятором.

Источник: utyatnishna.ru

Скрипт

Скрипт (англ. script) — сценарий работы программы, написанный на высокоуровневом языке программирования.

Отличие скрипта от обычной программы в том, что он является интерпретируемым (не требует компиляции перед началом работы) и использует уже готовые части программ, управляя ими по определённому сценарию.

Скрипты часто используются в Интернет-технологиях, где нужна кроссплатформенность, то есть, работа сценария на устройствах с разной архитектурой. К примеру, виджет на сайте, написанный на языке JavaScript будет одинаково работать и на Windows и на Android и на iOS.

Также скрипты выгодны тем, что работа с ними намного проще, чем создание полноценных программ на низкоуровневых языках программирования. Поэтому для их написания не нужны высококвалифицированные программисты и можно значительно сэкономить бюджет на разработку программных продуктов.

Источник: www.bestfree.ru