Весельчак У

 RXL:

Считаю неправильным критерий "Работа с большими нагрузками" - это применимо к системе в целом, а не к языку.
Все только по моему опыту.
Работал с PHP и Perl, чуть-чуть с ASP и Python. С Ruby мне работать не приходилось.
Для программирования на любом из них нужен опыт, иначе будет выходить хреново.
Все перечисленные языки не нуждаются в управлении памятью, не имеют жесткой типизации базовых типов (числа, строки) и каждый по своему подерживает ООП.
Perl.
Язык одновременно простой и сложный. Что хорошо, что не обязательно знать его весь - эффективность от этого сильно не пострадает.
Большая гибкость структур данных, простота работы с ними. Простой и удобный синтаксис работы с индексированными и ассоциативными массивами. Интегрированная в язык поддержка регулярных выражений. Поддерживает многопоточность.
Своеобразная реализация ООП - не легко разобраться во всех тонкостях, но применять не сложно.
Высокая скорость исполнения. По моему опыту perl5.6 быстрее php3 раз в 10. Php4 сравнивал уже с php3, но 10-и кратного ускорения программ не заметил.
Для большего ускорения perl можно компилить в байт-код - исключается фаза синтаксического разбора.
Встроенные возможности безопасности: меченые данные (ряд ограничений на применение этих и поизводных от них данных) и песочницы (изолированные пространства имен). Еще можно применять блоки с eval - пространство имен то же, но ошибки в блоке приводят к завершению только этого блока.
Богатая библиотека на www.cpan.org, но многие модули не документированы - приходится изучать код.
PHP.
Простой и понятный язык.
Содержит огромное число встроенных ф-ий - это, на мой взгляд, не очень хорошо.
Реализация ООП в php4 немного своеобразна. Например, нет последовательного вызова конструкторов при наследовании. В php5 реализация ООП ближе к классической.
Так же как и в perl имеется большая гибкость в построении структур данных, но целочисленные и строковые индексы замешаны в единый тип - по моему это минус.
Безопасность: ограничение дерева директорий на доступ к файлам, возможность запрета встроенных ф-ий по выбору.
Контроль ошибок: php4 - единственная ф-ия на всю программу, php5 - блоки try-catch.
ASP.
Ничего такого, что не могли бы php и perl я не увидел. Работает только под windows.
Python.
Не впечатлил... Главный, на мой взгляд, недостататок - иерархия блоков выражается в виде простого отступа - слишком грубо и чревато случайными ошибками. Параметры разделены пробелами, строки не терминируются - стремный язык.

 

Chuda:

Насчёт Питона.
Указанные минусы при правильном стиле минусами не являются.
Реализация ООП гораздо более своеобразна, чем во всех остальных языках. Как например нравится возможность создать свойство класса в отдельно взятом _объекте_ ?

 

dimka:

ООП в VBScript, JavaScript... Одно дело - поддержка объектов (например, ActiveX, документов, окон и т.п. - готовых объектов). Другое дело - написание собственных объектов. Вот для последнего в JavaScript и VBScript мне встречалось лишь так называемое HTC - собственные компоненты для страничек.
Однако в ASP серверный код пишется на VBScript и JavaScript. И в нём-то собственных объектов средствами языка не создашь.
Совсем другое дело ASP.NET. По своим возможностям близок к Java, основан на достаточно богатых библиотеках .NET. В ASP.NET 1.0 и 1.1 ещё несколько непрозрачно был организован дизайн Web-страниц (HTML-код) и его интеграция с кодом программы. В ASP.NET 2.0, говорят, это устранили, но сам пока ещё не пользовался - ручаться не могу... Может в ближайшие полгода познакомлюсь, если привлекут к соответствующим проектам.
Написание web-сервисов точно поддерживается в Java и ASP.NET - предоставляются базовые классы web-сервисов, инкапсулирующие протоколы обмена данными и удалённых вызовов функций по сети. Т.е. программист может использовать готовые решения организации web-сервисов, сосредоточившись на их функциональных возможностях и не занимаясь написанием вручную движка web-сервисов.
Я думаю (про надежность), это на 80% зависит от квалификации программиста, и лишь на 20% от платформы. Между тем пункт "безопасность" применительно к языку мне несколько непонятен: идёт ли речь о глючности трансляторов языков, идёт ли речь о защите языка программирования (на уровне конструкций языка) "от дурака"?
Если второе, то все языки без строгой типизации данных менее безопасны, поскольку логические ошибки или опечатки всплывают лишь во время исполнения кода, а не во время компиляции или верификации кода.
Затем для крупных проектов немаловажно наличие удобной среды разработки: просмотрщики объектов, отладчики и т.п. Например, отладка ASP без отладчика - это сущий кошмар, когда на любую ошибку получаешь "500 Internal server error", и ищи потом, где и почему это "500" возникло. Пока пишется новое приложение, это ещё можно обойти методом "написал новую строчку - проверил как работает". Но вот сопровождение ранее написанного крупного проекта без отладчика, особенно если проект реализован методом "спагетти", понижает КПД программиста в разы, а то и десятки раз. Вставил новую строчку - где-то в другом конце системы что-то упало, и потом часами ищи эту одну ошибку. А ошибки, бывает, возникают группами.
Впрочем, это уже более вопрос организации труда, ведения документации, хорошего проектирования, нежели выбора платформы. Если организацию труда можно классифицировать как CMM 0, то лучше позаботиться о том, чтобы хотя бы инструменты не усугубляли это печальное положение вещей Улыбаюсь. Если организация труда классифицируется как CMM 6, то инструменты уже не являются критическим фактором принципиальной реализуемости проекта даже для очень крупных проектов Улыбаюсь.