зачем нужны интерпретируемые языки?

[dosha]

Сообщение от Vad33

Лень - двигатель прогресса.

ну ну некоторое эволюционирует. KPHP и HHVM

[Utkin]

В чём причина такой популярности интерпретаторов?

Бейсик проталкивал Билл Гейтс и не скрывал этого. Начиная с Доса он регулярно светится во всем мелкософтовом.

1. Кроссплатформенность. Не важно на какой системе и на каком процессоре работает комп. Если на нём стоит интерпретатор, написанный именно под него, то прикладной код будет ним интерпретироваться без переделок.

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

2. Сорость написания программ.

Небольших программ.

3. Безопасность прикладного кода. Не нужно думать о том, что стек переполнится или выйдешь за границы массива и затрёшь расположенную в соседнем сегменте прогу.

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

[waleri]

Сложность языка не определяется тем, является ли язык компилируемым или интерпретируемым.

Скорость разработки больше зависит от
а) Мощности IDE
б) Функционала библиотеки языка.

[Utkin]

Скорость разработки больше зависит от
а) Мощности IDE
б) Функционала библиотеки языка.

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

[Smitt&Wesson]

вкусные плюшки типа функций высшего порядка, навроде map, уже встроены в язык

Языки постоянно совершенствуются. Тот-же, С-подобный PHP, имеет ряд встроенных функций, позволяющих работать с массивам. Для того, чтобы нечто подобное использовать в C++, нужно написать (купить или слямзить) соответствующую библиотеку. Да ищё и выучить все дополнительные плюшки, которые для решения конкретной задачи совсем не нужны (но раз уж есть библиотека, могут пригодиться в будущем).

[Пепел Феникса]

Сообщение от Utkin

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

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

[bitix]

Вообще зачем придумали языки perl, ruby, php, python? Зачем тратить столько вычислительных ресурсов на интерпретацию кода?

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

[Utkin]

Тот-же, С-подобный PHP, имеет ряд встроенных функций, позволяющих работать с массивам.

Потому он и интерпретируемый в основном - медленно, но удобно.

[pu4koff]

Сообщение от rpy3uH

Вообще зачем придумали языки perl, ruby, php, python? Зачем тратить столько вычислительных ресурсов на интерпретацию кода?

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

Сообщение от rpy3uH

Самый быстрый и кошерный ruby работает медленее, чем нативный код примерно в 10 раз. Проще говоря: примерно 90% времени процессор тратит просто на интерпретацию кода.

Зато он кошерный. Даже ООП вносит неплохой такой оверхед и по памяти и скорости выполнения кода в том же С++ (вызов метода класса медленнее происходит, чем вызов функции). Люди зажрались, мощности некуда девать, вот и стали по всяким паттернам, да методологиям разработки заморачиваться.

Сообщение от rpy3uH

Да, понимаю, разработка на нативных языках типа С++ или Delphi, довольно сложная штука и очень много проблем с переносом на разные платформы.

Совсем никакой связи. Одно другому не мешает.

Сообщение от rpy3uH

Да и вообще медленная разработка и долгий этап тестирования.

Всё это субъективно и сложно оценивается. Я бы этого не утверждал.

Сообщение от rpy3uH

Поэтому придумали языки для мартышек типа perl, ruby, php, python, на которых можно легко и быстро накатать код, на них запилено много классов и инструментов, у которых красивый и логичный синтаксис, программист занимается реальными алгоритмическими задачами, а не тем, где у него утечка памяти или нарушение стека.

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

Сообщение от rpy3uH

Плюс, самое главное для бизнеса (бизнес - это деньги, а деньги это самое главное), самое главное, что если спец вдруг начнёт быковать, то его легко уволить и нанять другую мартышку на следующий день, в случае же сложных языков типа С++, это довольно сложная задача, искать спеца придётся месяц или два. Это очень хороший плюс и пофиг на потерю в произволительности кода в 10-15 раз.

Опять же никакой разницы. Быдлокодеры везде дешевы. Хорошие специалисты везде дороги. Быдлокодеры в "интерпретируемых" языках безопаснее, поэтому в этой нише таки можно сэкономить, но продукт в итоге всё равно будет сомнительный.

Сообщение от rpy3uH

Да, но есть Java, которая очень легко переносится и почти не уступает нативным языкам по производительности. Но она тоже очень сложная штука, таких спецов мало.

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

Сообщение от rpy3uH

Но потом придумали .NET, который почти не уступает в производительности нативным языкам, но при этом это довольно простые языки, со свеми преимуществами языков для мартышек: простота, логичность, лёгкость разработки кода. Есть Mono, есть ASP.NET, который благодаря mono можно поднять на бесплатном Linux, также есть XST - веб-сервер в котором вместо PHP можно использовать кошерный .NET язык типа C# или Delphi.NET

Поздно вышел, а теперь исторически сложился пхп, а не асп. И хостинг на лампе (LAMP) дешевле и распространеннее.

[Пепел Феникса]

(вызов метода класса медленнее происходит, чем вызов функции).

виртуатуального лишь.
только вот малое НО, реализация того же в виде функций будет работать так же.