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

Question

Предполагая, что вы можете получить динамический переводчик; могут ли статически скомпилированные языки заменить язык сценариев? Я никогда не понимал , почему кто-то использует язык сценариев? Я говорю о ПК, а не об ограниченной системе, которая нуждается в упрощенном интерпретаторе. Я видел несколько скриптов установки Python и видел похожие Python и C # решения проблемы. Так зачем использовать язык сценариев?

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

Как что-нибудь баловать и учиться

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Тот же ответ для:

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

и т.д ...

Answer 7

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

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

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

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

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

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

Это не означает, что еще не спроектированный язык не может обрабатывать функции языка сценариев относительно статично, но ему будет трудно стать популярным по сравнению с укоренившимся Python / PHP / Набор Perl / Ruby / Javascript. Фактор это самая близкая вещь, АФАКТ.

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

Answer 8

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

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

Answer 9

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