почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

По историческим причинам, полагаю.

Они же не «победили» статические альтернативы: сначала почти что только они и были. А взялись, по всей видимости, из Юникс-культуры скриптов.

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

Во-вторых, специфика задачи очень часто такова, что реализацию серверной стороны надо постоянно модифицировать. Цена цикла компиляции/сборки/выкладки значительно больше простой правки на серверной стороне.

В-третьих, специфика задачи приводит к массовой работе со структурами данных стиля словарей, списков... Ещё не так давно, когда компилируемыми языками были только Си и Си++-без-STL, это всё было крайне дорого и неэффективно. Зато для какого-нибудь Perl это было основным вариантом — и сейчас на нём массив, структура это побочные подходы, зато список и словарь — родные средства.

В клиентской части это ещё ярче выражено — попытка выложить работу с DOM на C приводит или к сумасшествию программиста, или просто к неэффективному результату.

Достаточно?

Есть исключения, как тот же RSDN. Но их мало.

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

1. Скорость разработки несложных приложений на динамических ЯП выше. Веб приложения, утрировано, состоят из набора слабо связанных скриптов, логика работы всей системы определяется действием пользователя. То есть веб приложение — несложное, с точки зрения архитектуры.
2. Отсутствие потребности потребности трансляции(при изменении или добавлении кода/модулей) дает возможность хранить работающий исходный код, который может изменятся без остановки всего приложения
3. Динамические языки позволяют легко использовать возможности метапрограммирования. Что опять же повышает скорость разработки. Но и дает возможность выстраивать архитектуру без первоначального планирования, собирая работающий код в абстракции более высокого уровня

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, rsdn2010, Вы писали:

R>>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

N>Во-первых, не смешивайте языки серверной стороны и клиентской. Между ними почти нет общего (конечно, можно попробовать писать серверную сторону на Javascript, но это обычно не окупается).

Не готов говорить за окупаемость, но проект Node.js получил довольно широкую известность в последнее время.
Хотя по сути я с тобой согласен.

Здравствуйте, Skynin, Вы писали:

S>1. Скорость разработки несложных приложений на динамических ЯП выше. Веб приложения, утрировано, состоят из набора слабо связанных скриптов, логика работы всей системы определяется действием пользователя. То есть веб приложение — несложное, с точки зрения архитектуры.
S>2. Отсутствие потребности потребности трансляции(при изменении или добавлении кода/модулей) дает возможность хранить работающий исходный код, который может изменятся без остановки всего приложения
S>3. Динамические языки позволяют легко использовать возможности метапрограммирования. Что опять же повышает скорость разработки. Но и дает возможность выстраивать архитектуру без первоначального планирования, собирая работающий код в абстракции более высокого уровня

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

Здравствуйте, rsdn2010, Вы писали:

R>Здравствуйте, Skynin, Вы писали:

S>>1. Скорость разработки несложных приложений на динамических ЯП выше. Веб приложения, утрировано, состоят из набора слабо связанных скриптов, логика работы всей системы определяется действием пользователя. То есть веб приложение — несложное, с точки зрения архитектуры.
S>>2. Отсутствие потребности потребности трансляции(при изменении или добавлении кода/модулей) дает возможность хранить работающий исходный код, который может изменятся без остановки всего приложения
S>>3. Динамические языки позволяют легко использовать возможности метапрограммирования. Что опять же повышает скорость разработки. Но и дает возможность выстраивать архитектуру без первоначального планирования, собирая работающий код в абстракции более высокого уровня

R>тогда возникает вопрос...
R>почему все остальные области не перешли на такие языки?

все остальные = имеется в виду не ниша C++ и т п, а ниша C# и Java

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

Здравствуйте, rsdn2010, Вы писали:

R>>тогда возникает вопрос...
R>>почему все остальные области не перешли на такие языки?

R>все остальные = имеется в виду не ниша C++ и т п, а ниша C# и Java

тем более, как я узнал из ветки про "Области приложения С++"
http://www.rsdn.ru/forum/job/3983665.flat.1.aspx

Автор: P542XX
Дата: 04.10.10

на C# в основном пишется как оказалось не гуишная клиентская часть, а как раз таки наоборот

Здравствуйте, rsdn2010, Вы писали:

R>Здравствуйте, Skynin, Вы писали:

