Почему так много веб-языков интерпретируются, а не компилируются?
Почему такие языки, как C, не используются для веб-разработки? Конечно, увеличение скорости после компиляции было бы полезно для сайтов с большой нагрузкой?
15 ответов
Еще одна веская причина в том, что на большом сервере скорость выполнения не так важна, как скорость соединения. Большую часть времени тратят на отправку и получение данных, а не на подсчет чисел. И на самом деле в некоторых веб-сервисах, которые выполняют много вычислений, жесткий анализ , вероятно, выполняется как скомпилированная программа.
Кроме того, интерпретируемые языки не нуждаются в компиляции (что в большом проекте может занять время), поэтому оно больше подходит для обычно гибкой разработки веб-решений.
Большинство веб-приложений общаются с базой данных. Подавляющее большинство этих приложений тратят почти все свое время на связь с базой данных. Таким образом, для любого данного запроса к приложению на сервере приложений происходит небольшое количество обработки, а затем длительная пауза в ожидании базы данных. Поскольку такой небольшой процент времени любого запроса тратится на реальный код сервера приложений, оптимизация этого кода путем написания его на C/C++ даст лишь незначительное, вероятно, не заметное, улучшение времени отклика.
Таким образом, вместо того, чтобы фокусироваться на C/C++ и сохранять каждый последний цикл ЦП, имеет больше смысла беспокоиться о производительности разработчиков. Разработчики очень дороги. И они, как правило, гораздо более продуктивны в языке сценариев или даже в Java, чем в C/C++.
Конечно, есть исключения из этого. И если некоторые запросы к вашему приложению требуют значительных ресурсов процессора или памяти, они должны быть написаны на C/C++. Но для остальной части вашего приложения вам лучше сосредоточиться на оптимизации ваших алгоритмов, структур данных, связи с базой данных и производительности разработчика, чем на оптимизации вашего языка.
Языки сценариев имеют следующие преимущества перед C:
- Гораздо быстрее развитие
- Сегодня все те, которые имеют отношение к этому вопросу, компилируются во время выполнения. В некоторых случаях это может сделать их быстрее, чем эквивалентная программа на C, поэтому производительность больше не является проблемой.
- Расходы на техническое обслуживание намного меньше
- Вы можете разрабатывать, используя Agile методы (например, модульные тесты), что приводит к гораздо лучшему коду. Да, вы можете сделать это и в C, но это гораздо больше усилий.
- Когда вы занимаетесь веб-разработкой, у вас есть огромные фреймворки, которые выполняют большую часть работы за вас.
- Они гораздо более открыты для изменений. Реализация новой функции может занять до нескольких минут.
- Если что-то не работает, вы можете войти на свой сервер, запустить текстовый редактор в консоли и исправить проблему, иногда без необходимости перезапуска.
C был использован для веб-приложений на ранней стадии - я написал различные сценарии CGI в нем.
Однако с течением времени более производительные языки (например, C# и Java, но не только те), как оказалось, оказались "достаточно эффективными" для веб-приложений. Обратите внимание, что и C#, и Java компилируются в промежуточный код, а затем JIT-компилируются, что позволяет добиться "грубой" производительности собственного кода. Почему мы хотим использовать C вместо этого?
Насколько мне известно, даже традиционно "истинно интерпретируемые" языки, такие как PHP, часто компилируются во время выполнения. (Мои знания PHP, в частности, все из вторых рук. Может быть, они всегда были скомпилированы... И также я уверен, что есть веб-платформы, которые до сих пор всегда интерпретируются.)
По крайней мере, изначально большая часть работы, выполняемой внутренним кодом (о чем я и говорю, была текстовой). Они либо создавали страницы непосредственно с нуля, либо, например, комбинируя данные из базы данных с шаблоном.
C не всегда хорошо подходит для обработки текста. Строки C являются очень простыми, и, хотя обработка текста в C, конечно, может выполняться быстро, разработка часто занимает немного больше времени и требует более глубоких навыков, чтобы разобраться, чем языки, которые помогают вам немного больше.
Стоит отметить, что большинство языков сценариев (Python, Ruby и т. Д.) Легко - почти тривиально - подключаются к C. (Я только что написал несколько расширений C для программы на Python, и меня поразило, насколько это легко). Если у веб-сайта / веб-приложения есть некоторые узкие места из-за использования "медленного" языка сценариев, обычно можно написать разделы, критичные к производительности, на более быстром языке, таком как C. На самом деле, это то, что большие приложения, такие как поиск Google, Facebook и т. д. делают - они пишут интерфейс на языке сценариев и выполняют тяжелую работу с другими языками, такими как C.
Отличный вопрос Причина в основном из-за эволюции сети. Подумайте об этом поэтапно:
1) Основной текст в "сети" -> 2) Некоторая "разметка", добавленная к тексту -> 3) тег "center" и "marquee" сформированы!!! какой прогресс!!! -> 4) скриптинг на клиенте!!! 5) -> хм... скриптинг на сервере!!!
Хотя я и придумал этот ответ, чтобы быть немного глупым, это действительно так. Интеренет, и особенно "сеть", был удивительным эволюционным процессом. Действительно, требования к более мощным языкам (и более производительным языкам) появились совсем недавно.
Также посмотрите на инструменты. Я сделал свой PHP в блокноте (и некоторых других простых приложениях). Когда я впервые занимался веб-разработкой, на моем компьютере не было достаточно места на жестком диске для поддержки Visual Studio 2008:)
Побочное замечание: Существовали приложения ".exe" (я думаю, что " SunBiz" публикует "exe") и некоторые скомпилированные приложения на некоторое время, но их было гораздо меньше.
Попробуйте выполнить какой-либо анализ / манипулирование строками в C и Perl/PHP, и вы узнаете.
Кстати: почему так много людей заявляют, что производительность больше не проблема? Я не мог бы быть проблемой для небольших домашних страниц / блогов, но крупномасштабные веб-приложения все еще должны быть настроены на производительность (процессор / сеть / память), независимо от того, написаны ли они в java, php или ruby.
В основном потому, что их можно быстро и просто изменить на лету. Скомпилированные языки требуют среды разработки, которая должна соответствовать серверу. С помощью скрипта вы можете использовать инструмент ftp и редактировать текст напрямую, а затем сохранять его. Эта способность делать это с любого компьютера любой ОС или типа много раз спасала мою жизнь (или правильную жизнь моих сайтов).
Таким образом, вместо того, чтобы фокусироваться на C/C++ и сохранять каждый последний цикл ЦП, имеет больше смысла беспокоиться о производительности разработчиков. Разработчики очень дороги. И они, как правило, гораздо более продуктивны в языке сценариев или даже в Java, чем в C/C++.
О, так очень, очень верно. Если использование более динамичного языка освобождает неделю разработчика от графика, эта неделя времени программиста, за которую вам не нужно платить, купит вам дополнительный сервер. Может быть, даже несколько серверов, если вам нравится много дешевых, а не несколько массивных зверей.
В большинстве стран мира (например, не в Google/Amazon/eBay/ и т. Д.) Один дополнительный сервер более чем компенсирует любую потерю производительности, которая может возникнуть в результате выбора языка.
Многие из чрезвычайно полезных функций динамических языков, таких как самоанализ и функции, такие как eval(), действительно трудны / невозможны? реализовать на языках, которые компилируются в нативный код.
При этом большинство языков "сценариев" компилируют (на лету) некоторый промежуточный код, который затем интерпретируется (Python,Ruby,Perl) или, возможно, даже JIT, скомпилированный с собственным кодом (JSP, .NET)
Вот мои мысли по этому вопросу:
- Для оригинальных приложений CGI требовался собственный процесс ОС, что, конечно же, требует значительных ресурсов. Попытка объединить все в единый процесс также нелегка с нативным кодом, так как если что-то пойдет не так в приложении, это может легко привести к остановке всего сервера. С этими вещами намного проще справиться с помощью интерпретатора или виртуальной машины. Конечно, вы можете сделать то же самое с нативным кодом, но я полагаю, что реализовать фреймворк будет гораздо сложнее. В конце вы получите что-то похожее на интерпретатор или виртуальную машину.
- Интерпретируемые языки переносимы между операционными системами.
- Конечно, большим преимуществом является продуктивный прирост, который вы получаете, используя современный язык.
- Производительность, конечно, важна. Однако интерпретируемые языки или языки VM становятся все лучше и лучше в этом отношении (с такими технологиями, как JIT-компиляция) и приближаются к производительности нативного кода. Также несправедливо сравнивать только время, потраченное в процессе исполнения. Вам необходимо измерить всю последовательность: прием запроса с сервера, делегирование в правильное приложение, выполнение, возврат результатов на сервер. Будет ли нативное приложение быстрее во всех этих?
Потому что индустрия страдает от массового заблуждения, что скорость выполнения не имеет значения (что подтверждается принятым ответом).
Я думаю, что настоящая причина в том, что с интерпретируемыми языками легче начать, если вы используете существующую среду, и они делают работу над веб-приложением простой и увлекательной.
Есть много, много случаев, когда вам действительно нужно сделать сокращение числа в веб-приложениях, но разработчики в конечном итоге либо не выполняют их (потому что они дороги), и / или делегируют задачу на внешний сервер: либо сервер базы данных, либо какой-то другой. другой сервер.
Это можно увидеть в недавнем распространении так называемых "микросервисных" архитектур.
Моя компания использует C++ (расширение ISAPI) для нашего веб-приложения. Почти все сделано в скомпилированных двоичных файлах. Мы также используем движок JavaScript для частей системы, которые требуют сценариев (да, JavaScript на стороне сервера). Причиной, приведенной для этого дизайна, является скорость, но возраст также является фактором... это старая кодовая база. Кроме того, мы распространяем наш продукт среди наших клиентов для размещения самих себя, поэтому его компиляция защищает наш исходный код (многие интерпретируемые языки тривиально декомпилируемы, а в случае PHP и Perl вообще не компилируются).
Языки сценариев, где единственный вариант для веб-разработки давно. Теперь у нас есть другие альтернативы (Java, .NET ..), поэтому ситуация не так плоха.
C как платформа была не очень успешной для веб-разработки, так как трудно создать модуль, который можно было бы загружать и выполнять с сервера веб-приложений, но одной из первых платформ для создания динамического веб-приложения были модули ISAPI для IIS Microsoft, которые в основном были разработано в C++ и где скомпилировано.