Может ли статически скомпилированные языки заменять язык сценариев?

Question

Предполагая, что вы можете получить динамический интерпретатор; может ли статически скомпилированные языки заменять язык сценариев? Я никогда не понимал why anyone would use a scripting language? Я говорю о ПК, а не о ограниченной системе, которая нуждается в упрощенном интерпретаторе. Я видел некоторые скрипты для установки python и видел подобные проблемы с python и C#. Итак, зачем использовать скриптовый язык?

ПРИМЕЧАНИЕ: Есть вещи, которые беспокоят меня о C#, я не спрашиваю, почему бы не использовать C# вместо этого. Я спрашиваю, зачем использовать скриптовый язык? Я считаю, что статические скомпилированные языки намного проще отлаживать и часто проще кодировать.

Answer 1

Wikipedia говорит, что язык сценариев - это язык, который управляет другим программным обеспечением. Вы можете сделать это с помощью C#, но для этого разработаны именно такие языки сценариев, как Powershell.

Я склонен думать о языке сценариев в более «интерактивных» терминах, чем C#. С помощью языка сценариев вы можете написать строку или два кода, выполнить его и сразу увидеть результаты. Это не так просто на C#, где вам нужно поместить свой код в консольное приложение или отключить его от единичного теста или ввести его в окно Immediate, где у вас нет intellisense.

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

Answer 2

Этот вопрос часто начинает пламенные войны, так как люди страстно относятся к своим лагерям.

В компьютерные устаревшие инструменты командной строки Unix и консольные оболочки предоставили богатую среду сценариев, где можно было выполнить всевозможные обработки. Вам не нужно было быть экспертом-программистом на каком-либо конкретном языке и могли бы использовать различные программы (другие, написанные людьми), используя структуру труб, чтобы массировать ваши данные, которые в основном связаны не с бинарными текстами. Быстро и легко вносить изменения в ваш командный файл. У вас нет исходного файла, который нужно отредактировать, скомпилированного с использованием внешних статических или общих libries/DLLS в случае Windows.

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

Откиньте назад к настоящему, и воды станут мутными. Некоторые среды сценариев предлагают своего рода ускоренное средство, где они будут читать ваш скрипт и почти компилировать и связывать в модулях то же, что и обычные программы на C++ или VB, которые могут использоваться для купирования скорости. Но это очень плохо, и на него нельзя положиться.

Итак, как вы выбираете, какой маршрут идти. Начать выполнение задач с помощью скриптов. Если он работает слишком медленно или вам нужно делать вещи каждые 5 минут, то части вашего скрипта могут быть полезны из раздела, написанного на традиционном языке, или все это может быть написано на языке.

Как и все балуются и узнать

Answer 3

Каждый используются для различных целей. Программы, написанные на языках сценариев, часто не являются самодостаточными; они часто функционируют как «код клея» или (как упоминает Роберт Харви) для автоматизации задачи. Вы часто находите интерпретаторы языка сценариев, встроенные в приложение (cf Python в Blender, Guile, Perl и Python в GIMP, JS - в разных браузерах, Lua - в бесчисленных играх). Скомпилированные языки, с другой стороны, используются для создания автономных приложений. Скрипты в основном кросс-платформенные; скомпилированных приложений обычно нет.

Обратите внимание, что язык сценариев не обязательно использует интерактивный интерпретатор (например, Perl), а интерпретируемый язык не обязательно используется для скриптов (например, игр, выполненных с использованием PyGame). Обратите также внимание на то, что в самих языках нет ничего, что могло бы интерпретировать или компилировать их. У вас может быть C# interpreter или Ruby compiler. Было несколько систем Lisp, которые предлагали как интерпретаторы, так и компиляторы.

Answer 4

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

Answer 5

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

Единственная разница в деталях набора команд, особенно в системе типов. Языки сценариев обычно (но не всегда) динамически типизируются. Но многие большие приложения также написаны на языках с динамически типизированным языком. Итак, здесь нет четкого различия.

Лично я считаю, что статическая типизация, не являющаяся «лишним ненужным усилием» (как это часто описывается), на самом деле является огромным ускорителем производительности, что делает намного проще писать короткие фрагменты правильно с первой попытки, благодаря intellisense/автодополнение. Чтобы подчеркнуть это, посмотрите, как Microsoft улучшила библиотеку jQuery, просто добавив к ней информацию статического типа (в специально форматированных комментариях), чтобы мы могли иметь intellisense в среде IDE.

А между тем статические языки (включая C# и Java) привносят более динамичные функции ввода.

Таким образом, я вижу эти категории в конечном итоге, и их различие не имеет смысла.

Answer 6

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

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

1. Многие пользователи языка сценариев ненавидят статических языков. Они чувствуют себя ограниченными. Языки сценариев, как правило, очень хороши в том, что они не попадают на пути пользователей, которые жертвуются статическими языками для скорости/правильности.

2. Утиная печать не будет отображаться на статических языках.

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

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

Который не должен сказать, что до сих пор, чтобы быть спроектированный язык не может обрабатывать особенности языка сценариев в относительно статически, но было бы трудно, чтобы он стал популярным по отношению к укоренившейся Python/PHP/Perl/Ruby/Javascript. Factor - ближайшая вещь, AFAICT.

Что произойдет, так это то, что реализация языка сценариев будет быстрее, используя JIT.

Answer 7

Я спрашиваю, зачем использовать скрипты язык? Я считаю, статическими скомпилированные языков гораздо проще отлаживать и часто легче код.

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

Answer 8

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

же anwser для:

• наследования классов против прототипа;
• императив против оо;
• статические против динамического ввода;
• сильно против слабо типизированного;
• Управление памятью вручную против GC;
• C# vs Java;
• синий против красного;
• мужчина против женщины;
• бэтмен против сверхчеловека (но я думаю, что сверхчеловек выиграет ... подожди, есть криптонит ... о человеке, я не знаю ...)

и т.д ...

Answer 9

Я бы назвал свой shell (bash) языком сценариев, и я не вижу компиляцию, которая компилируется.

Мне нравится использовать scala, который является статически типизированным языком, который поставляется с интерпретаторным REPL-интерфейсом, и из-за вмешательства типа выглядит во многом подобно скриптовому языку; смотрите здесь: http://www.simplyscala.com/.

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