S>>1. Скорость разработки несложных приложений на динамических ЯП выше. Веб приложения, утрировано, состоят из набора слабо связанных скриптов, логика работы всей системы определяется действием пользователя. То есть веб приложение — несложное, с точки зрения архитектуры.
S>>2. Отсутствие потребности потребности трансляции(при изменении или добавлении кода/модулей) дает возможность хранить работающий исходный код, который может изменятся без остановки всего приложения
S>>3. Динамические языки позволяют легко использовать возможности метапрограммирования. Что опять же повышает скорость разработки. Но и дает возможность выстраивать архитектуру без первоначального планирования, собирая работающий код в абстракции более высокого уровня

R>тогда возникает вопрос...
R>почему все остальные области не перешли на такие языки?

Недостаточная развитость инфраструктуры управления библиотеками и ненасыщенность самих библиотек, чтобы заменить компилируемые языки с их наработками в своей сфере.
Компилируемые языки хорошо подходят для маркетинга программных продуктов в сфере частной собственности, так как исходный код труднее получить из откомпилированных (иногда обфусцированных) бинарников, в которых продаётся конечный продукт, а значит, сохраняется ноу-хау, выраженное в компилируемом коде, и, как следствие, преимущество продавца.

Кроме этого, не забывайте, серверная Java — это COBOL XXI века.

Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, rsdn2010, Вы писали:

R>>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

Не сможет ли в таком случае, уважаемый программист объяснить, что выполняет вот этот код:

0000000000: B3 F2 0D 0A 00 8C DD 4A ¦ 63 00 00 00 00 00 00 00  ?od0 ?YJc
0000000010: 00 07 00 00 00 40 00 00 ¦ 00 73 42 00 00 00 64 00   •   @   sB   d
0000000020: 00 5A 00 00 64 01 00 64 ¦ 02 00 6B 01 00 5A 01 00   Z  dO dO kO ZO
0000000030: 64 01 00 64 03 00 6B 02 ¦ 00 6C 03 00 5A 03 00 01  dO d¦ kO l¦ Z¦ O
0000000040: 65 01 00 69 04 00 65 03 ¦ 00 64 00 00 64 04 00 64  eO i¦ e¦ d  d¦ d
0000000050: 05 00 83 03 00 83 00 00 ¦ 83 01 00 01 64 02 00 53  ¦ ?¦ ?  ?O OdO S
0000000060: 28 06 00 00 00 73 12 00 ¦ 00 00 73 65 74 75 70 74  (¦   s¦   setupt
0000000070: 6F 6F 6C 73 3D 3D 30 2E ¦ 36 63 31 31 69 FF FF FF  ools==0.6c11iyyy
0000000080: FF 4E 28 01 00 00 00 74 ¦ 10 00 00 00 6C 6F 61 64  yN(O   t>   load
0000000090: 5F 65 6E 74 72 79 5F 70 ¦ 6F 69 6E 74 74 0F 00 00  _entry_pointt0
00000000A0: 00 63 6F 6E 73 6F 6C 65 ¦ 5F 73 63 72 69 70 74 73   console_scripts
00000000B0: 74 0C 00 00 00 65 61 73 ¦ 79 5F 69 6E 73 74 61 6C  t+   easy_instal
00000000C0: 6C 28 05 00 00 00 74 0C ¦ 00 00 00 5F 5F 72 65 71  l(¦   t+   __req
00000000D0: 75 69 72 65 73 5F 5F 74 ¦ 03 00 00 00 73 79 73 74  uires__t¦   syst
00000000E0: 0D 00 00 00 70 6B 67 5F ¦ 72 65 73 6F 75 72 63 65  d   pkg_resource
00000000F0: 73 52 00 00 00 00 74 04 ¦ 00 00 00 65 78 69 74 28  sR    t¦   exit(
0000000100: 00 00 00 00 28 00 00 00 ¦ 00 28 00 00 00 00 73 39      (    (    s9
0000000110: 00 00 00 43 3A 5C 50 72 ¦ 6F 67 72 61 6D 20 46 69     C:\Program Fi
0000000120: 6C 65 73 5C 50 79 74 68 ¦ 6F 6E 5C 32 35 5C 53 63  les\Python\25\Sc
0000000130: 72 69 70 74 73 5C 65 61 ¦ 73 79 5F 69 6E 73 74 61  ripts\easy_insta
0000000140: 6C 6C 2D 73 63 72 69 70 ¦ 74 2E 70 79 73 08 00 00  ll-script.pys•
0000000150: 00 3C 6D 6F 64 75 6C 65 ¦ 3E 03 00 00 00 73 08 00   <module>¦   s•
0000000160: 00 00 06 01 0C 01 10 02 ¦ 06 01                      ¦O+O>O¦O

являющийся единственной понятной формой среде исполнения cpython?

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

KV>Не сможет ли в таком случае, уважаемый программист объяснить, что выполняет вот этот код:
KV>являющийся единственной понятной формой среде исполнения cpython?

А что, на серверах используется CPython? Не знал. У меня на десктопе ни одного файла с его байткодом нету.

> pkg_info | grep python
boost-python-libs-1.43.0 Framework for interfacing Python and C++
exaile-0.3.2.0      A full featured python-based music player for GTK+
py26-gtksourceview-2.10.1 A python bindings for the version 2 of the GtkSourceView li
py26-notify-0.1.1_7 A python bindings for libnotify
py26-xdg-0.19       A python library to access freedesktop.org standards
python26-2.6.6      An interpreted object-oriented programming language
> find /usr/local -name '*.pys' | wc -l
find: /usr/local/etc/polkit-1: Permission denied
find: /usr/local/etc/cups/ssl: Permission denied
       0
> uname -a
FreeBSD selena.fire 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct  9 19:19:32 VOLST 2010     root@selena.fire:/usr/obj/usr/src/sys/SELENA  amd64

Здравствуйте, kochetkov.vladimir, Вы писали:

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

KV>Не сможет ли в таком случае, уважаемый программист объяснить, что выполняет вот этот код:

Если говорить про CPython, то, к сожалению, это не компиляция. Максимум, чем можно это назвать — это парсинг во внутреннее представление. Разумеется, это не 100% чёткий тезис, но то, что для работы питона не обязательно присутствие файлов *.pyc, *.pyo, достаточно показывает несущественность и возможность отсутствия специальной формы для среды исполнения.

KV>являющийся единственной понятной формой среде исполнения cpython?

Того, что среда способна поднимать py-файлы без pyc, достаточно, чтобы это утверждение было неверным.

Здравствуйте, iZEN, Вы писали:

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

KV>>Не сможет ли в таком случае, уважаемый программист объяснить, что выполняет вот этот код:
KV>>являющийся единственной понятной формой среде исполнения cpython?

ZEN>А что, на серверах используется CPython?

CPython == Canonical Python, если что. Да, он используется на серверах

ZEN>Не знал. У меня на десктопе ни одного файла с его байткодом нету.

Зато в памяти есть. Исходный код, который в файлах .py не является родным для среды исполнения python.

Здравствуйте, netch80, Вы писали:

KV>>Не сможет ли в таком случае, уважаемый программист объяснить, что выполняет вот этот код:

N>Если говорить про CPython, то, к сожалению, это не компиляция.

да я вроде нигде про компиляцию и слова не сказал

N>Максимум, чем можно это назвать — это парсинг во внутреннее представление. Разумеется, это не 100% чёткий тезис, но то, что для работы питона не обязательно присутствие файлов *.pyc, *.pyo, достаточно показывает несущественность и возможность отсутствия специальной формы для среды исполнения.

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

KV>>являющийся единственной понятной формой среде исполнения cpython?
N>Того, что среда способна поднимать py-файлы без pyc, достаточно, чтобы это утверждение было неверным.

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

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

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

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>среде (каноническому питону) необходимо преобразование исходников в байт-код для выполнения кода. Следовательно, представление в виде исходного текста не является одинаково понятным и программисту и среде исполнения. Собственно, я только с этим утверждением и спорил.

А кто преобразует в байт-код — не среда ли? Значит, это не более чем её внутреннее дело.

Здравствуйте, netch80, Вы писали:

N>Того, что среда способна поднимать py-файлы без pyc, достаточно, чтобы это утверждение было неверным.
А хочешь я тоже самое с немерлом сделаю?
Там делать то почти ничего не придется. NCC.exe это просто консольная запускалка для Nemerle.Compiler.dll.
Все что нужно это сделать аналог NCC.exe который будет компилировать прямо в памяти и передавать управление полученному коду.
И что по твоему немерле после этого станет динамически типизированным интерпритатором?

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

Сваять очередной интерпретируемый язык банально проще и быстрей.