Re[48]: почему в вебе распространены именно динамические язы - Философия программирования

почему в вебе распространены именно динамические языки программрования — 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
на 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?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

On 10.10.2010 20:27, rsdn2010 wrote:

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

Кто тебе сказал ? Самая наверное распространённая -- это Javа.
По объёму кода уж точно. И она нихрена не динамическая.

А так -- деплоить проще, но это потому, что это интерпретируемые языки,
а не потому, что динамические.

Posted via RSDN NNTP Server 2.1 beta

On 10.10.2010 23:10, rsdn2010 wrote:

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

Ещё не пришло время. Но перейдут, обязательно перейдут.

Posted via RSDN NNTP Server 2.1 beta

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

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

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

N>А кто преобразует в байт-код — не среда ли?

Парсер — парсит исходный код в AST, компилятор — компилирует AST в байт-код, среда выполнения — выполняет байт код

Что из перечисленного подразумеваешь под "средой" ты?

N>Значит, это не более чем её внутреннее дело.

Это значит, что то, что мы называет "исходным кодом на python", не является родным представлением для среды исполнения.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>И что по твоему немерле после этого станет динамически типизированным интерпритатором?

А заоодно с ним и подмножество C#, паровозом

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

В вебе намного ниже средняя квалификация и больше используются "индусы". А у динамики learning curve сильно положе.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

MZ>Ещё не пришло время. Но перейдут, обязательно перейдут.
Не уверен.
1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы.
2. Обновление кода на хостинге сделано ещё во 2м асп.нете.
3. На клиента — какая разница, что деплоить: бинарник, или архив со скриптами?

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

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

MZ>Ещё не пришло время. Но перейдут, обязательно перейдут.

Та же ява в эту нишу чуть ли не раньше (если перл не считать) вошла, что не помешало туда куче динамики
пролезть и очень прилично ее потеснить.

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

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

Вряд-ли, те же питон с руби не проще статических языков.

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

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

FR>Вряд-ли, те же питон с руби не проще статических языков.

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

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

FR>>Вряд-ли, те же питон с руби не проще статических языков.

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

Простой компилятор пишется также быстро:

http://portal.acm.org/citation.cfm?id=1085114.1085122
http://min-caml.sourceforge.net/index-e.html

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

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

Можно сделать компилятор под существующую VM. Например, CLR или JVM. Достаточно простой язык — по кр. мере соответствующий возможностям VM — можно будет слепить даже быстрее, чем интерпретатор.

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

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

MZ>>Ещё не пришло время. Но перейдут, обязательно перейдут.
FR>Та же ява в эту нишу чуть ли не раньше (если перл не считать) вошла, что не помешало туда куче динамики
FR>пролезть и очень прилично ее потеснить.

Кстати, вот интересно. Если даже посмотреть на тот же ASP.NET, то на заре своего появления он позиционировался именно как: пишем для веб на статически типизированном языке, код отдельно, разметка — отдельно, деплоим на сервер бинарники. Студии ранних версий AFAIR вообще не поддерживали другой модели разработки. (Хотя сам ASP.NET умел).

А вот если посмотреть что происходит сейчас, то ASP.NET стал куда более "scripty" что ли. Во-первых, деплоймент бинарников теперь вроде как моветон, снова рекламируется "код вместе с разметкой". Благодаря динамической компиляции практически имитируется "интерпретируемость". Да и статическая типизация уже чувствуется не столь явно опять же благодаря той самой динамической компиляции. Т.е. вместо "даешь статический язык в веб" получилось, что делаем вид, будто бы у нас все как у всех.

Вот реально интересно — почему так происходит

Кстати, scripty ASP.NET мне тоже кажется более удобным, чем "старый".

MZ>>Ещё не пришло время. Но перейдут, обязательно перейдут.
S>Не уверен.
S>1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы.

Здесь слэш означает «или» или «и»? Потому что Слаботипизированные != с динамической проверкой типов

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

S>>1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы.

M>Здесь слэш означает «или» или «и»? Потому что Слаботипизированные != с динамической проверкой типов
Здесь слеш означает "подстраховался"

Или.

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

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

S>Здесь слеш означает "подстраховался"

Или.

S>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.

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

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

FR>На лиспе и смалталке было полно (и есть) больших проектов.
FR>А сейчас и питон с руби уже используются для не мелких вещей.
Ну вы же не назовёте такие вещи мэйнстримом? Напомню, мы обсуждаем

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

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

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

FR>>На лиспе и смалталке было полно (и есть) больших проектов.
FR>>А сейчас и питон с руби уже используются для не мелких вещей.
S>Ну вы же не назовёте такие вещи мэйнстримом? Напомню, мы обсуждаем

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

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

FR>Питон сейчас тоже вполне близок к мейнстриму и достаточно широко используется не только в вебе и скриптинге.
Близок, но в обозримом будущем ни на что большее не претендует.
Вообще, мерянья "кто у кого откусит кусок" — довольно бессмысленное занятие. Я так подозреваю, что по распространённости на десктопах всех зарулит lua

*лопата: lua массово используется в игровых движках.

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

S>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.

А вы на "больших проектах" для статически-типизированных языков тесты не пишите?

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

S>>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.

ВВ>А вы на "больших проектах" для статически-типизированных языков тесты не пишите?
С переходом на code contracts и статические проверки (в процессе) нано-юнит тесты практически не пишутся, интеграционные — а как без них?

Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.
Но это, согласитесь совсем другой уровень проблем.

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

ВВ>>А вы на "больших проектах" для статически-типизированных языков тесты не пишите?
S>С переходом на code contracts и статические проверки (в процессе) нано-юнит тесты практически не пишутся, интеграционные — а как без них?

Стоп. Мы говорим о каких-то конкретных языках? Для есть контракты для статических языков, точно также как и для динамических есть специальные верификаторы — тот же pychecker, к примеру.

S>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.

"Очень много", да. В том-то и дело, что тут критерии исключительно количественные. В статическом языке тоже можно наплодить ошибок, в т.ч. и из-за опечаток, которые выстрелят только в рантайме. Компилятор статического языка позволяет отследить больше ошибок, чем компилятор динамического. Это бесспорно плюс. Но тесты-то все равно писать надо. А раз их надо писать в обоих случаях...

Вот и получается:
1. Микро-тесты в динамике с одной стороны необходимы, с другой — от них тоже можно избавиться, если пользоваться услугами верификаторов
2. Микро-тесты есть плата за гибкость системы типов, лаконичность кода и пр. Т.е. вы быстрее напишите работающий прототип, но чуть больше времени потратите на тесты. Вполне приемлимый trade off как по мне.

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

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

ВВ>А вот если посмотреть что происходит сейчас, то ASP.NET стал куда более "scripty" что ли. Во-первых, деплоймент бинарников теперь вроде как моветон, снова рекламируется "код вместе с разметкой". Благодаря динамической компиляции практически имитируется "интерпретируемость". Да и статическая типизация уже чувствуется не столь явно опять же благодаря той самой динамической компиляции. Т.е. вместо "даешь статический язык в веб" получилось, что делаем вид, будто бы у нас все как у всех.

Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

Л>А с компилятором специалисту, владеющему ассемблером, возни куда на большее время.

Есть готовые бекенды — JVM, LLVM, CLR.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>Стоп.
Стоп. А смысл обсуждать сфероконические тесты? Вы вообще двукратно уходите от темы.

	вся дискуссия
	MZ: Ещё не пришло время. Но перейдут, обязательно перейдут. S: Не уверен. 1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы. ... Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит. ВВ: А вы на "больших проектах" для статически-типизированных языков тесты не пишите? — раз S: С переходом на code contracts и статические проверки (в процессе) нано-юнит тесты практически не пишутся, интеграционные — а как без них? BB: Стоп. Мы говорим о каких-то конкретных языках? Для есть контракты для статических языков, точно также как и для динамических есть специальные верификаторы — тот же pychecker, к примеру. — два Раз как бы понятно: — вы используете тесты для костылей — а вы вообще не используете тесты? Два — pychecker по возможностям оочень далёк от компилятора статического языка. До code contracts ему ещё дальше.

Как с вами спорить?

S>>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.
ВВ>"Очень много", да. В том-то и дело, что тут критерии исключительно количественные.
BB>Компилятор статического языка позволяет отследить больше ошибок, чем компилятор динамического. Это бесспорно плюс. Но тесты-то все равно писать надо. А раз их надо писать в обоих случаях...

Ок. Я сформулирую так:
Статические проверки значительно повышают качество кода, за счёт того, что больше (*относительная метрика

) ресурсов уходит на проверку не ошибок программиста — они находятся автоматом при сборке проекта — а на проверку дизайна/соответствия требованиям.

ВВ>В статическом языке тоже можно наплодить ошибок, в т.ч. и из-за опечаток, которые выстрелят только в рантайме.
Пример в студию.

ВВ>1. Микро-тесты ... — от них тоже можно избавиться, если пользоваться услугами верификаторов
И тут тоже, плиз.

ВВ>2. Микро-тесты есть плата за гибкость системы типов, лаконичность кода и пр. Т.е. вы быстрее напишите работающий прототип, но чуть больше времени потратите на тесты. Вполне приемлимый trade off как по мне.

Прототип, во-первых, приводить к продакшн-коду, и, во-вторых, поддерживать. В лучшем случае баш на баш выйдет.

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

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

S>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.
Опечатки — да, но думаю с ними не плохо справляется ide.
Ошибки — если это ошибка в логике, то тут никакая типизация не поможет, если же речь о "перепутали местами fргументы" опять же хорошая ide должна свести их к минимум.
Имхо, пользы от системы типов уровня java не так много и большенство проблем можно решит инструментально.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

S>>Статические проверки отсеивают очень много ошибок/опечаток. С динамикой всё куда сложнее.
D>Опечатки — да, но думаю с ними не плохо справляется ide.
Это при late binding-то?%)

D>Ошибки — если это ошибка в логике, то тут никакая типизация не поможет, если же речь о "перепутали местами fргументы" опять же хорошая ide должна свести их к минимум.

Необязательно. Вы ещё забыли вызовов метода с неверными параметрами/вызов недопустимого в данном состоянии метода. Вот имено их CodeContracts и ловят в основном. Ну, ещё инварианты покрывают всякую экзотику, ради которой раньше писались пачки юнит-тестов. Точнее, пардон, сами тесты на инварианты никуда не денутся, только их можно генерить автоматом — см pex.

D>Имхо, пользы от системы типов уровня java не так много и большенство проблем можно решит инструментально.
Дык примеры, примеры!

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

AVK>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>А вот если посмотреть что происходит сейчас, то ASP.NET стал куда более "scripty" что ли. Во-первых, деплоймент бинарников теперь вроде как моветон, снова рекламируется "код вместе с разметкой". Благодаря динамической компиляции практически имитируется "интерпретируемость". Да и статическая типизация уже чувствуется не столь явно опять же благодаря той самой динамической компиляции. Т.е. вместо "даешь статический язык в веб" получилось, что делаем вид, будто бы у нас все как у всех.

AVK>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

Да только эти, с позволения сказать, "околотехнологии" завязаны на одну платформу — Windows. И Microsoft пророк её.

Для нормальных людей есть независимый от операционки web-фреймворк JSF (JavaServer Faces, JSR 127/JSR 314) с нормальным компонентным подходом (возможность использовать портлеты JSR 168/JSR 286/JSR 301 или XUL).

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

AVK>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

Ну ASP.NET MVC как раз и имеет куда более "scripty" стиль, чем ASP.NET в своем первоначальном виде.
А то, что в угоду массам — это, конечно, так. Другой вопрос — плохо ли это.

В том виде, в котором ASP.NET подавался в первой своей версии, у него очень плохо дела обстояли с REPL-ом. Не знаю, является ли REPL чем-то таким строго необходимым именно для веба и не столь обязательным для того же десктопа, другой вопрос, что люди привыкли к тому, что мейнстрим средства разработки для веба на тот момент (да и сейчас) имели отличную поддержку REPL.

S>>>1. Слаботипизированные/с динамической проверкой типов отпадают сразу: для сложного кода они малоприменимы.

M>>Здесь слэш означает «или» или «и»? Потому что Слаботипизированные != с динамической проверкой типов
S>Здесь слеш означает "подстраховался"

Или.

S>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.

Ну, люди, пишущие на Erlang'е с тобой не согласились бы

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

S>Это при late binding-то?%)
Если вам нужен late binding, вам статика также не спасет.

S>Необязательно. Вы ещё забыли вызовов метода с неверными параметрами/вызов недопустимого в данном состоянии метода. Вот имено их CodeContracts и ловят в основном.
А кто мешает их исользовать в динамике? Все равно подовляющее большенство падений происходит также в рантайме.
S>Дык примеры, примеры!
90% интернета? Если бы от статики была бы существенная польза, акромя скорости которая в вэбе особо не нужна, думаете все бы продолжали есть кактусы?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

S>Необязательно. Вы ещё забыли вызовов метода с неверными параметрами/вызов недопустимого в данном состоянии метода. Вот имено их CodeContracts и ловят в основном. Ну, ещё инварианты покрывают всякую экзотику, ради которой раньше писались пачки юнит-тестов. Точнее, пардон, сами тесты на инварианты никуда не денутся, только их можно генерить автоматом — см pex.

Design by Contract вполне применим и применяется в динамике. Конечно чисто статической проверки как в NET'овском Code Contracts (там кстати тоже без прогона в общем не обойтись) нет, но в том же питоне (в Smalltalk тоже) например контракты оформляются в виде декораторов и метаклассов, которые отрабатывают в момент загрузки модуля (аналог compile-time для статики).

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

S>Как с вами спорить?

Сначала лучше определиться, о чем мы спорим. Ваша мысль была — языки с динамической типизацией не подходят для разработки больших проектов. Я правильно сформулировал? Речь не была о том, что какой-то конкретный язык не подходит. А какой-то конкретный — скажем, C# — подходит более чем полностью.
Опять же, если бы вы сказали, что, скажем, PHP не подходит для разработки больших проектов, я, может быть, с вами и согласился бы (несмотря на то, что больших проектов на PHP до хрена).
Но нет — мы говорим "в общем" о языках с динамической типизацией, обо всей братии, так сказать. О сферических конях, т.е. В этой связи приводить в пример какие-то конкретные статически-типизированные языки и платформы мне кажется не совсем честным что ли.

S>Ок. Я сформулирую так:
S>Статические проверки значительно повышают качество кода, за счёт того, что больше (*относительная метрика

) ресурсов уходит на проверку не ошибок программиста — они находятся автоматом при сборке проекта — а на проверку дизайна/соответствия требованиям.

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

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

Вот честно, я не вижу, чем ваш аргумент — надо писать больше тестов, следовательно, не подходят (логическую цепочку см. выше) — лучше вышеприведенного.

ВВ>>В статическом языке тоже можно наплодить ошибок, в т.ч. и из-за опечаток, которые выстрелят только в рантайме.
S>Пример в студию.

Скобочки не там закрыли? Доступ к массиву по индексу? Опечатались в названии ключа для хэш-таблицы? Вместо "==" написали в условном операторе "="? Да еще проще — в конфиге опечатался, где у меня список каких-нибудь классов хранится (плагины, например, или HTTP-хэндлеры какие-нибудь). В общем в зависимости от языка, список может быть довольно длинным.

Вообще интересная ситуация получается. Раз уж так хочется дотнет, возьмем C#. Статически-типизированный язык, да. Вот только что ж людям-то при этом "на месте не сидится"? Постоянно пытаются с этой самой статикой бороться, ценой, естестественно, потери львиной доли проверок на этапе компиляции. Тут вам и рефлекшины всех сортов, и кодогенерация в рантайме, и всяческие IOC-контейнеры с ХМЛ-конфигами (ХМЛ-конфиги, кстати, тоже тема отдельная и благодатная), теперь вот еще dynamic прикрутили. На фига все это? Чем статическая типизация не устраивает? Зачем в язык тащить столько динамики? (А потом еще и тесты писать, ага).

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

ВВ>>1. Микро-тесты ... — от них тоже можно избавиться, если пользоваться услугами верификаторов
S>И тут тоже, плиз.

В каком виде хотите пример? Тот же pychecker делает довольно многое для избавления от ряда микро-тестов, само наличие которых (опять же) никак "большим проектам" не мешает. Ибо обратное не доказано.

ВВ>>2. Микро-тесты есть плата за гибкость системы типов, лаконичность кода и пр. Т.е. вы быстрее напишите работающий прототип, но чуть больше времени потратите на тесты. Вполне приемлимый trade off как по мне.
S>Прототип, во-первых, приводить к продакшн-коду, и, во-вторых, поддерживать. В лучшем случае баш на баш выйдет.

В лучшем случае "баш на баш" — мы о чем спорим-то теперь?

Я согласен, что "баш на баш", серебряной пули нет. Иначе говоря, я согласен, что динамически-типизированные языки для разработки "больших проектов" удобны где-то в той же мере, что и статически-типизированные. Все, предмета спора нет?

ВВ>>Опять же я не вижу, как из всего этого следует невозможность или сложность написания больших проектов на динамических языках.
S>Никак, но почему-то никто не несёт свет динамики в массы.

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

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

AVK>>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

ZEN>Да только эти, с позволения сказать, "околотехнологии" завязаны на одну платформу — Windows. И Microsoft пророк её.

Очень в тему топика

. И, да, MVC под Mono работает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>Ну ASP.NET MVC как раз и имеет куда более "scripty" стиль, чем ASP.NET в своем первоначальном виде.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

S>>Это при late binding-то?%)
D>Если вам нужен late binding, вам статика также не спасет.

А если не нужен?

S>>Дык примеры, примеры!
D>90% интернета? Если бы от статики была бы существенная польза, акромя скорости которая в вэбе особо не нужна, думаете все бы продолжали есть кактусы?

Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Ну ASP.NET MVC как раз и имеет куда более "scripty" стиль, чем ASP.NET в своем первоначальном виде.
AVK>Он гораздо более типизирован и лучше контроллируется компилятором по факту, чем оригинальные вебформсы. А как он для тебя выглядит, это уже пофигу.

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

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

ВВ>Вот только в сочетании с динамической компиляцией это самое "лучше контролируется" ничего с точки зрения статики не дает.

Ну так не сочетай, делов то.

ВВ> Ибо выделенной стадии компиляции уже нет

При желании — есть.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Вот только в сочетании с динамической компиляцией это самое "лучше контролируется" ничего с точки зрения статики не дает.
AVK>Ну так не сочетай, делов то.
ВВ>> Ибо выделенной стадии компиляции уже нет
AVK>При желании — есть.

Ты изначальную тему не забыл, если что? ASP.NET, как я помню, поддерживал эту самую динамическую компиляцию с версии 1.0. Только Visual Studio не поддерживала. И активно рекламировался code behind как "тру" путь.

Теперь — с точностью до наоборот. Предкомпиляция по-прежнему доступна. Но вот рекламируется теперь именно динамическая компиляция как тот же самый "тру" путь. И именно она является "моделью по умолчанию", которую поддерживает студия. Если она вообще еще поддерживает старый коде бехаинд с предкомпиляцией — в чем я сомневаюсь, если честно.

В тему к вопросу, заданному в subj, эти метаморфозы ASP.NET весьма интересны.

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

S>>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.

ВВ>А вы на "больших проектах" для статически-типизированных языков тесты не пишите?

А кто будет сторожить сторожей?

$TestsResult = fasle; // or result of smthng or...

//
// ....
//

$TestResult = Security.IsAccessAllowed($fakeUser); // You cannot pass!
Assert.AreEqual(false, $TestsResult);

Мы всё сделали правильно, обложились тестами, нам опечатки не страшны?

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

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

S>>>Это при late binding-то?%)
D>>Если вам нужен late binding, вам статика также не спасет.

AVK>А если не нужен?
Не нужен, не используйте, в чем проблемма?

S>>>Дык примеры, примеры!
D>>90% интернета? Если бы от статики была бы существенная польза, акромя скорости которая в вэбе особо не нужна, думаете все бы продолжали есть кактусы?

AVK>Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.
Причина не в леммингах, а в том что php на десять лет старше, пройдет еще десяток и ror будет таким же кривоглазым по сравнению например с каким нибудь nor.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>А кто будет сторожить сторожей?

YKU>

YKU>$TestsResult = fasle; // or result of smthng or...

YKU>//
YKU>// ....
YKU>//

YKU>$TestResult = Security.IsAccessAllowed($fakeUser); // You cannot pass!
YKU>Assert.AreEqual(false, $TestsResult);
YKU>

YKU>Мы всё сделали правильно, обложились тестами, нам опечатки не страшны?

Примера не понял

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

AVK>>А если не нужен?
D>Не нужен, не используйте, в чем проблемма?

В динамике статического бидинга нет.

AVK>>Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.
D>Причина не в леммингах, а в том что php на десять лет старше

Уверен?

D>пройдет еще десяток и ror будет таким же кривоглазым по сравнению например с каким нибудь nor.

php был кривоглазым с рождения.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>Ты изначальную тему не забыл, если что? ASP.NET, как я помню, поддерживал эту самую динамическую компиляцию с версии 1.0. Только Visual Studio не поддерживала. И активно рекламировался code behind как "тру" путь.

Что и где рекламируется — нетехнический вопрос, и лично мне его обсуждать не интересно. Чем больше народа на подобную рекламу будут вестись, тем востребованее будет мой труд.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

Здравствуйте, Mamut, Вы писали:
S>>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.
M>Ну, люди, пишущие на Erlang'е с тобой не согласились бы

Кстати да. Раз уж речь зашла, в The Development of Erlang (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.5602) есть и страничка про типизацию (о способности системы типов ловить что-то серьезнее опечаток).

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

ВВ>Примера не понял

Из-за опечатки тест всегда будет passed. Пример иллюстрирует, так иногда тесты помогают в борьбе с опечатками.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

ВВ>>Примера не понял

YKU>Из-за опечатки тест всегда будет passed. Пример иллюстрирует, так иногда тесты помогают в борьбе с опечатками.

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

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

S>>Потому как всё, что для обнаружения опечатки требует прогона тестов, на большом проекте не взлетит.
M>Ну, люди, пишущие на Erlang'е с тобой не согласились бы

Ну так эрланг слегка специфичная штука и не лезет в "нишу явы/шарпа".

*да-да, я издевательски придерживаюсь исходной темы.

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

D>Если вам нужен late binding, вам статика также не спасет.
Он не нужен, но как вы собираетесь добиться динамической типизации без позднего связывания?

S>>Необязательно. Вы ещё забыли вызовов метода с неверными параметрами/вызов недопустимого в данном состоянии метода. Вот имено их CodeContracts и ловят в основном.
D>А кто мешает их исользовать в динамике? Все равно подовляющее большенство падений происходит также в рантайме.
То, что для динамика code flow построить мягко говоря посложнее.

S>>Дык примеры, примеры!
D>90% интернета? Если бы от статики была бы существенная польза, акромя скорости которая в вэбе особо не нужна, думаете все бы продолжали есть кактусы?
Ну censored же! Следим за дискуссией, ок? Третьему человеку говорю: я ответил на

Тогда возникает вопрос...
почему все остальные области не перешли на такие языки?
все остальные = имеется в виду не ниша C++ и т п, а ниша C# и Java

А то так можно договориться до того, что я вообще против <подставить нужное>.

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

FR>Design by Contract вполне применим и применяется в динамике. Конечно чисто статической проверки как в NET'овском Code Contracts (там кстати тоже без прогона в общем не обойтись)
Не совсем так, используется "abstract interpretation", что бы это у MS Research не значило.
http://research.microsoft.com/apps/pubs/default.aspx?id=135669

FR> но в том же питоне (в Smalltalk тоже) например контракты оформляются в виде декораторов и метаклассов, которые отрабатывают в момент загрузки модуля (аналог compile-time для статики).

Гмм... а возможно организовать что-то аля code flow analysis — чтоб обнаруживать только действительные нарушения контрактов? Code Contracts именно этим и сильны — если у нас какое-то условие уже проверено, ложных сообщений о нарушении контракта не будет.

Я даже в теории не могу представить, как это можно сделать для динамики, когда в общем случае неизвестно что это у нас за "a.Foo 42";

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

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

AVK>>>Ну просто ASP.NET стал развиваться в угоду массам. Но технологии для нормальных пацанов, кстати, тоже есть — например ASP.NET MVC

iZEN>>Да только эти, с позволения сказать, "околотехнологии" завязаны на одну платформу — Windows. И Microsoft пророк её.

AVK>Очень в тему топика

. И, да, MVC под Mono работает.

Mono на сервере? Только в страшном сне.

http://www.linux.org.ru/news/opensource/5414839/page-1

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

Accepted. У меня даже возразить по делу не получается —

?

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

S>Не совсем так, используется "abstract interpretation", что бы это у MS Research не значило.
S>http://research.microsoft.com/apps/pubs/default.aspx?id=135669

Ну по сути (как я это понимаю) это довольно просто вместо реального прогона байткода проводится его интерпретация с проверкой только некоторых аспектов, например типизации, эта же технология используется в одной из реализаций питона PyPy http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation

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

FR>> но в том же питоне (в Smalltalk тоже) например контракты оформляются в виде декораторов и метаклассов, которые отрабатывают в момент загрузки модуля (аналог compile-time для статики).

S>Гмм... а возможно организовать что-то аля code flow analysis — чтоб обнаруживать только действительные нарушения контрактов? Code Contracts именно этим и сильны — если у нас какое-то условие уже проверено, ложных сообщений о нарушении контракта не будет.

В классическом питоне нет.
Но тот же PyPy по сути проводит анализ программы, вывод типов и перевод на статическое подмножество питона (R-Python) он как раз умеет строить статические control flow graph http://codespeak.net/pypy/dist/pypy/doc/architecture.html#the-translation-framework.
Аналогичные вещи были разработаны и для Smalltalk — Strongtalk и Self, от них кстати и пошли JIT для явы. Также компиляторы лиспа и схемы используют подобные технологии (как демонстрация http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)).

S>Я даже в теории не могу представить, как это можно сделать для динамики, когда в общем случае неизвестно что это у нас за "a.Foo 42";

Все это делается и делалось, притом делалось когда шарпа и вовсе не было, а ява была примитивным интерпретатором.

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

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

D>>Если вам нужен late binding, вам статика также не спасет.
S>Он не нужен, но как вы собираетесь добиться динамической типизации без позднего связывания?
Я применяю термин познего связывания не к
class foo:
def bar(self):
return 1;
foo().bar

а к

get("http://something.com/getjson").bar

Или вы утверждаете что сейчас нет нормальных ide для дя?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

Вполне возможно, что я вас неправильно понял, но CC такие ассерты спокойнейше прожёвывают. Более того, они прожёвывают любую функцию без сайд-эффектов (помеченную атрибутом [Pure]). Так что не так всё просто

void A(int a)
{
  Contract.Requires(a>5);
  Contract.Requires(a<25);
}
void B()
{
  A(222);
}

Завтра конечно проверю, но я не вижу причин, по которым код выше не будет работать. Отпишусь.

FR>В классическом питоне нет...
Ок, покопаюсь. Спасибо!

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

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

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

Замечание интересное, но — пусть и сваял кто-то новый язык, и что — он сразу становится популярным в вебе? К тому же не так уж и много разных интерпретируемых языков популярно в вебе.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

ZEN>Mono на сервере? Только в страшном сне.

Знаю не одну работающую инсталляцию. ВРоде бы неизлечимых проблем нет. А что не так?

ZEN>http://www.linux.org.ru/news/opensource/5414839/page-1

И? Я должен просмотреть лоровский пердеж чтобы понять, что ты сказать хотел?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

S>Вполне возможно, что я вас неправильно понял, но CC такие ассерты спокойнейше прожёвывают. Более того, они прожёвывают любую функцию без сайд-эффектов (помеченную атрибутом [Pure]). Так что не так всё просто

S>

S>void A(int a)
S>{
S>  Contract.Requires(a>5);
S>  Contract.Requires(a<25);
S>}
S>void B()
S>{
S>  A(222);
S>}
S>

S>Завтра конечно проверю, но я не вижу причин, по которым код выше не будет работать. Отпишусь.

Так на вход же может подаваться любая переменная свободно изменяющаяся в рантайме, без зависимых типов такое не разрулить,
так что контракты скорее всего отрабатываются в рантайме. Например D тоже может в compile time для констант разруливать
такие контракты:

pure int A(int a)
in
{
    assert(a > 5);
    assert(a < 25);
}
body
{
    return a + 1;
}

void main()
{
    static x = A(123);
}

Выдаст во время компиляции такую ошибку:

contr1.d(6): Error: assert(a < 25) failed
contr1.d(15): Error: cannot evaluate A(123) at compile time

Но если заменить static (это вычисляется в compile time) на auto, то ошибок компиляции не будет, но будет
исключение после запуска.

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

FR>Так на вход же может подаваться любая переменная свободно изменяющаяся в рантайме, без зависимых типов такое не разрулить,

Ну да. CC выдают предупреждение "contract unproven". Либо игнорировать (выпадет в рантайме, если включите соотв. опцию), либо добавлять проверки выше по стеку. Ложных срабатываний (пока) очень мало.

FR>Например D тоже может в compile time для констант разруливать такие контракты:
Интересный подход.

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

F>Замечание интересное, но — пусть и сваял кто-то новый язык, и что — он сразу становится популярным в вебе?
Конечно нет. Стать популярным — это все равно, что выиграть в лотерею.

F>К тому же не так уж и много разных интерпретируемых языков популярно в вебе.
Я подозреваю, что практически все они специально для веба и разрабатывались. Даже, наверное, для собственных нужд авторов в рамках тех или иных веб проектов. Так что получить результат по-быстрее для их создателей было очень актуальнео.

Вообще, потребность в Domain Specific Language для веба достаточно очевидна. Но я б ручонки всем авторам динамических языков поотрывал. Могли бы ограничиться трансляторами со своего языка в сишный или плюсовый код. На самом C++ могли бы с помощью перегрузки операторов сделать DSL. Да и вообще, для веба нужен не столько функциональный язык, сколько HTML-шаблонизатор с возможностью подстановки данных из баз, интеграцией с веб-сервером.

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

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

А почему ты так считашь? Вот на этом сайте все не так, например. И таких примеров море. Чем более отечественная разработка, тем реже там скрипты и тем чаще там компилируемые (но тоже безопасные и динамичные) языки.

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

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

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

ВВ>Теперь — с точностью до наоборот. Предкомпиляция по-прежнему доступна. Но вот рекламируется теперь именно динамическая компиляция как тот же самый "тру" путь. И именно она является "моделью по умолчанию", которую поддерживает студия. Если она вообще еще поддерживает старый коде бехаинд с предкомпиляцией — в чем я сомневаюсь, если честно.
Вопрос не в "бехаинд с предкомпиляцией", а в том, что во-первых, при нормальной разработке компилироваться все, включая страницы, должно как минимум при каждом коммите, а лучше при каждой компиляции. А во-вторых, как раз рекламируется вынос всей логики из некомпилирующихся по умолчанию вьюшек в контроллеры и другой "кодбехаинд".
Так что не угадал.

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>

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

Л>Я подозреваю, что практически все они специально для веба и разрабатывались. Даже, наверное, для собственных нужд авторов в рамках тех или иных веб проектов. Так что получить результат по-быстрее для их создателей было очень актуальнео.

"Подозреваю"... ты не программист, а гуманитарий чтоль? Из динамических языков вебных популярных я бы назвал PHP, Perl, Ruby и Python. Специально для веба разрабатывался из них только PHP (Personal Home Page при рождении). Комментарии?

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

К>"Подозреваю"... ты не программист, а гуманитарий чтоль? Из динамических языков вебных популярных я бы назвал PHP, Perl, Ruby и Python. Специально для веба разрабатывался из них только PHP (Personal Home Page при рождении). Комментарии?

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

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

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

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

VD>А почему ты так считашь? Вот на этом сайте все не так, например. И таких примеров море. Чем более отечественная разработка, тем реже там скрипты и тем чаще там компилируемые (но тоже безопасные и динамичные) языки.

Влад, у тебя, наверное, есть статистика в поддержку этого утверждения?

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

F>>К тому же не так уж и много разных интерпретируемых языков популярно в вебе.
Л>Я подозреваю, что практически все они специально для веба и разрабатывались. Даже, наверное, для собственных нужд авторов в рамках тех или иных веб проектов. Так что получить результат по-быстрее для их создателей было очень актуальнео.

Перл и питон появились когда веба еще практически не было, руби чуть позже но, он по словам автора их производная. Остается только PHP который да по сути DSL — переросток.

Л>Вообще, потребность в Domain Specific Language для веба достаточно очевидна. Но я б ручонки всем авторам динамических языков поотрывал. Могли бы ограничиться трансляторами со своего языка в сишный или плюсовый код.

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

Л>На самом C++ могли бы с помощью перегрузки операторов сделать DSL.

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

Л>Да и вообще, для веба нужен не столько функциональный язык, сколько HTML-шаблонизатор с возможностью подстановки данных из баз, интеграцией с веб-сервером.

Почему-то разработчикам PHP не хватает, иначе не питон ни руби в эту нишу ни пролезли бы.

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

VD>>А почему ты так считашь? Вот на этом сайте все не так, например. И таких примеров море. Чем более отечественная разработка, тем реже там скрипты и тем чаще там компилируемые (но тоже безопасные и динамичные) языки.

К>Влад, у тебя, наверное, есть статистика в поддержку этого утверждения?

У меня есть глаза. Этого достаточно чтобы заметить на чем работают www.microsoft.com, www.ibm.com и т.п.

А статистикой я не занимаю. Думаю, что ты тоже.

ЗЫ

Возможно тебя смутило слово "отечественная" — это очепятка исправления орфографии. Имелось в виду "ответственная".

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

VD>Здравствуйте, Курилка, Вы писали:

VD>>>А почему ты так считашь? Вот на этом сайте все не так, например. И таких примеров море. Чем более отечественная разработка, тем реже там скрипты и тем чаще там компилируемые (но тоже безопасные и динамичные) языки.

К>>Влад, у тебя, наверное, есть статистика в поддержку этого утверждения?

VD>У меня есть глаза. Этого достаточно чтобы заметить на чем работают www.microsoft.com, www.ibm.com и т.п.

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

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

VD>>У меня есть глаза. Этого достаточно чтобы заметить на чем работают www.microsoft.com, www.ibm.com и т.п.

R>читал, что мсовский сайт написан на специально заточенном асп, потому что обычный такие нагрузки не выдерживает

Где ты такой бред выискал?

Нет никакого московского сайта ни у Microsoft, ни у IBM. Они все живут на корпоративных серверах.

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

Никакого специализированного АСП тоже нет в природе. Есть технологии распределения нагрузки и т.п.

Наш сайт тоже имеет не само маленькую посещаемость (по меркам рунета по крайней мере) — около 20-30 тысяч посетителей в день. Хиты измеряются миллионами. И тем не менее наш сайт работает на одном сервере (2 процессора по 4 ядра, 16 гиг оперативки и RAID0 на скази-винтах). Сервер не кислый конечно, но это далеко не те монстры, что продают HP, IBM и т.п.

Так что все это выдумки.

Дотнет в отличии от скриптов порождает отличный машинный код мало уступающий тому что можно получить от компиляторов С/С++. При этом языки вроде C# типобезопасны и отлично поддерживают компонентный подход, что позволяет добиться отличной динамичности.

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

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

VD>>>У меня есть глаза. Этого достаточно чтобы заметить на чем работают www.microsoft.com, www.ibm.com и т.п.

R>>читал, что мсовский сайт написан на специально заточенном асп, потому что обычный такие нагрузки не выдерживает

VD>Где ты такой бред выискал?

VD>Нет никакого московского сайта ни у Microsoft, ни у IBM. Они все живут на корпоративных серверах.

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

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

VD>Дотнет в отличии от скриптов порождает отличный машинный код мало уступающий тому что можно получить от компиляторов С/С++. При этом языки вроде C# типобезопасны и отлично поддерживают компонентный подход, что позволяет добиться отличной динамичности.

Как будто в машину времени попал

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

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

VD>>>У меня есть глаза. Этого достаточно чтобы заметить на чем работают www.microsoft.com, www.ibm.com и т.п.

R>>читал, что мсовский сайт написан на специально заточенном асп, потому что обычный такие нагрузки не выдерживает

VD>Где ты такой бред выискал?

где-то на рсдн

VD>Нет никакого московского сайта ни у Microsoft, ни у IBM. Они все живут на корпоративных серверах.

мсовский = ms-овский = microsoft.com

VD>Посещаемость у этих серверов конечно неслабая, но как раз таки в таких условиях скрипты сливают по полной.

даже с использованием APC у php? (читал что это кардинально ускоряет работу)
или какой-то прекомпиляции у питона (здесь не в теме)

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

VD>Возможно тебя смутило слово "отечественная" — это очепятка исправления орфографии. Имелось в виду "ответственная".

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

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

К>Влад, вроде как человек не опечатывался, хотя точней было бы "MSовский" написать, я думаю.

Какой человек? Я про себя говорил.

К>С твоими же опечатками тебя порой "несколько странно" читать.
К>P.S. просто замечание по поводу имхо забавной ситуации.

Ну, без ошибок жизнь была бы скучна.

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

FR>Как будто в машину времени попал

А ты сейчас в каком времени живешь то?

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

R>читал, что мсовский сайт написан на специально заточенном асп, потому что обычный такие нагрузки не выдерживает

Если там что специально и заточено, то только самый низ стека. К статической типизации языка разработки это оношения не имеет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

FR>>Как будто в машину времени попал

VD>А ты сейчас в каком времени живешь то?

Судя по тому что ты выше написал в 2004

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

R>мсовский = ms-овский = microsoft.com

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

К тому же надо понимать, что статический контент проблем с производительностью не создает. А динамический, обычно упирается в СУБД.

VD>>Посещаемость у этих серверов конечно неслабая, но как раз таки в таких условиях скрипты сливают по полной.

R>даже с использованием APC у php? (читал что это кардинально ускоряет работу)

Да хоть с пропеллером и сбоку бантиком.

R>или какой-то прекомпиляции у питона (здесь не в теме)

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

Ты хоть представляешь во что выливаются все эти димамические выкрутасы?

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

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

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

К>Википедия и фейсбук, наверное, безответственные, хотя оспаривать что-либо, учитывая,

Википедия довольно статическое приложение. Страницы в основном показываются, так что можно тупо кэшировать результат.

Но я хорошо помню, как дико тормозила википедия перед тем как ее куплена одним гигантом.

К>что нет аргументов у обоих сторон, смысла нет

Каких аргументов нет? По какому поводу? Кому-то не ясно, что компилируемый код в 10 и более раз быстрее интерпретируемого?

Или кто-то сомневается, что сайты крупных корпораций редко пишут на php?

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

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

FR>Судя по тому что ты выше написал в 2004

Следовательно ты читал года из 1999-го?

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

VD>Каких аргументов нет? По какому поводу? Кому-то не ясно, что компилируемый код в 10 и более раз быстрее интерпретируемого?

ну это понятно

VD>Или кто-то сомневается, что сайты крупных корпораций редко пишут на php?

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

VD>Я же не спорю, что если есть море денег на железо, а задача параллелится или кэшируется, то ее можно решать как угодно экстенсивно.

на самом деле цена железа не так уж высока, если сравнить ее с годовой зарплатой более менее хорошего программиста из страны второго мира в 30K$ в год (про первый мир молчу)
причем, если железо решает задачу тупо/напрямую и сразу, то эффект от работы программиста не факт что будет заметен для очень большого проекта в течение 3-6 месяцев как минимум

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

FR>>Судя по тому что ты выше написал в 2004

VD>Следовательно ты читал года из 1999-го?

Нет я как будто вернулся в 2004.

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

FR>Судя по тому что ты выше написал в 2004

Если серьезно, то что что-то изменилось за последние 50 лет, и компилируемые языки стали медленнее интерпретируемых?

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

R>на самом деле цена железа не так уж высока,

Да? На, дай денег на новый сервер РСДН. Нам много не надо. $40k хватит.

R>если сравнить ее с годовой зарплатой более менее хорошего программиста из страны второго мира в 30K$ в год (про первый мир молчу)

Дык. Железо еще обслуживать надо. Если у нас будет вместо одного сервера 10, то ты заплатишь не за программиста, а за админа. Какая разница?

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

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

Но вот чего точно нет, так это реализации вычислительных задач на скриптах. Это точно абсурд.

R>причем, если железо решает задачу тупо/напрямую и сразу, то эффект от работы программиста не факт что будет заметен для очень большого проекта в течение 3-6 месяцев как минимум

Железо никогда ничего не решает тупо. Чем больше железа тем задача сложнее.
Тот же гугль почему-то на питонах пишет только не очень ответственные части. А движок поиска и т.п. у них на компилируемых языках пишутся.

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

VD>Но вот чего точно нет, так это реализации вычислительных задач на скриптах. Это точно абсурд.

И тем не менее, многие делают расчеты в том же matlab-е.

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

L>И тем не менее, многие делают расчеты в том же matlab-е.

Некоторые еще калькулятором пользуются. Обсудим это?

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

L>>И тем не менее, многие делают расчеты в том же matlab-е.

VD>Некоторые еще калькулятором пользуются.

Для вычислительных задач?!

VD>Обсудим это?

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

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

L>Да не, не стоит, ты уже достаточно продемонстрировал степень владения предметом.

С удовольствием выслушаю развенчание моих слов.

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

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

L>>>И тем не менее, многие делают расчеты в том же matlab-е.

VD>>Некоторые еще калькулятором пользуются.

L>Для вычислительных задач?!

ОК, я забыл что ты у нас намеков не понимаешь. Отвечу в лоб.

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

Достаточно разжевано? Так сможешь понять?

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

L>>Да не, не стоит, ты уже достаточно продемонстрировал степень владения предметом.

VD>С удовольствием выслушаю развенчание моих слов.

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

VD>А вот смотреть на твои понты и то как ты не к месту влезаешь мне не интересно. Ты уж ивини.

На себя сначала посмотри. Мой пост был совершенно нейтральный, в отличие от твоей неадекватной реакции.

VD>Так что если нечего сказать, то проходи не задерживайся.

Шел бы ты сам, родной. Почему-то по скайпу ты себя гораздо сдержаннее ведешь. От "публики" крышу сносит?

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

L>>Для вычислительных задач?!

VD>ОК, я забыл что ты у нас намеков не понимаешь. Отвечу в лоб.

Не надо переходить на личности. Хотя кому я это говорю?!!

VD>Вычислительные задачи — это задачи сильно нагружающие процессор. По своей природе они таковы, что их нельзя закэшировать или упростить. Математика это совсем из другой оперы.

Т.е. математика — это не ычислительные задачи? Жжошь неподеццки.

VD>Достаточно разжевано? Так сможешь понять?

Да я собственно уже все понял. Можешь не продолжать.

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

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

L>Не надо переходить на личности.

Тогда пусть личности со своими странностями держатся по дальше.

L>Хотя кому я это говорю?!!

Да, да. С этим тоже разберись для начала.

L>Т.е. математика — это не ычислительные задачи? Жжошь неподеццки.

Нет — это наука. А за "Жжошь неподеццки" можно и в баньку.

L>Да я собственно уже все понял. Можешь не продолжать.

Ну, вот и славно. Хорошо, что ты у нас понятливый.

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

L>Развенчание чего? Того, что не только на компилируемых языках делают расчеты? Я привел пример матлаба, который достаточно широко используется. Этого недостаточно?

Да ты славишься своей алогичностью мышления. В качестве примера приводишь не язвк программирования.э
В прочем, если не интересует производительность, то несомненно "вычисления" можно производить и на Руби. Только это не будет вычислительной задачей. Это будет некий расчет скорость которого никого не трогает.

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

Тебе это в общем-то известно. Но ты же сюда забежал по другому поводу. Поспорить, по самоутверждаться.

Ну, так как? Ты потешил свое ЧСВ?

L>На себя сначала посмотри.

Я этим почти каждый день занимаюсь.

ЗЫ

Был бы рад, если бы бы забанил меня и не отвечал на мои сообщения. Все равно за последние 10 лет полезной информации от тебя практически не было.

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

L>>Не надо переходить на личности.

VD>Тогда пусть личности со своими странностями держатся по дальше.

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

L>>Хотя кому я это говорю?!!

VD>Да, да. С этим тоже разберись для начала.

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

L>>Т.е. математика — это не ычислительные задачи? Жжошь неподеццки.

VD>Нет — это наука.

И там конечно же нет вычислений, я тебя правильно понимаю?

VD>А за "Жжошь неподеццки" можно и в баньку.

Ох уж чья бы корова...

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

L>>Развенчание чего? Того, что не только на компилируемых языках делают расчеты? Я привел пример матлаба, который достаточно широко используется. Этого недостаточно?

VD>Да ты славишься своей алогичностью мышления.

Тут есть модераторы или где? Может пора уже, господа, умерить распоясовщегося подростка?

VD>В качестве примера приводишь не язвк программирования.э

Блин, Влад, да кончай позориться-то. Ну не видел ты его в глаза, так хоть википедию почитай что-ли.

VD>В прочем, если не интересует производительность, то несомненно "вычисления" можно производить и на Руби. Только это не будет вычислительной задачей. Это будет некий расчет скорость которого никого не трогает.

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

Во-первых, не надо так уж открыто подтасовывать формулировки. Только что были вычислительные задачи, потом выяснилось, что научные вычислительные задачи по каким-то причинам сюда не входят. Теперь уже оказывается речь идет о критичных по времени задачах. Может стоит уже определеиться о чем идет речь?
А во-вторых, я тебе говорю факты, то что видел собственными глазами: вычислительными научными задачами на матлабе вполне анимаются. Про Руби и Питон ничего сказать не могу, не встречал такого в вышеозначенной области.

VD>Тебе это в общем-то известно. Но ты же сюда забежал по другому поводу. Поспорить, по самоутверждаться.

VD>Ну, так как? Ты потешил свое ЧСВ?

По себе судишь. У меня нет такой цели.

L>>На себя сначала посмотри.

VD>Я этим почти каждый день занимаюсь.

VD>ЗЫ

VD>Был бы рад, если бы бы забанил меня и не отвечал на мои сообщения.

Я тебе не доставлю такого удовольствия.

VD>Все равно за последние 10 лет полезной информации от тебя практически не было.

Об этом не тебе судить.

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

FR>>Судя по тому что ты выше написал в 2004

VD>Если серьезно, то что что-то изменилось за последние 50 лет, и компилируемые языки стали медленнее интерпретируемых?
Это он так пытается тролить намекая на то что ты сказал C#, а не немерле.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

S>>Завтра конечно проверю, но я не вижу причин, по которым код выше не будет работать. Отпишусь.

FR>Так на вход же может подаваться любая переменная свободно изменяющаяся в рантайме, без зависимых типов такое не разрулить,

Проверил

Код (комментарии — копипаста из error list window)

  class Program
  {
    static void A(int a)
    {
      Contract.Requires(a > 5);
      Contract.Requires(a < 25);
    }

    static void B(int a, int b)
    {
      Contract.Requires(a < b);
      Contract.Requires(SomeMagic(a - b));
    }

    [Pure]
    static bool SomeMagic(int a)
    {
      return new Random(123).Next() == a;
    }

    [STAThread]
    static void Main(string[] args)
    {
      // CodeContracts: requires unproven: s != null (!!!)
      int b = Int32.Parse(Console.ReadLine());

      if (12 < b && SomeMagic(12 - b))
      {
        B(12, b);  // Здесь сообщения об ошибке не будет!
      }

      // CodeContracts: requires unproven: a < b
      // CodeContracts: requires unproven: SomeMagic(a - b)
      B(12, b);
      
      // CodeContracts: requires is false: a < 25
      A(123);

      Console.ReadKey();
    }
  }

Заметьте, я умудрился лопухнуться в сампле: Console.ReadLine() действительно может вернуть null.

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

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

VD>>Возможно тебя смутило слово "отечественная" — это очепятка исправления орфографии. Имелось в виду "ответственная".

К>Википедия и фейсбук, наверное, безответственные, хотя оспаривать что-либо, учитывая, что нет аргументов у обоих сторон, смысла нет

В фейсбуке используется трансляция PHP исходников в C++ с последующей компиляцией. Подробнее можно почитать тут: http://github.com/facebook/hiphop-php/wiki Иными словами, на бэкенде никаких преимуществ динамических языков они не используют, юзая PHP исключительно как DSL для C++-го (и весьма сурово оптимизированного при этом) кода. Что как бы намекает.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

KV>В фейсбуке используется трансляция PHP исходников в C++ с последующей компиляцией. Подробнее можно почитать тут: http://github.com/facebook/hiphop-php/wiki Иными словами, на бэкенде никаких преимуществ динамических языков они не используют, юзая PHP исключительно как DSL для C++-го (и весьма сурово оптимизированного при этом) кода. Что как бы намекает.

Смотрим на ник автора сообщения

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

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

KV>>В фейсбуке используется трансляция PHP исходников в C++ с последующей компиляцией. Подробнее можно почитать тут: http://github.com/facebook/hiphop-php/wiki Иными словами, на бэкенде никаких преимуществ динамических языков они не используют, юзая PHP исключительно как DSL для C++-го (и весьма сурово оптимизированного при этом) кода. Что как бы намекает.

К>Смотрим на ник автора сообщения

Ну это ж отлично

Так зачем разработчикам FB понадобился подобный инструмент?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

R>читал, что мсовский сайт написан на специально заточенном асп, потому что обычный такие нагрузки не выдерживает
Не читайте советских газет.
Нет там никакого специфически заточенного asp.net-а. Например тот же самый msn.com, который в ходит в пятерку самых нагруженных серверов в мире и имеет порядка 9К хитов в секунду, работает на самом обычном asp.net-е. Другое дело, что там правильно настроенный кластер и закешировано все что можно, но .net там самый обычный.

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>

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

VD>Вычислительные задачи — это задачи сильно нагружающие процессор. По своей природе они таковы, что их нельзя закэшировать или упростить. Математика это совсем из другой оперы.

VD>Достаточно разжевано? Так сможешь понять?

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

Для многих сложных вычислительных задач может быть вполне допустимо, что процессор нагружается "очень сильно" и на несколько дней. И это никого сильно не волнует. При этом, возможно, использование другого средства позволило бы на несколько дней сократить время вычисления, но — это не интересно, т.к. неважно для тех конкретных задач. Несколько дней всех устраивает. Можно считать и на скриптах.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

VD>>Нет никакого московского сайта ни у Microsoft, ни у IBM. Они все живут на корпоративных серверах.
К>Влад, вроде как человек не опечатывался, хотя точней было бы "MSовский" написать, я думаю.

А точно! Я тоже "московский" прочитал.

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

L>Здравствуйте, Курилка, Вы писали:

VD>>>Нет никакого московского сайта ни у Microsoft, ни у IBM. Они все живут на корпоративных серверах.
К>>Влад, вроде как человек не опечатывался, хотя точней было бы "MSовский" написать, я думаю.

L>А точно! Я тоже "московский" прочитал.

Масквичи такие масквичи

On 11.10.2010 17:12, Sinix wrote:

> MZ>Ещё не пришло время. Но перейдут, обязательно перейдут.
> Не уверен.

Верь мне !

> 2. Обновление кода на хостинге сделано ещё во 2м асп.нете.

Где сделано что ? Нипонял.

Posted via RSDN NNTP Server 2.1 beta

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

FR>>>Судя по тому что ты выше написал в 2004

VD>>Если серьезно, то что что-то изменилось за последние 50 лет, и компилируемые языки стали медленнее интерпретируемых?
WH>Это он так пытается тролить намекая на то что ты сказал C#, а не немерле.

Да? Мне даже это в голову не пришло.

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

ВВ>Статически-типизированные языки не подходят для разработки больших проектов, потому что количество кода, которое приходится писать на таких языках, значительно больше, чем количество кода, которое приходится писать на динамически-типизированных языках для решения ровно тех же задач. Т.е. надо писать больше кода, тратить больше времени на "обслуживание" системы типов — по сути подсказки для компилятора, на которых и работает статическая типизация, — и все это вместо того, чтобы сконцетрироваться на основном, на решении своей задачи.

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

ВВ>Вообще интересная ситуация получается. Раз уж так хочется дотнет, возьмем C#. Статически-типизированный язык, да. Вот только что ж людям-то при этом "на месте не сидится"? Постоянно пытаются с этой самой статикой бороться, ценой, естестественно, потери львиной доли проверок на этапе компиляции. Тут вам и рефлекшины всех сортов, и кодогенерация в рантайме, и всяческие IOC-контейнеры с ХМЛ-конфигами (ХМЛ-конфиги, кстати, тоже тема отдельная и благодатная), теперь вот еще dynamic прикрутили. На фига все это? Чем статическая типизация не устраивает? Зачем в язык тащить столько динамики? (А потом еще и тесты писать, ага).
По тому что люди боятся языка на букву N.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

Это неправда. Во-первых, даже самый мощный вывод типов не избавляет нас от необходимости писать объявления этих типов, чего в случае с динамической типизацией вообще можно избежать.
Во-вторых, вывод типов тоже даром не дается. Тут либо как в Немерле, где глобального вывода типов нет и соответственно код никак не может быть таким же лаконичным, как в динамическом языке. Либо как в F#, где приходится вводить разные ограничения для обеспечения работы вывода типов — и по факту занимаешься тем, что пытаешься этот самый вывод типов не поломать.
До динамики далеко однако.

ВВ>>Вообще интересная ситуация получается. Раз уж так хочется дотнет, возьмем C#. Статически-типизированный язык, да. Вот только что ж людям-то при этом "на месте не сидится"? Постоянно пытаются с этой самой статикой бороться, ценой, естестественно, потери львиной доли проверок на этапе компиляции. Тут вам и рефлекшины всех сортов, и кодогенерация в рантайме, и всяческие IOC-контейнеры с ХМЛ-конфигами (ХМЛ-конфиги, кстати, тоже тема отдельная и благодатная), теперь вот еще dynamic прикрутили. На фига все это? Чем статическая типизация не устраивает? Зачем в язык тащить столько динамики? (А потом еще и тесты писать, ага).
WH>По тому что люди боятся языка на букву N.

И причем тут Немерле?

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

ВВ>Это неправда. Во-первых, даже самый мощный вывод типов не избавляет нас от необходимости писать объявления этих типов, чего в случае с динамической типизацией вообще можно избежать.
http://docs.python.org/tutorial/classes.html

ВВ>Во-вторых, вывод типов тоже даром не дается. Тут либо как в Немерле, где глобального вывода типов нет и соответственно код никак не может быть таким же лаконичным, как в динамическом языке.
В немерле можно сделать глобальный вывод типов.
Но есть две проблемы:
1)Делать интерфейс класса зависимым от реализации плохая идея.
2)Время компиляции увеличится.

ВВ>Либо как в F#, где приходится вводить разные ограничения для обеспечения работы вывода типов — и по факту занимаешься тем, что пытаешься этот самый вывод типов не поломать.
Это от того что его авторы пытались натянуть систему типов окамла на .НЕТ. Не удивительно что у них полная фигня получилась.

ВВ>До динамики далеко однако.
Вот только по факту получается что не только не далеко но порой и короче получается.
Попробуй ка вот такое на питоне изобразить: http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/LRPEGCC/Optimizer.OptimizeRule.n
Кстати я сейчас думаю над алгоритмом вывода типов при помощи котрого можно будет извести все "Rule."
Кстати посчитай "оверхед" от типов в этом коде.

ВВ>И причем тут Немерле?

При том что перечисленная байда в немерле не нужна.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ВВ>>Это неправда. Во-первых, даже самый мощный вывод типов не избавляет нас от необходимости писать объявления этих типов, чего в случае с динамической типизацией вообще можно избежать.
WH>http://docs.python.org/tutorial/classes.html

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

ВВ>>До динамики далеко однако.
WH>Вот только по факту получается что не только не далеко но порой и короче получается.
WH>Попробуй ка вот такое на питоне изобразить: http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/LRPEGCC/Optimizer.OptimizeRule.n
WH>Кстати я сейчас думаю над алгоритмом вывода типов при помощи котрого можно будет извести все "Rule."
WH>Кстати посчитай "оверхед" от типов в этом коде.

Хитер.

Ну ты покажи код, в котором используемые по ссылке типы объявляются, я посчитаю. А так-то что считать.

ВВ>>И причем тут Немерле?

WH>При том что перечисленная байда в немерле не нужна.

Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить. Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь

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

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

KV>Ну, а википедия пошла по пути наращивания мощностей как средства борьбы с падением производительности, тут вообще странно рассуждать о преимуществе тех или иных языков

В mediawiki очень специфичная нагрузка. Объем правок не такой уж огромный, а при выводе страниц просто отдается уже готовый файл с диска.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Либо как в F#, где приходится вводить разные ограничения для обеспечения работы вывода типов — и по факту занимаешься тем, что пытаешься этот самый вывод типов не поломать.
WH>Это от того что его авторы пытались натянуть систему типов окамла на .НЕТ. Не удивительно что у них полная фигня получилась.

Натянуть у них да не получилось, они очень многое выкинули из системы типов OCaml'а.
Корявостей конечно прилично, но полной фигней не назовешь и кое-что я бы не отказался забрать из F# обратно в OCaml.

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

ВВ>Я уже говорил, еще раз повторю. Мы какие-то конкретные языки сравниваем? Питон и Немерле? И почему именно Питон? Давай уж Схему тогда, оно как-то ближе к телу.

Лучше Pure http://code.google.com/p/pure-lang/ да и Dylan http://www.opendylan.org/ тоже подойдет.

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

VD>Если серьезно, то что что-то изменилось за последние 50 лет, и компилируемые языки стали медленнее интерпретируемых?

Нет все также, и даже языки с JIT и виртуальными машинами так и не догнали нативные компиляторы

Но те же Лисп, Smalltalk с компанией показали что динамические языки не обязательно должны интерпретироваться, они вполне
неплохо компилируются и JIT'ся, результат конечно уступает лучшим статическим компиляторам, но вполне неплох.
Эрланг и луа уже добились определенных успехов.
У питона с руби это сделать пока не получилось, просто нужны ресурсы как в свое время для Smalltalk'а. Тот же PyPy
продемонстрировал что в принципе все возможно.

Ну и про вычисления, вот эта http://www.scipy.org/ библиотека для питона весьма популярна и как раз предназначена для
тяжелых расчетов, все конечно просто питон тут по сути просто управляет нативным высокооптимизированным кодом который все
и считает, и это вполне работает, даже существует целая группа языков — APL семейство (J, K) которые и построены на этом
принципе — на интерпретаторе только очень высокий уровень, и они вполне быстрые.

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

F>Недостаточно. Чтобы получилось то, что ты имеешь в виду надо еще добавить — что при этом ограничено время, в течение которого должен быть получен результат.

Это само собой разумеется. Но нельзя же объяснять любой термин от печки?

F>Для многих сложных вычислительных задач может быть вполне допустимо, что процессор нагружается "очень сильно" и на несколько дней. И это никого сильно не волнует. При этом, возможно, использование другого средства позволило бы на несколько дней сократить время вычисления, но — это не интересно, т.к. неважно для тех конкретных задач. Несколько дней всех устраивает. Можно считать и на скриптах.

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

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

Время всегда актуально. Вопрос только насколько.

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

FR>Нет все также, и даже языки с JIT и виртуальными машинами так и не догнали нативные компиляторы

Практически догнали. Разницу обычно в микроскоп не видно, а при сравнении со специализированными решениями (расчеты на базе GPU, например) эта разница и вовсе выглядит смешной.

FR>Но те же Лисп, Smalltalk с компанией показали что динамические языки не обязательно должны интерпретироваться, они вполне неплохо компилируются и JIT'ся, результат конечно уступает лучшим статическим компиляторам, но вполне неплох.

Этот миф появилась куда раньше 2004-го года. Я уже думал, что его перестали распространять.

FR>Эрланг и луа уже добились определенных успехов.

Ничего они не добились. Тут не раз приводили числодробильные тесты на которых они сливали по полной программе. В прочем как и Смолтолк (он еще жив, кстати?).

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

FR>У питона с руби это сделать пока не получилось, просто нужны ресурсы как в свое время для Smalltalk'а. Тот же PyPy
FR>продемонстрировал что в принципе все возможно.

Тешь себя надеждами и дальше. Только вот не надо сказок, что что-то там получилось для Smalltalk.

Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

FR>Ну и про вычисления, вот эта http://www.scipy.org/ библиотека для питона весьма популярна и как раз предназначена для тяжелых расчетов,

Охотно верю. Только причем тут Питон? Эта библиотека наверняка написана на Си или Фортране. И может она только то, что в нее заложили авторы. Все остальное придется писать и запускать на Питоне, что как ты сам понимаешь каюк для производительности.

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

VD>Практически догнали. Разницу обычно в микроскоп не видно, а при сравнении со специализированными решениями (расчеты на базе GPU, например) эта разница и вовсе выглядит смешной.

Разница практически осталась как пять лет назад, а обещали перегнать.

FR>>Но те же Лисп, Smalltalk с компанией показали что динамические языки не обязательно должны интерпретироваться, они вполне неплохо компилируются и JIT'ся, результат конечно уступает лучшим статическим компиляторам, но вполне неплох.

VD>Этот миф появилась куда раньше 2004-го года. Я уже думал, что его перестали распространять.

Это не миф, у лиспа например большинство реализаций компиляторы.

FR>>Эрланг и луа уже добились определенных успехов.

VD>Ничего они не добились. Тут не раз приводили числодробильные тесты на которых они сливали по полной программе. В прочем как и Смолтолк (он еще жив, кстати?).

Добились существенного ускорения, на мировое господство не претендовали.

VD>Тешь себя надеждами и дальше. Только вот не надо сказок, что что-то там получилось для Smalltalk.

Меня вполне устраивает даже существующая производительность питона.

VD>Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

Smalltalk'еры похоже совсем вымерли

FR>>Ну и про вычисления, вот эта http://www.scipy.org/ библиотека для питона весьма популярна и как раз предназначена для тяжелых расчетов,

VD>Охотно верю. Только причем тут Питон? Эта библиотека наверняка написана на Си или Фортране.

Так людям пофиг на шашечки им ехать надо.

VD>И может она только то, что в нее заложили авторы. Все остальное придется писать и запускать на Питоне, что как ты сам понимаешь каюк для производительности.

Перепишут этот кусок на си, или Cython

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

VD>Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

iZEN>>Mono на сервере? Только в страшном сне.

AVK>Знаю не одну работающую инсталляцию. ВРоде бы неизлечимых проблем нет. А что не так?

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

iZEN>>http://www.linux.org.ru/news/opensource/5414839/page-1

AVK>И? Я должен просмотреть лоровский пердеж чтобы понять, что ты сказать хотел?

См. выше.

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

ZEN>И я не знаю и не слышал (от тебя — услышал впервые). Может ссылочек подбросишь

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

AVK>>И? Я должен просмотреть лоровский пердеж чтобы понять, что ты сказать хотел?

ZEN>См. выше.

Посмотрел. Все равно непонятно, что ты этой ссылкой сказать хотел.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

FR>Разница практически осталась как пять лет назад, а обещали перегнать.

В этом направлении никто особо пока не работал всерьез. Есть шанс, что кое что будет в CLR 5, но это пока только планы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

FR>Разница практически осталась как пять лет назад, а обещали перегнать.

Кто обещал что в течении пяти лет? Да и есть объективные причины которые не дают достичь 100%.

VD>>Этот миф появилась куда раньше 2004-го года. Я уже думал, что его перестали распространять.
FR>Это не миф, у лиспа например большинство реализаций компиляторы.

Это миф и я сам его проверил.

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

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

Неа. Это всего лишь оптимизация. CPython прекрасно умеет работать без pyc-файлов.

Для этого надо всего-навсего выставить простую и интуитивно понятную переменную окружения: PYTHONDONTWRITEBYTECODE (в самом Питоне доступна как sys.dont_write_bytecode)

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

VD>>Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

FR>Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

Не уловил связи.

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

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

VD>>Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

FR>Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

Кстати, о птичках. Забавная цитата от туда по поводу джит-языков:

The C++ version is a little bit faster than the RPython version translated to C, at 750'000 chars/s. That's not very surprising, given their similarity. The Java version is more than twice as fast, with 1'920'000 chars/s.

То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

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

VD>>>Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

FR>>Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

VD>Не уловил связи.

Пожалй пояснию. Не уловил связи межу скоростью интерпретаторов и скоросью статических языков с джит-компиляцией (к которым относится RPython (сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей (с) Википедия)). К тому же RPython-овский код был напичкан жуткими хинтами для джита.

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

VD>Кстати, о птичках. Забавная цитата от туда по поводу джит-языков:
VD>

VD>The C++ version is a little bit faster than the RPython version translated to C, at 750'000 chars/s. That's not very surprising, given their similarity. The Java version is more than twice as fast, with 1'920'000 chars/s.

VD>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

А дальше что? Нашли причину или так и остались в непонятках?

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

AVK>>Думаю, да. Миллионы леммингов и не такое вытворяют. Достаточно вспомнить, что основу динамики в вебе составляют не django и ror, а кривокосоглазый php.
D>Причина не в леммингах, а в том что php на десять лет старше, пройдет еще десяток и ror будет таким же кривоглазым по сравнению например с каким нибудь nor.

Вы сравниваете свиней с апельсинами, сравнивая PHP с ROR. Первое — язык, второе — фреймворк под другой язык. Сравните PHP с Ruby, а ROR с чем-то другим (не разбираюсь до такой степени), но именно фреймворком для веба.

Причина же распространения PHP именно в леммингах. PHP формально даёт очень низкий порог вхождения: хочешь добавить кусок динамики — вставь <?php ... ?> в статическую страницу и готово. И именно это рекламировалось в первых версиях, когда он набирал силу. Но даже это не страшно — это могло привести и к разумному результату. Но не привело — получили несистемную, дурную кашу из множества подходов, с отсутствием единообразия практически в каждой подсистеме и на каждом уровне, с отсутствием качественной структуризации, с отсутствием поддержки безопасной работы — наоборот, шуточки вроде XSS провоцируются всем стилем PHP... сейчас легче выбросить и взять другое, чем приводить PHP к уму и здравому смыслу.

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

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

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

C>Неа. Это всего лишь оптимизация. CPython прекрасно умеет работать без pyc-файлов.

Я говорю о байт-коде в целом, а не о его конкретном представлении (в виде файла).

C>Для этого надо всего-навсего выставить простую и интуитивно понятную переменную окружения: PYTHONDONTWRITEBYTECODE (в самом Питоне доступна как sys.dont_write_bytecode)

Нет. Он умеет не кэшировать байт-код в pyc-файлы, но создает его всегда, т.к. среда исполнения умеет выполнять только его.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

ВВ>Хитер.

Ну ты покажи код, в котором используемые по ссылке типы объявляются, я посчитаю. А так-то что считать.
Оверхед в коде.
Его НЕТ.

ВВ>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить.
Я не пытаюсь лечить динамику.
Эту ошибку природы личить не имеет смысла.

ВВ>Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь

. И вывод типов по большому счету ей ортогонален. Динамика — это прежде всего возможности самой системы типов, которая, благодаря позднему связыванию, обладает просто чудовищной гибкостью, на статически-типизированном языке недостижимой.
Бред!
Макры + вывод типов зарулят всю твою динамику в минуса.

ВВ>Естественно, ничто не бывает бесплатным, и за гибкость приходится платить.
Ага... платить дохрена (тормоза и баги) а выгоды по сравнению с правильными статически типизированными языками никакой.

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

Ручной рефакторинг тоже проблема.
Что-то поменял и что дальше?
Статически типизируемый язык покажет кучу мест где нужно поправить.
А что делать с динамически типизируемым?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>Ручной рефакторинг тоже проблема.
WH>Что-то поменял и что дальше?
WH>Статически типизируемый язык покажет кучу мест где нужно поправить.
WH>А что делать с динамически типизируемым?

Тесты же.

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

WH>>Ручной рефакторинг тоже проблема.
WH>>Что-то поменял и что дальше?
WH>>Статически типизируемый язык покажет кучу мест где нужно поправить.
WH>>А что делать с динамически типизируемым?
L>Тесты же.
Что тесты? Они и близко не так эффективны как компилятор.
Ибо компилятор гарантированно заглянет во все уголки кода.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

WH>>>Ручной рефакторинг тоже проблема.
WH>>>Что-то поменял и что дальше?
WH>>>Статически типизируемый язык покажет кучу мест где нужно поправить.
WH>>>А что делать с динамически типизируемым?
L>>Тесты же.
WH>Что тесты? Они и близко не так эффективны как компилятор.
WH>Ибо компилятор гарантированно заглянет во все уголки кода.

Моя практика показывает, что тестов достаточно. Разумеется, если они грамотно построены (вот это уже совершенно неформализуемый признак).

ВВ>>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить.
WH>Я не пытаюсь лечить динамику.
WH>Эту ошибку природы личить не имеет смысла.

В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.

FR>>Но те же Лисп, Smalltalk с компанией показали что динамические языки не обязательно должны интерпретироваться, они вполне неплохо компилируются и JIT'ся, результат конечно уступает лучшим статическим компиляторам, но вполне неплох.
VD>Этот миф появилась куда раньше 2004-го года. Я уже думал, что его перестали распространять.
FR>>Эрланг и луа уже добились определенных успехов.
VD>Ничего они не добились. Тут не раз приводили числодробильные тесты на которых они сливали по полной программе.

А никто и не собирается их исопльзовать для числодробления

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

KV>Ну, а википедия пошла по пути наращивания мощностей как средства борьбы с падением производительности, тут вообще странно рассуждать о преимуществе тех или иных языков

Более того, мобильная версия википеиди на RoR 0_O Пару раз нарывался на ошибки при загрузке. Вот зачем им RoR для этго понадобился, вообще вне моего понимания.

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

FR>>Разница практически осталась как пять лет назад, а обещали перегнать.

AVK>В этом направлении никто особо пока не работал всерьез. Есть шанс, что кое что будет в CLR 5, но это пока только планы.

Ну явщики только этим и занимались.

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

VD>>>Если получилось, то просьба привести результаты для какого-нить альфа-блэндинга.

FR>>Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

VD>Не уловил связи.

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

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

VD>Кто обещал что в течении пяти лет? Да и есть объективные причины которые не дают достичь 100%.

Ну были голоса что будет только одно ~~телевидение~~ NET вокруг, а натив только в песочнице для легаси.

FR>>Это не миф, у лиспа например большинство реализаций компиляторы.

VD>Это миф и я сам его проверил.

Понятно компиляторы лиспа и схемы мне приснились.

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

VD>Кстати, о птичках. Забавная цитата от туда по поводу джит-языков:
VD>

VD>The C++ version is a little bit faster than the RPython version translated to C, at 750'000 chars/s. That's not very surprising, given their similarity. The Java version is more than twice as fast, with 1'920'000 chars/s.

VD>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

Там и си версия есть (Python re module) она шустрее явы.

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

VD>>Не уловил связи.

VD>Пожалй пояснию. Не уловил связи межу скоростью интерпретаторов и скоросью статических языков с джит-компиляцией (к которым относится RPython (сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей (с) Википедия)). К тому же RPython-овский код был напичкан жуткими хинтами для джита.

Так питон почти однозначно транслируется в RPython.

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

AVK>>В этом направлении никто особо пока не работал всерьез. Есть шанс, что кое что будет в CLR 5, но это пока только планы.

FR>Ну явщики только этим и занимались.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

FR>Так питон почти однозначно транслируется в RPython.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

WH>А если вспомнить про рефакторинг... я вообще не представляю как рефакторить без статической типизации.
WH>Автоматический рефакторинг для динамики сделать нельзя. Вообще никак. В лучшем случае получится что-то типа текстовой замены когда одно имя заменяется сразу во всей программе.

Угу при этом слово рефакторинг придумали Smalltalk разработчики.

Кстати рефакторинг в питоне все-таки появился, года три назад он практически отсутствовал, я недавно смотрел питоные IDE
хоть он и не идеален, но по моему уже лучше чем в C++. Кроме IDE вот эта http://rope.sourceforge.net/ библиотека тоже весьма неплоха.

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

VD>>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

N>А дальше что? Нашли причину или так и остались в непонятках?

Дык это не я же эту статью писал. Откуда я занаю. Но факт остается фактом даже не стремясь можно получить более быструю реализацию на яве нежели на С++.

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

ЗЫ

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

Далее выясняется еще более интересные факты. Оказывается, что это даже не JIT-компиляция RPython, а какое-то в доску рукопашно оптимизированное решение для конкретных целей.

Далее становится еще интереснее, так как сравнивают они его с универсальными библиотеками регулярных выражений которые сильно отличаются от сравниваемого решения. Так сравниваемое решение делате только сопоставление, в то время как универсальные библиотеки позволяет разбирать сопоставляемые фрагменты. Как человек вдоволь назанимавшися парсерами могу четко сказать, что разбор сматченых фрагментов занимает очень много времени. Кроме того универсальные библиотеки поддреживают расширения вроде обратных ссылок, что делает их алгоритм отличным от сравнивамого. В доврешение всего универсальные библоитеки являются интрпретаторами регулярных выражений, а не компилируют их. Собственно авторы открытр говорят об всем этом.

Так что как не крути это еще одна попытка выдать сказки за чудесную действительность.
Я уже устал повторять. Чудес не бывает. Скрипты дико медленны и могу использоваться только как клей для компонентов созданных на более быстрых средствах разрабоки. Компиляция скриптов конечно может несколько их ускорить, но в общем случае это ускорение не будет очень значительным в следствии динамической природы самих язков.
Так что пора прекратить рассказывать сказки о шустрости скриптов.

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

AVK>Оптимизацией JVM для числодробилок? Можно ссылочку на масштабные проекты? А то там вроде бы даже поддержки векторных расширений процессоров в пользовательских высислениях до сих пор нет, я уж не говорю о таких изысках как generic арифметика.

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

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

M>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
Демагогия. Аппеляция к общественному мнению.
По существу есть что сказать?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

FR>Почему вычисления

Ну этот тред вроде бы о применении динамики в числодробилках.

FR> они вроде прилично подтянули GC и оптимизацию использования стека, это гораздо больше просаживает чем кодогенератор.

Смотря что.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

C>>Для этого надо всего-навсего выставить простую и интуитивно понятную переменную окружения: PYTHONDONTWRITEBYTECODE (в самом Питоне доступна как sys.dont_write_bytecode)

KV>Нет. Он умеет не кэшировать байт-код в pyc-файлы, но создает его всегда, т.к. среда исполнения умеет выполнять только его.
Это уже детали реализации.

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

FR>>Так питон почти однозначно транслируется в RPython.

AVK>Не знаю что там куда транслируется, но сабсет RPython статически типизирован и как то странно приводить его в защиту динамических языков.

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

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

VD>>Ничего они не добились. Тут не раз приводили числодробильные тесты на которых они сливали по полной программе.

M>А никто и не собирается их исопльзовать для числодробления

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

M>Как бы есть еще толпа задач, кроме числодробления. И никто не мешает подключить библиотеку на С, если числодробилка вдруг понадобится.

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

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

И тут мы приходим к теме данного обсуждения и понимаем, что ложна сама посылка. Распространены как скрипты, так и типобезопасные компилируемые языки. Вот С/С++ в данном сегменте действительно не распространен, так как с одной стороны писать на нем тяжело, а с другой добиться надежной работы программы существенно сложнее.

M>А на каких-гибудь нечислодробилках тот же Erlang спокойно работает на уровне того же С

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

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

FR>Цель проекта PyPy исполнять питон код без изменений но существенно быстрей чем интерпретатором, трансляция в RPython средство этого добиться.

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

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

Не будет. Но надо отдавать себе отчет, что это гибридное решение. Вон, С#4 весь компилируется, но это не мешает в нем писать динамический код. С соответствующими потерями перформанса, разумеется.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

FR>>Почему вычисления

AVK>Ну этот тред вроде бы о применении динамики в числодробилках.

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

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

FR>Угу при этом слово рефакторинг придумали Smalltalk разработчики.
Только их "рефакторинг" тупо переименовывал все вхождения имени в программе.
Сравни с решарпером который может переименовать один из перегруженных методов.

FR>Кстати рефакторинг в питоне все-таки появился, года три назад он практически отсутствовал, я недавно смотрел питоные IDE
Могут ли они надежно переименовать метод класса при условии что есть другой класс с таким же методом?
Или они одно имя меняют на другое по всей программе?

FR>хоть он и не идеален, но по моему уже лучше чем в C++.
Нашол блин с чем сравнивать.
Сравни с явой или шарпом.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

FR>Но как клей для нативных библиотек вполне пригодны
FR>и используются.

С этим кто то здесь спорит?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

AVK>Отлично. Но речь то не о питоне, а о динамике. И то, что пипи компилирует реально, это никакая не динамика, а самая натуральная статика, пусть и с выводом типов кое где. Поэтому пипи как аргумент работает именно в защиту статически типизированных языков.

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

AVK>Не будет. Но надо отдавать себе отчет, что это гибридное решение. Вон, С#4 весь компилируется, но это не мешает в нем писать динамический код. С соответствующими потерями перформанса, разумеется.

Возможно в будущем и будут рулить гибриды.

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

FR>>Но как клей для нативных библиотек вполне пригодны
FR>>и используются.

AVK>С этим кто то здесь спорит?

Влад.

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

AVK>>С этим кто то здесь спорит?

FR>Влад.

Не заметил.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

FR>>>Вот http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

VD>>Не уловил связи.

FR>Так питон всех обогнал, притом на задаче требующей больших вычислительных ресурсов.

Да ну? Где ж там Питон то?

Нельзя же так нагло и беспардонно лгать в глаза?!

Код там написан на RPython. Вот что про него пишут в Википедии:

RPython[70] — созданная в рамках проекта PyPy сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей. RPython код можно компилировать во множество других языков/платформ — C, JavaScript, Lisp,

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

Потом там идет какая-то трехэтажная химия с джитом. Так что назвать это JIT-компиляцией скрипта никак нельзя. Там имеет место JIT-компиляция языка регулярных выражений. А скорость работы самого Питона там берется за пяденицу. И она на порядки медленнее чем любая другая реализация.

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

FR>Ну были голоса что будет только одно ~~телевидение~~ NET вокруг, а натив только в песочнице для легаси.

Ну, найди ссылку, тогда обсудим. А пока оставим эти инсинуации.

FR>>>Это не миф, у лиспа например большинство реализаций компиляторы.

VD>>Это миф и я сам его проверил.

FR>Понятно компиляторы лиспа и схемы мне приснились.

Ты опять перевираешь чужие слова. Миф — это скорость получаемого кода. Я видел этот код (машинный). Он далек о того что может сделать даже дотнет с Явой. О сравнении его с хорошими оптимизирующими компиляторами С даже речи идти не может.

К тому же пересометрия в этой области обычно проводится на примитивных примерах где в основном присутствует простенькая целочисленная арифметика. А вот когда дело доходит до компиляции реальных лисповских приложений, то как и в случае со Смотоком, все становится куда печальнее. Динамика есть динамика. Она всегда накладывает свой след. Получать быстрый код в общем случае не представляется возможным. Можно говорить только о его ускорении по сравнению с интерпретацией.

Так что кончай повторять эту ересь в сотый раз. Право, надоело.

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

FR>Там и си версия есть (Python re module) она шустрее явы.

Не надо нести пургу. Ты хотя бы почитал то на что даешь ссылку:

The lesson from these posts is not that you can or should write a practical and general regular expression module in this way – indeed, enhancing the algorithm to support more features of the re module would be a lot of work and it is also unclear what the speed results for more realistic regular expressions would be. However, it makes for a great case study of the JIT generator.

В прочем, убедил. Отныне мы будем считать, что Питон самый быстрый язык на свете (просто потому, что ты так хочешь). За ним идет Ява. Далее С++. А самый медленный язык это, конечно же, С.

Доволен? Такой маразм тебя устраивает.

ЗЫ

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

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

VD>>Пожалй пояснию. Не уловил связи межу скоростью интерпретаторов и скоросью статических языков с джит-компиляцией (к которым относится RPython (сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей (с) Википедия)). К тому же RPython-овский код был напичкан жуткими хинтами для джита.

FR>Так питон почти однозначно транслируется в RPython.

Ты читать то умеешь? Я же приводил тебе ссылку на Википедию.
Или тебе нужно основные мысли написанного выделить? ОК, пожалуйста:

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

Какой это на хрен Питон? Тогда С — это тоже питон, но с указателями и скобочками вместо отступов.

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

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

FR>>Угу при этом слово рефакторинг придумали Smalltalk разработчики.
WH>Только их "рефакторинг" тупо переименовывал все вхождения имени в программе.
WH>Сравни с решарпером который может переименовать один из перегруженных методов.

Это было тогда сейчас в Smalltalk автоматический рефакторинг.

FR>>Кстати рефакторинг в питоне все-таки появился, года три назад он практически отсутствовал, я недавно смотрел питоные IDE
WH>Могут ли они надежно переименовать метод класса при условии что есть другой класс с таким же методом?
WH>Или они одно имя меняют на другое по всей программе?

Используется статическое AST http://rope.sourceforge.net/overview.html#static-object-inference
плюс динамически построенный http://rope.sourceforge.net/overview.html#dynamic-object-analysis

Другой подход по сути вывод типов
http://pystructure.ifs.hsr.ch/trac/
http://pystructure.ifs.hsr.ch/doc/thesis.pdf

FR>>хоть он и не идеален, но по моему уже лучше чем в C++.
WH>Нашол блин с чем сравнивать.
WH>Сравни с явой или шарпом.

Так раньше и такого не было, прогресс весьма существенный.

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

FR>Там и си версия есть (Python re module) она шустрее явы.

С-версия там действительно есть. Только это "re module" — это не она. "re module" — это использование универсальной библиотеки. А вот реализация того же алгоритма полученная трансляцией RPython в С дала 720 килобайт в секунду, что почти в три раза медленнее аналогичной реализации на Яве (1 920 КБ/сек.).

Так что опять лож.

Скажи, тебе просто нравится врать и троллить? Зачем ты этим занимаешься?

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

VD>Да ну? Где ж там Питон то?

Ну будет

VD>Нельзя же так нагло и беспардонно лгать в глаза?!

Нужно иначе не дадут денег.

VD>Код там написан на RPython. Вот что про него пишут в Википедии:
VD>

VD>RPython[70] — созданная в рамках проекта PyPy сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей. RPython код можно компилировать во множество других языков/платформ — C, JavaScript, Lisp,

VD>Так что никакими скриптами тут и не пахнет. Мы имеем дело с языком который мало чем отличается от С. Разве что ли более ограниченный, так как с указателями не позволяет работать.

VD>Потом там идет какая-то трехэтажная химия с джитом. Так что назвать это JIT-компиляцией скрипта никак нельзя. Там имеет место JIT-компиляция языка регулярных выражений. А скорость работы самого Питона там берется за пяденицу. И она на порядки медленнее чем любая другая реализация.

Зато хорошо показали светлое будущее

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

VD>>Нельзя же так нагло и беспардонно лгать в глаза?!

FR>Нужно иначе не дадут денег.

Надо завести значок "Троллю!".

FR>Зато хорошо показали светлое будущее

Это конечно офигительный корм для тролей. Но вот показать этот материал ничего не может. Точнее он как раз показывает то что есть.

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

FR>Это было тогда сейчас в Smalltalk автоматический рефакторинг.
Что ты под автоматическим рефакторингом подразумеваешь?
Может ли он вот это:

WH>>Могут ли они надежно переименовать метод класса при условии что есть другой класс с таким же методом?

FR>Используется статическое AST http://rope.sourceforge.net/overview.html#static-object-inference
FR>плюс динамически построенный http://rope.sourceforge.net/overview.html#dynamic-object-analysis
Просто шикарно

PyCore.run_module() runs a module and collects object information if perform_doa project config is set. Since as the program runs rope gathers type information, the program runs much slower. After the program is run, you can get better code assists and some of the refactorings perform much better.

А если выполнение не зашло в нужный нам уголок кода?

FR>http://pystructure.ifs.hsr.ch/doc/thesis.pdf
Это я еще почитаю но в чудеса я не верю.

FR>Так раньше и такого не было, прогресс весьма существенный.
Короче все ясно.
Глюкодром.
Рефактори что попало и где угодно.
Вместо того что надо.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VD>Ну, найди ссылку, тогда обсудим. А пока оставим эти инсинуации.

Лень искать, но флейм был пока longhorn пости полностью не урезали.

FR>>Понятно компиляторы лиспа и схемы мне приснились.

VD>Ты опять перевираешь чужие слова. Миф — это скорость получаемого кода. Я видел этот код (машинный). Он далек о того что может сделать даже дотнет с Явой. О сравнении его с хорошими оптимизирующими компиляторами С даже речи идти не может.

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

VD>К тому же пересометрия в этой области обычно проводится на примитивных примерах где в основном присутствует простенькая целочисленная арифметика. А вот когда дело доходит до компиляции реальных лисповских приложений, то как и в случае со Смотоком, все становится куда печальнее. Динамика есть динамика. Она всегда накладывает свой след. Получать быстрый код в общем случае не представляется возможным. Можно говорить только о его ускорении по сравнению с интерпретацией.

Со схемой не так печально, хотя тоже конечно медленнее статики.

VD>Так что кончай повторять эту ересь в сотый раз. Право, надоело.

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

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

FR>>Так питон почти однозначно транслируется в RPython.

VD>Ты читать то умеешь? Я же приводил тебе ссылку на Википедию.
VD>Или тебе нужно основные мысли написанного выделить? ОК, пожалуйста:
VD>

VD>RPython ... сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей.

VD>Какой это на хрен Питон? Тогда С — это тоже питон, но с указателями и скобочками вместо отступов.

А ассемблер в который транслируется в конечном счете все это шарп но без классов.
Какая разница во что транслируется питон.

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

VD>Надо завести значок "Троллю!".

Обязательно. Только выдавать его голосованием, не исключая модераторов.

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

VD>Так что как не крути это еще одна попытка выдать сказки за чудесную действительность.
VD>Я уже устал повторять. Чудес не бывает. Скрипты дико медленны и могу использоваться только как клей для компонентов созданных на более быстрых средствах разрабоки. Компиляция скриптов конечно может несколько их ускорить, но в общем случае это ускорение не будет очень значительным в следствии динамической природы самих язков.

Ты хочешь сказать, что если динамический язык компилируется, а не интерпретируется, то это не дает значительного ускорения?

M>>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
WH>Демагогия. Аппеляция к общественному мнению.
WH>По существу есть что сказать?

1. Не демагогия, а факт
2. Куда еще более по сушеству? Людям, которые разрабатывают системы для телекома, важнее динамика, а не мифические бенефиты от статики.

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

FR>Никакой ереси ты просто не читаешь что я пишу и споришь с виртуальным собеседником.

А кто же это все пишет то?

FR>И вообще я в последнее время стал мирным малоспорящим и скромным человеком

Ага. Такой тихий, мирный троленок

.

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

FR>Какая разница во что транслируется питон.

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

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

FR>Обязательно. Только выдавать его голосованием, не исключая модераторов.

Зачем? Достаточно чтобы тот кто хочет потраолить мог его указать. Чтобы окружающие не дергались.

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

ВВ>Ты хочешь сказать, что если динамический язык компилируется, а не интерпретируется, то это не дает значительного ускорения?

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

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

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

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

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

ВВ>>Хитер.

Ну ты покажи код, в котором используемые по ссылке типы объявляются, я посчитаю. А так-то что считать.
WH>Оверхед в коде.
WH>Его НЕТ.

А объявления классов, вариантов и проч. это уже не код? Удобно.

ВВ>>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить.
WH>Я не пытаюсь лечить динамику.
WH>Эту ошибку природы личить не имеет смысла.

Понятно. Только начали беседовать — уже религиозные лозунги.
У меня уже начинает складываться впечатление, что у всех немерлистов есть строгая и неоспоримая позиция по всем, так сказать, вопросам жизни и смерти. А несогласие с этой позицией воспринимается чуть ли не как личное оскорбление. Надеюсь, это не заразно.

Кстати, пользуясь случаем, хотел бы спросить: что лучше — Кока-Кола или Пепси-Кола? А то я все как-то не решу

ВВ>>Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь

. И вывод типов по большому счету ей ортогонален. Динамика — это прежде всего возможности самой системы типов, которая, благодаря позднему связыванию, обладает просто чудовищной гибкостью, на статически-типизированном языке недостижимой.
WH>Бред!
WH>Макры + вывод типов зарулят всю твою динамику в минуса.

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

А зарулить динамику невозможно в принципе. Динамика позволяет программисту делать любые допущения о типах на этапе создания программы. *Любые*.

ВВ>>Естественно, ничто не бывает бесплатным, и за гибкость приходится платить.
WH>Ага... платить дохрена (тормоза и баги) а выгоды по сравнению с правильными статически типизированными языками никакой.

Как объяснишь феномен людей, которые с удовольствием пишут на динамических и статических языках? При этом в числе последних могут быть и весьма мощные языки. FR, если я не путаю, пишет на Питоне и OCaml.
Впрочем, что я спрашиваю "как объяснишь". Наверняка в ответ будет что-нибудь нецензурное.

WH>А если вспомнить про рефакторинг... я вообще не представляю как рефакторить без статической типизации.
WH>Автоматический рефакторинг для динамики сделать нельзя. Вообще никак. В лучшем случае получится что-то типа текстовой замены когда одно имя заменяется сразу во всей программе.
WH>А перегрузка? А методы в разных классах?...
WH>Ручной рефакторинг тоже проблема.
WH>Что-то поменял и что дальше?
WH>Статически типизируемый язык покажет кучу мест где нужно поправить.
WH>А что делать с динамически типизируемым?

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

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

VD>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Ты хочешь сказать, что если динамический язык компилируется, а не интерпретируется, то это не дает значительного ускорения?

VD>Да. С оговоркой, что "значительное" можно интерпретировать по разному. Ускорение конечно будет. Но достичь сравнимых результатов с теми что можно достичь при компиляции не динамических (статически типизируется) языков невозможно.

Я думаю, что ускорение при компиляции все же будет значительное. Ну положим, интерпретируемый динамический язык на 2 порядка медленнее компилируемого. Компилируемый динамический будет на порядок медленнее. Да и то ИМХО в худшем случае. Опять же это можно проверить. В качестве компилируемого динамического языка взять выбенет+страшные опшины или шарп+динамик и сравнить с JScript/VBScript. Я думаю, они некисло от них улетят.

А скорость "как у Си" не особо-то и требуется на самом деле. Типичные бизнес-приложения, много работы с БД, веб-сервисы, прочая хрень — на этом фоне, во-первых, практически весь код таких приложений идет под графом "клей", а во-вторых, и скорость особо и не требуется.

VD>И кому как не тебе об этом знать. Ты же представляешь как в динамических языках представляются переменные?

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

VD>На самом деле единственный путь который может привести к тому что динамический язык будет компилироваться в код быстродействие которого будет примерно такое же как у шарпа и явы — это замена динамики на вывод типов.

А зачем нужно это быстродействие в динамике?

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

ВВ>Я думаю, что ускорение при компиляции все же будет значительное. Ну положим, интерпретируемый динамический язык на 2 порядка медленнее компилируемого. Компилируемый динамический будет на порядок медленнее. Да и то ИМХО в худшем случае.

Это высасывание цифр из пальца. В среднем разница между хорошим скриптом и средненьким компилятором — 10-30 раз, т.е. ~ 1 порядок. Компиляция дает (опять же в среднем) двух-, трех-кратное ускорение. Но на отдельных (обычно вырожденных) задачах можно достичь и более серьезного ускорения.

ВВ>Опять же это можно проверить. В качестве компилируемого динамического языка взять выбенет+страшные опшины или шарп+динамик и сравнить с JScript/VBScript. Я думаю, они некисло от них улетят.

А зачем брать "шарп+динамик"?
Потом, я тебе и так скажу, что там будет где-то ~ 20-и кратного отставания от компилированного варианта.

ВВ>А скорость "как у Си" не особо-то и требуется на самом деле.

Гы-гы. А нафиг тогда этот С (и особенно С++) сдался бы?

ВВ>Типичные бизнес-приложения, много работы с БД, веб-сервисы, прочая хрень — на этом фоне, во-первых, практически весь код таких приложений идет под графом "клей", а во-вторых, и скорость особо и не требуется.

Веб сервисы тоже время занимают. К тому же "типичными бизнес-приложениями" ПО не заканчивается.
В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.

VD>>И кому как не тебе об этом знать. Ты же представляешь как в динамических языках представляются переменные?

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

Я имею в виду рантаймное определение типов значений хранимых в переменных.

VD>>На самом деле единственный путь который может привести к тому что динамический язык будет компилироваться в код быстродействие которого будет примерно такое же как у шарпа и явы — это замена динамики на вывод типов.

ВВ>А зачем нужно это быстродействие в динамике?

Поставим вопрос по другому. А зачем она вообще нужна — эта динамика? А вот быстродействие полезно всегда. Я вот не представляю себе парсер написанного динамическом языке. Те же реализации Лиспа все же обычно пользуются парсерами написанными на низкоуровневых языках или специальных расширениях лиспа позволяющих указывать типы и получать тем самым приемлемый по производительности код. Или взять к примеру PyPy-шный парсер. Он как раз реализован на RPython-е который по сути статически типизируемый сабсэт питона. Это позволяет добиться приемлемой производительности.

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

Л>Вообще, потребность в Domain Specific Language для веба достаточно очевидна. Но я б ручонки всем авторам динамических языков поотрывал. Могли бы ограничиться трансляторами со своего языка в сишный или плюсовый код. На самом C++ могли бы с помощью перегрузки операторов сделать DSL. Да и вообще, для веба нужен не столько функциональный язык, сколько HTML-шаблонизатор с возможностью подстановки данных из баз, интеграцией с веб-сервером.

Ггг. Для веба нужны точно такие же языки, как и для любой другой области.

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

VD>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Я думаю, что ускорение при компиляции все же будет значительное. Ну положим, интерпретируемый динамический язык на 2 порядка медленнее компилируемого. Компилируемый динамический будет на порядок медленнее. Да и то ИМХО в худшем случае.

VD>Это высасывание цифр из пальца. В среднем разница между хорошим скриптом и средненьким компилятором — 10-30 раз, т.е. ~ 1 порядок. Компиляция дает (опять же в среднем) двух-, трех-кратное ускорение. Но на отдельных (обычно вырожденных) задачах можно достичь и более серьезного ускорения.

Надо бы проверить и правда. Я вот помню, что JScript (к-й вместе с MSIE8 идет) сортирует массив из 1000 элементов пузырьком где-то за 0.35 сек. Руби, кстати, делает это где-то за 1.2 сек. Это на моем домашнем i5 750. При этом уже V8 выполняет эту задачу практически без времени. Могу просто уточнить цифры. V8 сойдет за компилируемый? Хотя что дадут эти измерения с другой стороны?

ВВ>>А скорость "как у Си" не особо-то и требуется на самом деле.
VD>Гы-гы. А нафиг тогда этот С (и особенно С++) сдался бы?

В бизнес-ориентированных приложениях? По большей части не сдался, да.

ВВ>>Типичные бизнес-приложения, много работы с БД, веб-сервисы, прочая хрень — на этом фоне, во-первых, практически весь код таких приложений идет под графом "клей", а во-вторых, и скорость особо и не требуется.
VD>Веб сервисы тоже время занимают. К тому же "типичными бизнес-приложениями" ПО не заканчивается.

Само собой. Не заканчивается. Есть задачи где и производительности дотнета мало.
Я не утверждал, что "скрипты" применимы всегда и везде.

VD>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.

Их пишут на том, что рекламируется "большими вендорами" (тм). Будут рекламировать скрипты — начнут писать на скриптах.
Ну вот сам посуди. Есть, скажем, Шарепоинт. У него в качестве бэкенда — SQL Server. Само собой структура базы универсальная, работать с ней напрямую нельзя. Данные в самом Шарепоинте хранятся в так называемых "списках", структура которых от структуры БД, естестественно, отличается. Т.е. уже присутствует нехилый оверхед по сравнению с рукописной базой.
Далее. Для исполнения запросов по спискам сделан свой специальный язык запросов — CAML. На СКЛ он похож слабо. Но транслируется, конечно, в СКЛ. Т.к. создавала этот КАМЛ какая-то охреневшая сволочь, то сделан он на основе ХМЛ-я, что, конечно же, неудобно — на ХМЛ-е то запросы писать.
Теперь вот до кого-то наконец дошло, что КАМЛ это вроде как "не айс" и надо что-то менять в консерватории. Естественно, открутить КАМЛ совсем нельзя — обратная совместимость понимаешь. Да и к тому же у нас уже теперь в языке встроенный ДСЛ для исполнения запросов. Так что решение вроде как очевидно.
В общем делаем еще один слой сверху — Linq2Caml. Как работает Линк, думаю, ты понимаешь куда лучше меня.

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

ВВ>>Ты что имеешь в виду под представлением переменных? Если динамический люкап, то это совсем не обязательное требование для языка с динамической типизацией и, собственно, никакого отношения к ней не имеет.
ВВ>>Кстати, как раз динамический люкап мне не очень нравится самому.
VD>Я имею в виду рантаймное определение типов значений хранимых в переменных.

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

VD>Поставим вопрос по другому. А зачем она вообще нужна — эта динамика? А вот быстродействие полезно всегда. Я вот не представляю себе парсер написанного динамическом языке. Те же реализации Лиспа все же обычно пользуются парсерами написанными на низкоуровневых языках или специальных расширениях лиспа позволяющих указывать типы и получать тем самым приемлемый по производительности код. Или взять к примеру PyPy-шный парсер. Он как раз реализован на RPython-е который по сути статически типизируемый сабсэт питона. Это позволяет добиться приемлемой производительности.

"Быстродействие полезно всегда" — это какое-то сомнительное утверждение. Зачем? Кому полезно? Почему же мы тогда жертвуем быстродействием, переходя на дотнет? Да и критерий странный — нельзя написать эффективный парсер — язык в помойку. Не так уж много парсеров мы тут пишем.

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

Ну я так предполагаю, ты приложения под Шарепоинт не пишешь

Да и сфера твоих интересов — компиляторы, парсеры и проч. — как-то действительно с динамикой не очень дружит. Но есть сферы, которые очень даже дружат. Зачем ее втаптывать в грязь-то?

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

А можно примеры?

Здравствуйте, Mamut, Вы писали:
M>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
А пруфлинк есть?

Здравствуйте, VladD2, Вы писали:
VD>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.
Зато "нескрипты" в "Типичных бизнес-приложениях" (тм) быстро обрастают рефлексией, динамикой и "stringly"-типизацией.

VD>>>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.

N>>А дальше что? Нашли причину или так и остались в непонятках?

VD>Дык это не я же эту статью писал. Откуда я занаю. Но факт остается фактом даже не стремясь можно получить более быструю реализацию на яве нежели на С++.

VD>С++ хорош не тем что он просто позволяет генерировать быстрый машинный код, а тем, что он позовляет делать низкоуровневые оптимизации.

http://balancer.ru/tech/forum/2008/02/t60021--CHto,gospoda-surovye-S-plus-plus-program.html

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

M>2. Куда еще более по сушеству? Людям, которые разрабатывают системы для телекома, важнее динамика, а не мифические бенефиты от статики.
Куда еще более по сушеству? Людям, которые ловят кайф, важнее наркотики, а не мифические бенефиты от здорового образа жизни.

Что еще "доказать" этим методом?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ВВ>А объявления классов, вариантов и проч. это уже не код? Удобно.
А в динамически типизированых языках объявлений типов нет?

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

ВВ>А зарулить динамику невозможно в принципе. Динамика позволяет программисту делать любые допущения о типах на этапе создания программы. *Любые*.
И огребать потом любые проблемы в продакшене.
А на полезном подмножестве всех програм динамика по сравнению с правильно сделанной статикой ничего не дает.

ВВ>Как объяснишь феномен людей, которые с удовольствием пишут на динамических и статических языках? При этом в числе последних могут быть и весьма мощные языки. FR, если я не путаю, пишет на Питоне и OCaml.
ВВ>Впрочем, что я спрашиваю "как объяснишь". Наверняка в ответ будет что-нибудь нецензурное.
Аппеляция к толпе ни разу не аргумент.
Ибо такими методами можно доказать что угодно.

ВВ>Ты либо в дурку играешь, либо я не знаю. С одной стороны сам же утверждаешь, что вывод типов позволяет писать практически такой же лаконичный код, как в динамике, с другой — рекламируешь крутые возможности рефакторинга для языков с выводом типов, а вот для динамики — ни-ни. Тебе самому не странно, нет?
Нет.
В случае с выводом типов у меня есть строгие правила которые позволяют точно вывести все типы всех переменных.
Разрешить все перегрузки.
Я точно знаю где и что.

В случае с динамикой полный бардак. Везде может быть все. Одна и тажа функция может быть вызвана с кучей разных типов.
Ты ссылки того же FR почтай. Там где он рекламирует "круть" IDE для питона...
Статический анализ тупит. Динамический (запуск программы) лучше но тоже далеко не айс. Особенно если запуск не исполняет 100%кода во всех возможных сочетаниях.

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

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

А если у тебя есть доступ к исходниками компилятора то компилятор немерла даст тебе всю информацию (собственно IDE для автокомплита и навигации компилятор и использует), а компилятор питона не даст тебе ничего.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Ггг. Для веба нужны точно такие же языки, как и для любой другой области.
Ага... для веба нужен DSL как и для любой другой предметной области.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.
MC>Зато "нескрипты" в "Типичных бизнес-приложениях" (тм) быстро обрастают рефлексией, динамикой и "stringly"-типизацией.
Это по тому что "нескрипты" не той системы.
При налисии нормальных макросов не обрастают.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ВВ>Надо бы проверить и правда. Я вот помню, что JScript (к-й вместе с MSIE8 идет) сортирует массив из 1000 элементов пузырьком где-то за 0.35 сек. Руби, кстати, делает это где-то за 1.2 сек. Это на моем домашнем i5 750. При этом уже V8 выполняет эту задачу практически без времени. Могу просто уточнить цифры. V8 сойдет за компилируемый? Хотя что дадут эти измерения с другой стороны?

Мало чего дадут. Хотя узнать кто такое V8 было бы все же интересно. Предполагаю что С++ из VS 2008. А там хрен его знает.

"В среднем" — означает, что какие-то задачи просядет сильнее, какие-то меньше.
Что до Руби, то это пожалуй один из худших интерпретаторов среди популярных скриптов. JScript от МС не худший, но и далеко не лучший.

ВВ>>>А скорость "как у Си" не особо-то и требуется на самом деле.
VD>>Гы-гы. А нафиг тогда этот С (и особенно С++) сдался бы?

ВВ>В бизнес-ориентированных приложениях? По большей части не сдался, да.

Нет. Вообще.

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

ВВ>Само собой. Не заканчивается. Есть задачи где и производительности дотнета мало.

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

Вот тут недавно появлялся орел и спрашивал на какую область разработки ориентирован Немерл. Ответ что Немерл является языком общего назначения и применим много для чего его не удовлетворил. Эмпирически он сразу же сделал вывод, что Немерл не применим для математики и для веба ("Математика мимо как я понял. Веб тоже"). Его уверенность была подкреплена одним из ответов котором говорилось, что работа с матрицами в дотнете реализована не самым шустрым образом. И его не остановило даже то, что в этом же ответе было сказано, что она человек как раз этими самыми рассчетами на немреле и занимается, а работу с матрицами перекладывает на GPU (который по любому на таких задачах любой С++ и i7 порвет). Про веб аргумент было вообще потрясающий — "Немерли так же удобен как пхп?".

ВВ>Я не утверждал, что "скрипты" применимы всегда и везде.

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

VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.

ВВ>Их пишут на том, что рекламируется "большими вендорами" (тм). Будут рекламировать скрипты — начнут писать на скриптах.

Ну, дык и все точно так же пишется. Людей со своей головй на плечах очень мало.

Вот для веба как раз рекламируются скрипты. Тут тебе и Руби с рельсами, и ПХП с тонной готовых решений для домашних страничек.

ВВ>Ну вот сам посуди. Есть, скажем, Шарепоинт. У него в качестве бэкенда — SQL Server. Само собой структура базы универсальная, работать с ней напрямую нельзя. Данные в самом Шарепоинте хранятся в так называемых "списках", структура которых от структуры БД, естестественно, отличается. Т.е. уже присутствует нехилый оверхед по сравнению с рукописной базой.
ВВ>Далее. Для исполнения запросов по спискам сделан свой специальный язык запросов — CAML. На СКЛ он похож слабо. Но транслируется, конечно, в СКЛ. Т.к. создавала этот КАМЛ какая-то охреневшая сволочь, то сделан он на основе ХМЛ-я, что, конечно же, неудобно — на ХМЛ-е то запросы писать.
ВВ>Теперь вот до кого-то наконец дошло, что КАМЛ это вроде как "не айс" и надо что-то менять в консерватории. Естественно, открутить КАМЛ совсем нельзя — обратная совместимость понимаешь. Да и к тому же у нас уже теперь в языке встроенный ДСЛ для исполнения запросов. Так что решение вроде как очевидно.
ВВ>В общем делаем еще один слой сверху — Linq2Caml. Как работает Линк, думаю, ты понимаешь куда лучше меня.

ВВ>Короче, у меня возникает серьезное подозрение, что по большому счету уже пофиг какова там скорость кода на языке, на котором ты эти Linq2Caml запросы пишешь.

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

Но это же не означает, что нет задач требующих хорошей производительности?

ВВ>Ну да, в этом суть динамической типизации. И *только* в этом. Больше ничего сюда примешивать не надо.

Это не совсем так. Просто динамика — это всего лишь "дешевое обобщение". Это конечно можно считать огромным плюсом. Но на самом деле современные сктипты популярны не столько из-за этого, сколько из-за поддержки ими "дешевого метапрограммирования". Дешевого — означает легко доступного, а не плохого (если что).

ВВ>И тут все просто на самом деле — тот факт, что все решения о типах принимаются в рантайме есть одновременно и главное преимущество, и главный недостаток динамически-типизированных языков.

Несомненно.

ВВ>Достичь такой же гибкости системы типов в статике нельзя по определению,

Такой же наверно не достичь. Но достичь приемлемой гибкости можно и относительно легко.

ВВ>но в динамике нельзя так хорошо проконтролировать программиста.

И получать такой же оптимизированный (читай быстырй) код.

VD>>Поставим вопрос по другому. А зачем она вообще нужна — эта динамика? А вот быстродействие полезно всегда. Я вот не представляю себе парсер написанного динамическом языке. Те же реализации Лиспа все же обычно пользуются парсерами написанными на низкоуровневых языках или специальных расширениях лиспа позволяющих указывать типы и получать тем самым приемлемый по производительности код. Или взять к примеру PyPy-шный парсер. Он как раз реализован на RPython-е который по сути статически типизируемый сабсэт питона. Это позволяет добиться приемлемой производительности.

ВВ>"Быстродействие полезно всегда" — это какое-то сомнительное утверждение.

Не более чем "динамика полезна".

ВВ>Зачем? Кому полезно?

В первую очередь пользователю.

ВВ>Почему же мы тогда жертвуем быстродействием, переходя на дотнет?

Зачем чушь то говорить? Ничем мы не жертвуем. На дотнете без проблем можно писать очень быстрый код. В него даже С++ можно компилировать почти без потерь производительности.

ВВ>Да и критерий странный — нельзя написать эффективный парсер — язык в помойку.

Я не говорил о помойке. Я говорил, что нельзя.

ВВ>Не так уж много парсеров мы тут пишем.

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

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

ВВ>Ну я так предполагаю, ты приложения под Шарепоинт не пишешь

100%. И я уж лучше в таксисты пойду нежели буду заниматься этим (как бы не накаркать

).

ВВ>Да и сфера твоих интересов — компиляторы, парсеры и проч. — как-то действительно с динамикой не очень дружит.

Да нет тех сфер которые с ней дружат (или не дружат). Нееет! Для любой сферы можно с тем же успехом использовать подходящий статически-типизированный язык. Фактор "мне кажется удобнее" — это все же субективное мнение. Тебе кажется удобнее, а мне нет. А вот фактор достаточности производительности является весьма объективным.

ВВ>Но есть сферы, которые очень даже дружат. Зачем ее втаптывать в грязь-то?

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

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

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

Полиморфизм всегда и везде уже не является таким уж однозначным плюсом. Плюсом является простота достижения этого самого полиморфизма. В скриптах полиморфизм достигается очень просто. Скажем в дотнете с этим есть проблемы, так как при наличии самих средств полиморфизма все же есть проблемы в реализации полиморфных методов. В основном они связаны с невозможностью полиморфного использования уже имеющихся типов (которые не были для этого предназначены). Проще говоря мы не можем в денерик-методах или типах использовать специфичные методы/операторы/свойства типов. Для этого нужно делать ряд телодвижений вроде введения и реализации интерфейсов, создания промежуточных объектов (вроде компараторов), использования лямбд для абстрагирования алгоритмов. Да — это создает неудобства. Но а) это не есть ограничение статики, это ограничение конкретной реализации, б) освоение небольшого набора приемов позволяет легко обходить эту проблему.

Еще одним (и возможно основным) "преимуществом" динамики является наличие метапрограммирования. Это мало кто афиширует (кроме, пожалуй, лисперов), но тем не менее — это так! Какие самые популярные языки программирования? Питон, Руби, Лиспы и ЯваСкрип (причем последний популярен в основном благодаря его доступности в браузерах). Все эти языки имеют весьма мощную (ну, за исключением ЯваСкрипа) подсистему метапрограммирования. Это позволяет создавать на их базе весьма выразительные и мощные решения.

Но как мы с вами знаем, метапрограммирование так же не является отличительной чертой скриптов. Просто его намного сложно качественно реализовать в статически-типизированном языке.

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

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

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

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

M>А можно примеры?

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

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

MC>Здравствуйте, VladD2, Вы писали:
VD>>В прочем, "Типичные бизнес-приложения" (тм) очень редко пишут на скриптах. Так что тут даже разговаривать не о чем.
MC>Зато "нескрипты" в "Типичных бизнес-приложениях" (тм) быстро обрастают рефлексией, динамикой и "stringly"-типизацией.

Не знаю. Сейчас тенденция обратная. Вот SQL на LINQ заменяют.

Для динамики в статике же давно придумали отличное решение — компонентный подход. Его применение позволяет достичь многих вещей ради чего применяют к скриптам, но при этом оставаясь в рамках статической типизации. Конечно можно назвать это рефлексией — но это хорошая рефлексия.

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

ZEN>http://balancer.ru/tech/forum/2008/02/t60021--CHto,gospoda-surovye-S-plus-plus-program.html
ZEN>

Сори, пенесометрии меня мало интересуют. Я знаю, что хорошие руки на С/С++ всегда могут оптимизировать решение задачи так, что никакие автоматические средства до этого решения не дотянут. Но я так же знаю цену таких оптимизаций.

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

MC>Здравствуйте, Mamut, Вы писали:
M>>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
MC>А пруфлинк есть?

сейчас лень искать далеко по рассылке, но есть пара ссылок в таком ключе:

http://article.gmane.org/gmane.comp.lang.erlang.general/19158

ericsson (who funds the OTP development) has reached the
conclusion that static typing would not improve the reliability of their
products. some ericsson people might even argue that static typing would lower
the quality of said products.

http://article.gmane.org/gmane.comp.lang.erlang.general/19165

...none of the attempts at
creating a static type system for Erlang were able to
attract enough users to become interesting in practice.

...there
is no formal acceptance or rejection process for Erlang.
If it had proven useful and enough people had started
using it, static typing might have made it into Erlang.

В догонку:
http://article.gmane.org/gmane.comp.lang.erlang.general/19182

a few years ago i did a study on erlang-related bug reports in our live
product. the conclusion was that once we get to system test, we find essentially
no more type-related bugs.

www.erlang.se/workshop/2004/matsbilder.pdf

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

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

M>>2. Куда еще более по сушеству? Людям, которые разрабатывают системы для телекома, важнее динамика, а не мифические бенефиты от статики.
WH>Куда еще более по сушеству? Людям, которые ловят кайф, важнее наркотики, а не мифические бенефиты от здорового образа жизни.

WH>Что еще "доказать" этим методом?

Нуну. От тебя, я вижу, «аргументы» еще более по существу. Тут еще надо внимательно приглядется, кто на наркотиках

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

M>>А можно примеры?

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

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

VD>Про конвертацию видео и т.п. я даже заикаться не хочу.

Про конвертацию не скажу, но с видео вполне можно работать. И опять же, для подавляющего количества людей здесь производительность — это не real-time и не обработка терабайтов данных в сжатые сроки.

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

M>сейчас лень искать далеко по рассылке, но есть пара ссылок в таком ключе:

M>http://article.gmane.org/gmane.comp.lang.erlang.general/19158
M>http://article.gmane.org/gmane.comp.lang.erlang.general/19165
M>В догонку:
M>http://article.gmane.org/gmane.comp.lang.erlang.general/19182

Спасиб, Мамут, что напомнил тёрки 4-летней давности

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

M>Нуну. От тебя, я вижу, «аргументы» еще более по существу. Тут еще надо внимательно приглядется, кто на наркотиках

Мои аргументы объективны.
1)Скорость исполнения у динамически типизированных языков ниже.
2)Динамически типизированные языки не ловят ошибки на этапе компиляции.

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

И таки да. Вы все знаете о каком языке я говорю.

Все что у тебя есть это "Миллион леммионгов не может ошибаться." Ага...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>Назови хоть одно преимущество динамической типизации.
WH>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.

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

WH>>Назови хоть одно преимущество динамической типизации.
WH>>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
G>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
G>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.

Да фигня этот тестовый код. Есть простое правило — чисто не там, где не гадят, а там, где убирают. В динамических языках при объеме кода больше определенного порога вобще невозможо даже теоретически привести код в порядок.
По этой причне динамика процветает именно там, где код проще выкинуть и написать заново. Веб это вобщем то именно такое место.
Тестовый, не тестовый код, если его можно упростить, причесать, преобразовать — то этим проблемы и решатся. Единственно, где у динамики преимущество, это перед С++. Там тоже принято не убирать за собой.

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

VD>Мало чего дадут. Хотя узнать кто такое V8 было бы все же интересно. Предполагаю что С++ из VS 2008. А там хрен его знает.

V8 — это реализация ECMAScript в Хроме, которая джитится. Причем джитится она напрямую, насколько я знаю, без всякого промежуточного представления. Вот, кстати, тестик, тупой по самое не могу:

var list = [];
var size = 1000;

for (var i = 0; i < size; i++)
    list[i] = size - i;

function BubbleSort(item)
{  
    for(var i = 0; i < item.length; i++)
    {
        for(var j = 0; j < item.length - i - 1; j++)
        {
            if(item[j + 1] < item[j])
            {
                var x = item[j];
                item[j] = item[j + 1];
                item[j + 1] = x;
            }
        }
    }
};

BubbleSort(list);

JScript MSIE8 — 367
V8 — 22

Как видишь, разница некислая все же.

VD>"В среднем" — означает, что какие-то задачи просядет сильнее, какие-то меньше.
VD>Что до Руби, то это пожалуй один из худших интерпретаторов среди популярных скриптов. JScript от МС не худший, но и далеко не лучший.

JScript они, кстати, допиливают потихоньку. Тот, что идет с 8-м осликом стал гораздо шустрее работать. В 7-м на том же тесте было порядка 600 мс.

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

Но ведь сам же постоянно делаешь то же самое

VD>Вот тут недавно появлялся орел и спрашивал на какую область разработки ориентирован Немерл. Ответ что Немерл является языком общего назначения и применим много для чего его не удовлетворил. Эмпирически он сразу же сделал вывод, что Немерл не применим для математики и для веба ("Математика мимо как я понял. Веб тоже"). Его уверенность была подкреплена одним из ответов котором говорилось, что работа с матрицами в дотнете реализована не самым шустрым образом. И его не остановило даже то, что в этом же ответе было сказано, что она человек как раз этими самыми рассчетами на немреле и занимается, а работу с матрицами перекладывает на GPU (который по любому на таких задачах любой С++ и i7 порвет). Про веб аргумент было вообще потрясающий — "Немерли так же удобен как пхп?".

Про ПХП это смешно, оценил.

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

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

WH>>Назови хоть одно преимущество динамической типизации.
WH>>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
G>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
G>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.

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

Я частично согласен с остальными аргументами против динамики, но именно данный аргумент просто некорректен.

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

WH>Мои аргументы объективны.
WH>1)Скорость исполнения у динамически типизированных языков ниже.
WH>2)Динамически типизированные языки не ловят ошибки на этапе компиляции.

WH>Назови хоть одно преимущество динамической типизации.
WH>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
WH>Метапрограммирование? Так оно прекрасно работает и в статически типизированных языках.

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

) Если ты пользуешься только теми возможностями, которые обычно ассоциируются со статическими языками, то у тебя даже простейший duck typing не будет работать.

WH>Кодогенерация в рантайме? Опять никаких проблем.

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

WH>И таки да. Вы все знаете о каком языке я говорю.

Неужели Algol 68?

Ах да, он на дотнете не работает...

WH>Все что у тебя есть это "Миллион леммионгов не может ошибаться." Ага...

P.S. Мне вот интересно — сколько из прочитавших моё сообщение решит, за что я агитирую и почему?

)

P.S[2]. А расскажите мне, каким образом в ASP.NET (я не перепутал название?) делается смена кода на ходу. Интересны именно механизмы и их ограничения.

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

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

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

WH>>>Назови хоть одно преимущество динамической типизации.
WH>>>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
G>>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
G>>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.

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

N>Я частично согласен с остальными аргументами против динамики, но именно данный аргумент просто некорректен.
Счегобы?
Банальный пример:

f1(f2(f3())))

В статически типизированном языке компилятор проверит соответствие типов. Для динамического языка надо писать проверки типов в тестах.

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

ВВ>Понятно. Только начали беседовать — уже религиозные лозунги.
ВВ>У меня уже начинает складываться впечатление, что у всех немерлистов есть строгая и неоспоримая позиция по всем, так сказать, вопросам жизни и смерти. А несогласие с этой позицией воспринимается чуть ли не как личное оскорбление. Надеюсь, это не заразно.

Это очень заразно. jIMHO, основная проблема Nemerle в кривой базе (.NET). Кривой — потому что база, сделанная MS только под Windows с её спецификой и закреплённая в таком виде, не годится для массы народа потому что
* работают под Unix, MacOS, etc. (а адаптировать даже Mono — та ещё забота)
* религиозные соображения запрещают всё от MS

в результате это во много раз сокращает пользовательскую базу, особенно среди тех, кто мог бы внести теоретический вклад и массовое использование;(

А как следствие этого — команда Nemerle психологически уже ориентирована на оппозицию и агрессивное отстаивание своей позиции. VladD2 это показывает на 120%.

Может, допишу ещё комментарий на это сообщение, но надо бежать по делам

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

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

)
Почему лицемерие?
Я почти каждый день работаю на немерле.
И там все прекрасно работает.
Причем даже весьма сложные вещи http://habrahabr.ru/blogs/nemerle/104968/

И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser

LRPEGCC — Макрос
Nemerle.Peg — Рантайм
CSharp — Парсер C#4
Остальное можно не смотреть.

N>Если ты пользуешься только теми возможностями, которые обычно ассоциируются со статическими языками, то у тебя даже простейший duck typing не будет работать.
С++
В шаблонах работает статически типизируемый duck typing...
А вообще это зло. Ты видел сообщения об ошибках при компиляции шаблонов С++?

Только не надо про динамику. Ошибка есть ошибка. И в отличии от шаблонов С++ она имеет все шансы вылезти в продакшене, а не при компиляции.

Нужны явные контракты. Это решает много проблем.

N>"Никаких проблем", если ты фактически принесёшь с собой компилятор (может, ещё и с JIT).
Так нтерпритаторы и носят с собой всю эту инфраструктуру всегда.

N>Во многих случаях это удовольствие сильно дороже, чем просто интерпретатор.
Например.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

G>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
На единици процентов.

G>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.
С большим таким запасом нивилируетя... А если учесть то что тесты ничего не герантируют...
Простой пример http://www.impredicative.com/ur/
А теперь обеспечь эти гарантии тестами

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

И еще про тормоза полученого решения не забудь.

А когда дело до рефкторинга доходит то вообще тушите свет.

Ну и нахрена оно надо?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

G>>Вообще говоря динамические языка дают уменьшение объема даже по сравнению с языками с выводом типов.
WH>На единици процентов.

G>>Но это все нивелируется необходимостью писать тестовый код чтобы как-то гарантировать работоспособность.
WH>С большим таким запасом нивилируетя... А если учесть то что тесты ничего не герантируют...
WH>Простой пример http://www.impredicative.com/ur/
WH>А теперь обеспечь эти гарантии тестами

WH>Можешь взять любой динамически типизируемый язык с любым фреймворком.

WH>И еще про тормоза полученого решения не забудь.

WH>А когда дело до рефкторинга доходит то вообще тушите свет.

WH>Ну и нахрена оно надо?
Да я вот тоже не знаю.

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

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

N>Это очень заразно. jIMHO, основная проблема Nemerle в кривой базе (.NET). Кривой — потому что база, сделанная MS только под Windows с её спецификой и закреплённая в таком виде, не годится для массы народа потому что
Nemerle2 будет сделан таким образом чтобы он мог комплироваться не только в .НЕТ
Нужно будет обязательно сделать поддержку LLVM.
Про JVM не уверен. Уж очень она кривая. Хотя если забить на некоторую потерю производительности можно и ее поддержать.

N>* работают под Unix, MacOS, etc. (а адаптировать даже Mono — та ещё забота)
Это религия. Моно работает.

N>* религиозные соображения запрещают всё от MS
Ну тут ты сам признаешь что это религия.

N>А как следствие этого — команда Nemerle психологически уже ориентирована на оппозицию и агрессивное отстаивание своей позиции. VladD2 это показывает на 120%.
Мозговед из тебя так себе.
Влада я знаю еще с тех времен когда немерлом и не пахло. Так вот намерле на его поведении не отразился.

Что касается меня то я просто перфекционист и питаю глубокое отвращения к фундаментально ущербным концепциям таким как динамическая типизация. А что касается немерле то для меня это не более чем подопытный кролик на котором я свои идеи обкатываю.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

G>С современными языками довольно сложно придумать адекватное применение динамики.
А его нет.
Единственное место где адекватно динамическое приведение типов это реализация плагинов.
Вот только вся динамика заключается в строке типа

IPlugin plugin = (IPlugin)Activator.CreateInstance(...);

А дальше опять статика.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

G>>С современными языками довольно сложно придумать адекватное применение динамики.
WH>А его нет.
WH>Единственное место где адекватно динамическое приведение типов это реализация плагинов.
WH>Вот только вся динамика заключается в строке типа
WH>

WH>IPlugin plugin = (IPlugin)Activator.CreateInstance(...);
WH>

WH>А дальше опять статика.

Я в динамике последний раз делал визитор на C#. Вызов dynamic обеспечивает диспетчеризацию в рантайме.
Но это скорее не динамика сама по себе, а стык динамики и статики.

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

N>>Это очень заразно. jIMHO, основная проблема Nemerle в кривой базе (.NET). Кривой — потому что база, сделанная MS только под Windows с её спецификой и закреплённая в таком виде, не годится для массы народа потому что
WH>Nemerle2 будет сделан таким образом чтобы он мог комплироваться не только в .НЕТ
WH>Нужно будет обязательно сделать поддержку LLVM.

О, вот тогда и начнём смотреть.

N>>* работают под Unix, MacOS, etc. (а адаптировать даже Mono — та ещё забота)
WH>Это религия. Моно работает.

Это не религия. Попытка хоть как-то её заюзать нарвалась, например, на следующее:
1. Нельзя открыть один и тот же файл два раза, не воспользовавшись специальными флагами "разделять открытие".
2. Mono пытается вести собственный индекс файловых дескрипторов, отдельно от системных, причём не даёт достаточного API для прямой работы с ними.
Первое ещё можно было преодолеть массовыми патчами, но второе тут же отправило попытки работать с ним в морг. Вот что получается, если переносить виндовые средства на unix...

N>>* религиозные соображения запрещают всё от MS
WH>Ну тут ты сам признаешь что это религия.

Да, но от этого не легче.

N>>А как следствие этого — команда Nemerle психологически уже ориентирована на оппозицию и агрессивное отстаивание своей позиции. VladD2 это показывает на 120%.
WH>Мозговед из тебя так себе.
WH>Влада я знаю еще с тех времен когда немерлом и не пахло. Так вот намерле на его поведении не отразился.

А подумай с другой стороны — если бы не его характер, он бы бросил Nemerle.
Да, это всё только догадки, но пока что не вижу опровержений.

WH>Что касается меня то я просто перфекционист и питаю глубокое отвращения к фундаментально ущербным концепциям таким как динамическая типизация. А что касается немерле то для меня это не более чем подопытный кролик на котором я свои идеи обкатываю.

В динамической типизации нет ничего фундаментально ущербного: это то, как думают _люди_. У нашего мышления не бывает статической типизации, она — не более чем оптимизация под свойства современных компьютеров.

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

N>>"Необходимость писать тестовый код чтобы как-то гарантировать работоспособность" есть _везде_. В любом коде, даже самом типизированном и компилированном, тривиально сделать ошибку, которая может быть проверена только внешним тестом, задавая вход и проверяя выход. И чем больше код делает реальной работы, тем это важнее.
G>Неправда. В статически типизированном языке очень много проверок выполняет компилятор, в динамически типизированном — нет.

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

N>>Я частично согласен с остальными аргументами против динамики, но именно данный аргумент просто некорректен.
G>Счегобы?
G>Банальный пример:

G>

G>f1(f2(f3())))
G>

G>В статически типизированном языке компилятор проверит соответствие типов. Для динамического языка надо писать проверки типов в тестах.

Мнэээ... зачем проверять типы промежуточных данных? Это годится только для крайне малого объёма кода — т.е. для песочницы. Для реальных ситуаций надо проверять, что на входе и что на выходе, а это не отличается от факта тестирования в случае статической типизации.

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

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

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

)
WH>Почему лицемерие?

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

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

WH>Я почти каждый день работаю на немерле.

Так он статически или динамически типизирован?

WH>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser

Не буду пытаться спорить с этой цифрой.

Но к чему она?

WH>С++
WH>В шаблонах работает статически типизируемый duck typing...

Знаю, но не считаю это примером для данного случая.

WH>А вообще это зло. Ты видел сообщения об ошибках при компиляции шаблонов С++?

Видел. И радуюсь, что мне не нужно писать на C++.

WH>Только не надо про динамику. Ошибка есть ошибка. И в отличии от шаблонов С++ она имеет все шансы вылезти в продакшене, а не при компиляции.
WH>Нужны явные контракты. Это решает много проблем.

Это речь про статику или динамику?

Здравствуйте, netch80, Вы писали:
N>Это не религия. Попытка хоть как-то её заюзать нарвалась, например, на следующее:
N>1. Нельзя открыть один и тот же файл два раза, не воспользовавшись специальными флагами "разделять открытие".
N>2. Mono пытается вести собственный индекс файловых дескрипторов, отдельно от системных, причём не даёт достаточного API для прямой работы с ними.
N>Первое ещё можно было преодолеть массовыми патчами,
Да, странная фича, но что она ломает? По идее, должен сломаться код, портированный из какой-то более юниксовой среды (почему-то мне в голову лезет мысль про перенос с питона на IronPython+Mono).

N>но второе тут же отправило попытки работать с ним в морг. Вот что получается, если переносить виндовые средства на unix...
А можно пример проблемы?

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

MC>Здравствуйте, netch80, Вы писали:
N>>Это не религия. Попытка хоть как-то её заюзать нарвалась, например, на следующее:
N>>1. Нельзя открыть один и тот же файл два раза, не воспользовавшись специальными флагами "разделять открытие".
N>>2. Mono пытается вести собственный индекс файловых дескрипторов, отдельно от системных, причём не даёт достаточного API для прямой работы с ними.
N>>Первое ещё можно было преодолеть массовыми патчами,
MC>Да, странная фича, но что она ломает? По идее, должен сломаться код, портированный из какой-то более юниксовой среды (почему-то мне в голову лезет мысль про перенос с питона на IronPython+Mono).

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

N>>но второе тут же отправило попытки работать с ним в морг. Вот что получается, если переносить виндовые средства на unix...
MC>А можно пример проблемы?

Так я ж описал, что ещё нужно?

M>>Нуну. От тебя, я вижу, «аргументы» еще более по существу. Тут еще надо внимательно приглядется, кто на наркотиках

WH>Мои аргументы объективны.

Вах. Неужели.

Я не пытаюсь лечить динамику.
Эту ошибку природы личить не имеет смысла.

Людям, которые ловят кайф, важнее наркотики, а не мифические бенефиты от здорового образа жизни.

Вот это — верх аргументации, ага.

WH>1)Скорость исполнения у динамически типизированных языков ниже.

Никому не нужна сферовакуумная скорость в отрыве от задачи. Если динамически типизируемый Erlang дает мне обработать 5000 запросов в секунду при том, что у меня пиковая нагрузка 1000, то зачем мне нужен статически типизируемый C#, например?

WH>2)Динамически типизированные языки не ловят ошибки на этапе компиляции.

Ошибки на этапе компиляции — это очень малая часть всех ошиок, что встречаются в программировании. Даже здесь, в «философии программирвания» про это говорили, и не раз, со ссылками на исследования и т.п.

WH>Назови хоть одно преимущество динамической типизации.
WH>Объем кода? По сравнению с жабой? Да. По сравнению с языком с выводом типов? Нет.
WH>Метапрограммирование? Так оно прекрасно работает и в статически типизированных языках.
WH>Кодогенерация в рантайме? Опять никаких проблем.

Процитирую Эрика Майера:

We are interesting in building data-intensive three-tiered en- terprise applications. Perhaps surprisingly, dynamism is probably more important for data intensive programming than for any other area where people traditionally position dynamic languages and scripting. Currently, the vast majority of digital data is not fully structured, a common rule of thumb is less then 5 percent. In many cases, the structure of data is only stat- ically known up to some point, for example, a comma separated file, a spreadsheet, an XML document, but lacks a schema that completely describes the instances that a program is working on. Even when the structure of data is statically known, people often generate queries dynamically based on runtime informa- tion, and thus the structure of the query results is statically unknown.

Hence it should be clear that there is a big need for languages and databases that can deal with (semi-structured) data in a much more dynamic way then we have today. In contrast to pure scripting languages and statically typed general purpose languages, data intensive applications need to deal seamlessly with several degrees of typedness.

WH>И таки да. Вы все знаете о каком языке я говорю.

Не имею ни малейшего представления. Ах, Немерле, наверное? Ну, когда Немерле станет хоть где-то когда-то использоваться, тогда и поговорим.

WH>Все что у тебя есть это "Миллион леммионгов не может ошибаться." Ага...

Нет. У меня есть опыт компании, разрабатывавшей Erlang, и использующей его в гигантском проекте. Оказалось, что преимуществ статическая типизация им не дает.

Здравствуйте, netch80, Вы писали:
N>>>но второе тут же отправило попытки работать с ним в морг. Вот что получается, если переносить виндовые средства на unix...
MC>>А можно пример проблемы?
N>Так я ж описал, что ещё нужно?
А, про файловые дескрипторы — это применительно все к той же проблеме открытия файлов?

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

MC>Здравствуйте, netch80, Вы писали:
N>>>>но второе тут же отправило попытки работать с ним в морг. Вот что получается, если переносить виндовые средства на unix...
MC>>>А можно пример проблемы?
N>>Так я ж описал, что ещё нужно?
MC>А, про файловые дескрипторы — это применительно все к той же проблеме открытия файлов?

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

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

N>Это очень заразно. jIMHO, основная проблема Nemerle в кривой базе (.NET). Кривой — потому что база, сделанная MS только под Windows с её спецификой и закреплённая в таком виде, не годится для массы народа потому что
N>* работают под Unix, MacOS, etc. (а адаптировать даже Mono — та ещё забота)
N>* религиозные соображения запрещают всё от MS
N>в результате это во много раз сокращает пользовательскую базу, особенно среди тех, кто мог бы внести теоретический вклад и массовое использование;(
N>А как следствие этого — команда Nemerle психологически уже ориентирована на оппозицию и агрессивное отстаивание своей позиции. VladD2 это показывает на 120%.
N>Может, допишу ещё комментарий на это сообщение, но надо бежать по делам

Это не вы ли спрашивали, удобнее ли Немерле, чем ПХП?

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

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

N>>Моя практика показывает, что тестов достаточно. Разумеется, если они грамотно построены (вот это уже совершенно неформализуемый признак).
WH>А я обхожусь исключительно функциональными тестами. Как показывает практика при наличии статической типизации другие не нужны.

Извини, "другие" это какие? Юниттесты? Мнэээ... Давай разберём следующий пример (да, я знаю, что он почти учебный):

int // number of roots
solve_square(double a, double b, double c, double *px1, double *px2)
{
  double dd = b*b - 3*a*c;
  if (dd < 0)
    return 0;
  double qb = -b / (2.0 * a);
  if (dd == 0) {
    *px1 = qb;
    return 1;
  }
  double d2a = sqrt(d) / (2.0 * a);
  *px1 = qb + d2a;
  *px2 = qb - d2a;
  return 2;
}

В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции? Прошу чёткое решение для любого из достаточно распространённых языков. Математическую библиотеку не привлекать. И опиши, что будет в твоём проекте, если в функции такого низкого уровня будет ошибка. Сможешь ли ты опознать при запуске функционального теста, что вообще есть ошибка, и указать, в какой функции?

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

ВВ>Это не вы ли спрашивали, удобнее ли Немерле, чем ПХП?

Точно не я: я не терплю PHP настолько, что отказываюсь связываться с любой работой, где он хоть как-то участвует.
А к чему вопрос?

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

N>А подумай с другой стороны — если бы не его характер, он бы бросил Nemerle.
Если увидит что-то получше бросит.
Но все остальное недотягивает...

N>В динамической типизации нет ничего фундаментально ущербного: это то, как думают _люди_. У нашего мышления не бывает статической типизации, она — не более чем оптимизация под свойства современных компьютеров.
Ерунду ты говоришь.
Люди думают на языке и в соответствии с правилами языка.
А язык может быть любым.

Также не нужно забывать что человек может держать в голове 7+-2 сущьности.
А компилятор может запоминать пока память у компьютера не кончится... а учитывая сколько на современных машинах памяти...
Вот и получается что в случае с динамической типизацией человек должен следить за всем сам (а краткосрочная память у человека мааааленькая). А в случае со статикой можно кучу всего переложить на компилятор.
И чем система типов круче тем больше может проверить компилятор.
Причем чем больше делает проверок компилятор тем меньше их остается рантайму. Скажем зависимые типы могут устранить практически все проверки в программе. Делая код надежней и быстрее.
Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.
Так что статическая типизация это оптимизация не только под процессор но и под человека.

Вот и получается что динамическая типизация не подходит ни человеку ни машине.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

N>Так он статически или динамически типизирован?

Статически.

WH>>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser
N>Не буду пытаться спорить с этой цифрой.

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

WH>>Только не надо про динамику. Ошибка есть ошибка. И в отличии от шаблонов С++ она имеет все шансы вылезти в продакшене, а не при компиляции.
WH>>Нужны явные контракты. Это решает много проблем.
N>Это речь про статику или динамику?
Про статику конечно. В динамике контракты бесполезны ибо их проверять некому.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>>В динамической типизации нет ничего фундаментально ущербного: это то, как думают _люди_. У нашего мышления не бывает статической типизации, она — не более чем оптимизация под свойства современных компьютеров.
WH>Ерунду ты говоришь.
WH>Люди думают на языке и в соответствии с правилами языка.

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

WH>А язык может быть любым.

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

WH>Также не нужно забывать что человек может держать в голове 7+-2 сущьности.
WH>А компилятор может запоминать пока память у компьютера не кончится... а учитывая сколько на современных машинах памяти...
WH>Вот и получается что в случае с динамической типизацией человек должен следить за всем сам (а краткосрочная память у человека мааааленькая). А в случае со статикой можно кучу всего переложить на компилятор.

Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.

Если у тебя нет динамической типизации, то альтернативой в случае изменения является смена API и порой радикальная. Например, в Erlang типичен возврат {error, Error} в качестве признака ошибки, где Error — произвольно сложный терм. Обычно он не анализируется (или анализируется только на типичные шаблоны). Полный анализ ведёт уже человек. Что ты дашь альтернативой при статической типизации? Базовый класс Exception?

WH>И чем система типов круче тем больше может проверить компилятор.

Никаких возражений. Но это начинает работать только там, где человек намеренно загнал значение в определённые рамки — например, установил, что тут целое число от нуля до миллиона. А если не загнал?

WH>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.

"Что там может прийти" должно быть в документации.

WH>Так что статическая типизация это оптимизация не только под процессор но и под человека.
WH>Вот и получается что динамическая типизация не подходит ни человеку ни машине.

"Ерунду ты говоришь" ((c) некто WolfHound)

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

N>>Потому что подменяет статически типизированный язык — мультиконцептуальным, где преобладает статическая типизация, но можно использовать и динамическую.
WH>Ты вообще о чем?
WH>Метапрограммирование в немерле работает на этапе компиляции и никакой динамики не использует.

Что ты здесь понимаешь под метапрограммированием?

WH>>>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>>>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser
N>>Не буду пытаться спорить с этой цифрой.

Но к чему она?
WH>К тому что можно сделать при помощи метапрограммирования времени компиляции на статически типизированном языке.
WH>Просто у меня возникает ощущение что ты не веришь в то что макросы могут работать в статически типизируемом языке.
WH>Так они могут. И делают это очень хорошо.

Я верю. Но проблема не в этом и не в макросах.

WH>>>Только не надо про динамику. Ошибка есть ошибка. И в отличии от шаблонов С++ она имеет все шансы вылезти в продакшене, а не при компиляции.
WH>>>Нужны явные контракты. Это решает много проблем.
N>>Это речь про статику или динамику?
WH>Про статику конечно. В динамике контракты бесполезны ибо их проверять некому.

Ну вообще-то даже простой assert() времени выполнения уже проверяет какой-то контракт.

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

M>Вот это — верх аргументации, ага.
Ты бы почитал на что я отвечал.
Одна из фраз вообще твоя. Я там просто несколько слов изменил для того чтобы продемонстрировать тебе ущербность твоей логики. Но похоже не помогло.

M>Никому не нужна сферовакуумная скорость в отрыве от задачи. Если динамически типизируемый Erlang дает мне обработать 5000 запросов в секунду при том, что у меня пиковая нагрузка 1000, то зачем мне нужен статически типизируемый C#, например?
Это пока ты остаешься в рамках.
Но шаг в сторону и превет.
Если нужно что-то посчитать начинаются тормоза.
Скажем при помощи этого http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser#peg-parser/CSharp
Я могу парсить C#4 со скорость 2 мегабайта в секунду.
Слабо повторить на ерланге?

M>Ошибки на этапе компиляции — это очень малая часть всех ошиок, что встречаются в программировании. Даже здесь, в «философии программирвания» про это говорили, и не раз, со ссылками на исследования и т.п.
Да мне плевать что кто-то что-то там писал.
http://www.impredicative.com/ur/
Вот попробуй тестами гарантировать отсутствие перечисленных проблем.

Not only do they not crash during particular page generations, but they also may not:

* Suffer from any kinds of code-injection attacks
* Return invalid HTML
* Contain dead intra-application links
* Have mismatches between HTML forms and the fields expected by their handlers
* Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
* Attempt invalid SQL queries
* Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

M>Процитирую
Ты не забывай заголовки читать... а то смешно получается.

Static Typing Where Possible, Dynamic Typing When Needed

Если у тебя есть помойка со слабо структуированными данными то приходится как то выкручиваться.
Но это очень редкий случай.
Но и тут польза динамической типизации мягко говоря не очевидна.
Ну во есть у тебя какая то байда в которой есть не поймешь что.
И что дальше?
Ну загрузил ты это все в объект.
И что дальше?
Обратишься к полю по имени? А если там ничего нет? Данные то у нас структуированы как попало.
Что делать?
Схлопывать ласты?
Или проверять есть ли у объекта поле?
И так на каждое поле. И каждый подобъект. И так до бесконечности.

Теперь сравним со статикой:
Описал тип.
И макросом сгенерировал для этого типа читалку которая проверяет наличие всех нужных нам полей. Если поле опционально то Option никто не отменял.

Итого:
Статика:
1)Проверка структуры декларативна.
2)Автокомплит, рефакторинг, навигация,...
3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.
4)Скорость работы высокая.

Динамика:
1)Проверки структуры императивны и размазаны по всей программе.
2)Поддержки IDE нет. Ибо структура объекта не извесна. И взять ее негде.
3)Компилятор молчит.
4)Тормоза.

Где профит то?

M>Не имею ни малейшего представления. Ах, Немерле, наверное? Ну, когда Немерле станет хоть где-то когда-то использоваться, тогда и поговорим.
Тебе нужен миллион леммингов?
Или корпорация?

M>Нет. У меня есть опыт компании, разрабатывавшей Erlang, и использующей его в гигантском проекте. Оказалось, что преимуществ статическая типизация им не дает.
У тебя есть демагогия: Аппеляция к толпе. Аппеляция к авторитету.
Технических аргументов нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>Что ты здесь понимаешь под метапрограммированием?
Метапрограмма — программа которая пишет другую программу.
Метапрограммирование — написание программы которая пишет другую программу.

Макросы немерла это программы которые пишут другие программы.

N>Я верю. Но проблема не в этом и не в макросах.
Какая проблема? Все отлично работает.

N>Ну вообще-то даже простой assert() времени выполнения уже проверяет какой-то контракт.
Фигня это, а не контракт.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции? Прошу чёткое решение для любого из достаточно распространённых языков. Математическую библиотеку не привлекать. И опиши, что будет в твоём проекте, если в функции такого низкого уровня будет ошибка. Сможешь ли ты опознать при запуске функционального теста, что вообще есть ошибка, и указать, в какой функции?
Проверь тестами:

Not only do they not crash during particular page generations, but they also may not:

* Suffer from any kinds of code-injection attacks
* Return invalid HTML
* Contain dead intra-application links
* Have mismatches between HTML forms and the fields expected by their handlers
* Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
* Attempt invalid SQL queries
* Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

http://www.impredicative.com/ur/

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>Я не видел, чтобы люди думали, например, "uint32", а не "целое число", кроме случаев, когда их специально приучили к специфике предметной области. И даже "шестизначное число" — это уже адаптация к специфике конкретного применения, которую ещё надо уточнить и понять (например, ведущие нули нужны или нет?)
Сначала "я не видел" и тутже пошли отмазки...

N>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.
Ну да... давай уберем все перила с балконов?
Это же ограничения.

Не нарвится тип смени. В че проблема то?
А что касается не ограниченного мышления то оно плод твоего воображения.
Мышление всегда ограничено.
Уж такие люди ограниченные создания.

N>Если у тебя нет динамической типизации, то альтернативой в случае изменения является смена API и порой радикальная. Например, в Erlang типичен возврат {error, Error} в качестве признака ошибки, где Error — произвольно сложный терм. Обычно он не анализируется (или анализируется только на типичные шаблоны). Полный анализ ведёт уже человек. Что ты дашь альтернативой при статической типизации? Базовый класс Exception?
И чем плох Exception?

N>Никаких возражений. Но это начинает работать только там, где человек намеренно загнал значение в определённые рамки — например, установил, что тут целое число от нуля до миллиона. А если не загнал?
А рамки они часть предметной области.
И если программист имея возможность сделать статические проверки их не сделал то гнать эту обезьяну из разработки поганой метлой.

WH>>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.
N>"Что там может прийти" должно быть в документации.
Обычное состояние документации:
Ее нет!
Если таки есть то устарела.
Если таки не устарела то с ошибками.

Актуальную документацию без ошибок я еще не видел. Ни разу.

А типы проверяет робот. У него не забалуешь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

N>>Я не видел, чтобы люди думали, например, "uint32", а не "целое число", кроме случаев, когда их специально приучили к специфике предметной области. И даже "шестизначное число" — это уже адаптация к специфике конкретного применения, которую ещё надо уточнить и понять (например, ведущие нули нужны или нет?)
WH>Сначала "я не видел" и тутже пошли отмазки...

Это не отмазки. Без намеренного укладывания в прокрустово ложе конкретного типа не зайдёт мысль о соответствующих ограничениях. Конечно, человек — существо гибкое и даже в таких условиях будет работать, но вообще-то они ему претят.

N>>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации. Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное мышление вытесняется рано или поздно, и неважно, в чём это ограничение — в uint32 или в борьбе рабочего класса за свои интересы.
WH>Ну да... давай уберем все перила с балконов?
WH>Это же ограничения.

И что показывает твоё сравнение? Именно то, что введение перил или типов — искусственно, ибо вызвано предшествующими действиями (создание многоэтажных домов, впихивание в конкретный тип). Более того, часто оказывается, что типы есть, а перил нет — чему равно сложение 0x5000 и 0x4000 в int16?

WH>Не нарвится тип смени. В че проблема то?

На что я его должен сменить, и почему, если мне нужно, например, представить _число_?

WH>А что касается не ограниченного мышления то оно плод твоего воображения.
WH>Мышление всегда ограничено.

В конкретный момент — да. В общем — нет.

WH>Уж такие люди ограниченные создания.

Ты хочешь уподобить людей компьютеру? Даже в тех пределах, в которых люди ограниченны — они ограничены иначе, чем компьютер.

N>>Никаких возражений. Но это начинает работать только там, где человек намеренно загнал значение в определённые рамки — например, установил, что тут целое число от нуля до миллиона. А если не загнал?
WH>А рамки они часть предметной области.

С чего ты взял?

WH>>>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.
N>>"Что там может прийти" должно быть в документации.
WH>Обычное состояние документации:
WH>Ее нет!
WH>Если таки есть то устарела.
WH>Если таки не устарела то с ошибками.

WH>Актуальную документацию без ошибок я еще не видел. Ни разу.

WH>А типы проверяет робот. У него не забалуешь.

Я до сих пор думал, что "RTFS!" это лозунг красноглазных линуксоедов. А тут он приходит почти с противоположной стороны. Непонятно...

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

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

N>>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции? Прошу чёткое решение для любого из достаточно распространённых языков. Математическую библиотеку не привлекать. И опиши, что будет в твоём проекте, если в функции такого низкого уровня будет ошибка. Сможешь ли ты опознать при запуске функционального теста, что вообще есть ошибка, и указать, в какой функции?
WH>Проверь тестами:

И давно ты стараешься отвечать вопросом на вопрос?

Я понимаю, к чему ты это рассказываешь. Но сначала ответь на мои вопросы.

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

N>Это не отмазки. Без намеренного укладывания в прокрустово ложе конкретного типа не зайдёт мысль о соответствующих ограничениях. Конечно, человек — существо гибкое и даже в таких условиях будет работать, но вообще-то они ему претят.
Отучаемся говорить за всех.
Лично я не могу мыслить не накладывая ограничений на сущьность.
И чесно говоря не могу представить как это можно сделать.
Ведь тогда сущьность может быть чем угодно.
Как рассуждения то строить?

N>И что показывает твоё сравнение?
Это не сравнение.
Это иллюстрация того для чего нужны ограничения вообще и типы в частности.

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

N>Более того, часто оказывается, что типы есть, а перил нет — чему равно сложение 0x5000 и 0x4000 в int16?

Ошибке компиляции в системе с зависимыми типами.

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

WH>>А рамки они часть предметной области.
N>С чего ты взял?
А откуда ты их тогда взял?

N>Я до сих пор думал, что "RTFS!" это лозунг красноглазных линуксоедов. А тут он приходит почти с противоположной стороны. Непонятно...
Любой крупный проект это всегда RTSF. Исключений я еще не видел.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>>Это не отмазки. Без намеренного укладывания в прокрустово ложе конкретного типа не зайдёт мысль о соответствующих ограничениях. Конечно, человек — существо гибкое и даже в таких условиях будет работать, но вообще-то они ему претят.
WH>Отучаемся говорить за всех.
WH>Лично я не могу мыслить не накладывая ограничений на сущьность.

Те ограничения, о которых ты говоришь, искусственны.

N>>И что показывает твоё сравнение?
WH>Это не сравнение.
WH>Это иллюстрация того для чего нужны ограничения вообще и типы в частности.

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

N>>Именно то, что введение перил или типов — искусственно, ибо вызвано предшествующими действиями (создание многоэтажных домов, впихивание в конкретный тип).
WH>Чтож теперь обходится без многоэтажных домов и многомегабатных (в смысле исходного кода) программ?

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

N>>Более того, часто оказывается, что типы есть, а перил нет — чему равно сложение 0x5000 и 0x4000 в int16?

WH>Ошибке компиляции в системе с зависимыми типами.

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

N>>Ты хочешь уподобить людей компьютеру? Даже в тех пределах, в которых люди ограниченны — они ограничены иначе, чем компьютер.
WH>Когда ты работаешь с чемто то ты ограничен не только своими ограничениями но и ограничениями этого чегото.
WH>Ограничения внутри программы весьма сложны и многочисленны.
WH>И человек должен их учитывать.
WH>Но ограничения человека не позволяют следить за всем.
WH>И тут на помощь приходит компилятор.

Компилятор следит не за ограничениями, свойственными предметной области, а ограничениями, которые ты сам ввёл. У тебя есть промежуточный уровень для этого. И хорошо, если оно не позволит сложить секунды с километрами — но если не позволит сложить int16 и int32, это не есть естественное ограничение, это специфика проекции на возможности компьютера.

WH>>>А рамки они часть предметной области.
N>>С чего ты взял?
WH>А откуда ты их тогда взял?

Я? Их "взял" тот, кто укладывал на машинный язык.

N>>Я до сих пор думал, что "RTFS!" это лозунг красноглазных линуксоедов. А тут он приходит почти с противоположной стороны. Непонятно...
WH>Любой крупный проект это всегда RTSF. Исключений я еще не видел.

И часто ты читаешь код ядра Windows для реализации своего проекта?

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

WH>>Отучаемся говорить за всех.
WH>>Лично я не могу мыслить не накладывая ограничений на сущьность.
N>Те ограничения, о которых ты говоришь, искусственны.
Они естественны для модели с которой я работаю.
А работать без модели не получится даже на динамически типизируемом языке.

N>Перила возникают там, где уже есть ограничения (нельзя шагать с лестницы вбок).
Почему нельзя?
Можно.
Но будет больно. Возможно смертельно больно.
И динамикой таже байда. Оторвали перила и айда ходить где попало. Если ходить осторожно и прыгать не слишком далеко то вроде даже все хорошо. Но если оступишся костей не соберешь.

N>Зачем? Не обходиться — использовать. И статическую типизацию активно использовать, но при этом не забывать, что она вызвана, как правило, не естественными ограничениями, а спецификой укладки задачи на возможности компьютера.
"Естественность" ограничений вопрос весьма филосовский.
Но главное тут то что ты признал что ограничения есть. И отних нельза избавится.
Осталось признать что контроль ограничений машиной есть благо, а не как тут пытаются всех убедить что зло великое есть сие.

N>Вот именно, что ты выбрал только один вариант из многих возможных. Но вариант в духе Си (не заметили вообще, что есть какая-то проблема) не сильно лучше.
Переполнение для int16 не имеет смысла.
Для uint16 возможны варианты.
Но лично я бы предпочел отдельный тип. Например uintmod16 чтобы ясно дать понять что у нас тут арифметика по модулю.

N>Компилятор следит не за ограничениями, свойственными предметной области, а ограничениями, которые ты сам ввёл. У тебя есть промежуточный уровень для этого. И хорошо, если оно не позволит сложить секунды с километрами —
Ты всегда работаешь с моделью предметной области.
И у модели есть ограничения.
Вот за ними компилятор и следит.

N>но если не позволит сложить int16 и int32, это не есть естественное ограничение, это специфика проекции на возможности компьютера.
Ессно любой уважающий себя компилятор такое позволит.

N>И часто ты читаешь код ядра Windows для реализации своего проекта?
А они где?
Но вот код библиотек .НЕТ рефлектором смотреть приходилось.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

Потому что водораздел в характеристиках м/у динамикой и статикой стерся. Тут даже не о чем спорить.
Раньше у динамики был целый список преимуществ:
— метапрограммирование
— кодогенерация в рантайм (даже банальный eval("runtime-generated expression") мог решить выбор в пользу динамики)
— невозможность попортить память и прочие важные ресурсы в случае ошибок

Сейчас ни одного этого преимущества нет, ибо managed платформы все это дело обеспечили для своих статически-типизируемых языков. И скорость исполнения того самого промежуточного кода обеспечили тоже.
Так что спор превратился из динамика vs статика, в типизация vs бестиповость. И там остался только один довод в пользу динамики: это возможность запуска некоректной/неполной программы, что удобно для целей макетирования.

Но прикол в том, что для одного и того же языка со статическим выводом типов и прочей оптимизацией мог бы существовать как компилятор, так и такой динамический REPL для макетирования. Схема или Хаскель тому пример. С объектными языками беда, понятное дело, ибо непонятно что делать с незавершенными определениями типов... Но можно как в HUGS prompt, чтобы интерпретатор "глотал" корректную часть программы из файлов, а затем в REPL был доступ к "переваренным" типам для экспериментов.

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

ВВ>V8 — это реализация ECMAScript в Хроме, которая джитится. Причем джитится она напрямую, насколько я знаю, без всякого промежуточного представления. Вот, кстати, тестик, тупой по самое не могу:

ВВ>

ВВ>var list = [];
ВВ>var size = 1000;

ВВ>for (var i = 0; i < size; i++)
ВВ>    list[i] = size - i;

ВВ>function BubbleSort(item)
ВВ>{  
ВВ>    for(var i = 0; i < item.length; i++)
ВВ>    {
ВВ>        for(var j = 0; j < item.length - i - 1; j++)
ВВ>        {
ВВ>            if(item[j + 1] < item[j])
ВВ>            {
ВВ>                var x = item[j];
ВВ>                item[j] = item[j + 1];
ВВ>                item[j + 1] = x;
ВВ>            }
ВВ>        }
ВВ>    }
ВВ>};

ВВ>BubbleSort(list);
ВВ>

ВВ>JScript MSIE8 — 367
ВВ>V8 — 22

ВВ>Как видишь, разница некислая все же.

А это в каких попугаях измерялось? Не уж то в секундах?

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

ВВ>>Как видишь, разница некислая все же.
VD>А это в каких попугаях измерялось? Не уж то в секундах?

В миллисекундах, конечно.

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

WH>>>Отучаемся говорить за всех.
WH>>>Лично я не могу мыслить не накладывая ограничений на сущьность.
N>>Те ограничения, о которых ты говоришь, искусственны.
WH>Они естественны для модели с которой я работаю.

Вот именно, что с которой _ты_ работаешь. Это включает в себя не только персональную ограниченность опыта, но и временную. А что будет, когда она будет меняться? А она таки будет меняться.

WH>А работать без модели не получится даже на динамически типизируемом языке.

Не получится, не спорю. Но дальше вопрос — пределы её гибкости.

N>>Перила возникают там, где уже есть ограничения (нельзя шагать с лестницы вбок).
WH>Почему нельзя?
WH>Можно.
WH>Но будет больно. Возможно смертельно больно.
WH>И динамикой таже байда. Оторвали перила и айда ходить где попало. Если ходить осторожно и прыгать не слишком далеко то вроде даже все хорошо. Но если оступишся костей не соберешь.

Нет, динамика не "та же байда", что отсутствие перил. Как раз просто перила — это динамика: тебя ограничили только от невольных ошибок. А когда тебя зажали в узкую полосу на лестнице и обрешётили, как в ментовке — это статика. Точнее, даже не так: тебя ещё ставят на рельсы.

Чтобы катился быстро. Да, это будет быстрее. Но с соответствующими проблемами: например, ты сможешь пройти сам, но не сможешь пронести два пакета еды — для них банально не хватит места.

Вообще, эти аналогии всегда хромают и поэтому смешны. Предлагаю избавиться от них.

N>>Зачем? Не обходиться — использовать. И статическую типизацию активно использовать, но при этом не забывать, что она вызвана, как правило, не естественными ограничениями, а спецификой укладки задачи на возможности компьютера.
WH>"Естественность" ограничений вопрос весьма филосовский.
WH>Но главное тут то что ты признал что ограничения есть. И отних нельза избавится.

Не считаю это "главным". Ограничения есть всегда. Но есть принципиальная разница как минимум между следующими тремя категориями
1) естественные ограничения (например, законы сохранения)
2) ограничения укладки в модель
3) ограничения укладки на возможности компьютера

и, во-первых, ты явно нечётко разделяешь (2) и (3). Во-вторых, статическая типизация — это именно (3), в то время как человек, не зажатый явно в рамки применяемой системы типов, мыслит на уровне (1) и (2). Статическая типизация как процесс — в основном переход от (2) к (3). Тут у тебя обязательно int16, а тут — int32 (а завтра потребуют не экономить байты, а хранить числа до миллиона — int16 пойдёт лесом). Тут у тебя обязательно два возвращаемых значения, а третье уже не лезет. Тут у тебя ошибка — целое (и надо хитрым образом распределять диапазоны значений — системные налево, библиотечные направо, свои — прямо и вверх через левое ухо). И тэ дэ и тэ пэ. Цена статики — та же, что её преимущество — чёткая определённость. Надо изменить возможности, особенно расширить — надо ломать интерфейс.

В Erlang я могу передать любые уточнения как элементы списка свойств (proplist), если функция в принципе принимает подобные уточнения. Аналогично со всеми динамическими языками. В статике получаются монстры в стиле CreateFile(), которые тут же устаревают, не успев выпуститься (ты можешь указать в ней путь относительно каталога, заданного другим хэндлом, как в юниксовой openat()?)

WH>Осталось признать что контроль ограничений машиной есть благо, а не как тут пытаются всех убедить что зло великое есть сие.

Я не знаю, кто тут "пытается убедить" что "зло великое". Я говорю, что это благо только на нижнем уровне. На верхнем оно действительно становится злом (великим или нет — вопрос эмоций, не учитываем). Хорошая аналогия из сетевого мира: на нижних уровнях протокольного стека по максимуму используются двоичные форматы посылок с фиксированным размещением и смыслом полей, иначе просто времени не хватит на элементарные операции типа форварда пакета. Но на верхних уровнях ситуация совсем другая — в завивисимости от лагеря, это или ASN.1 с двоичными кодеками (ISO), или текстовые протоколы (IETF). А всё почему? — потому что подобные форматы не только сконструированы как расширяемые и пригодные выдержать что угодно (чему равно максимально представимое целое в BER?

, но и принципиально неограничиваемые — ты не можешь придумать в рамках ASN.1+BER, не нарушая правила, как сделать нерасширяемый формат посылки. А любая мультиформатность — это уже динамика: ты в рантайме определяешь, что пришло и как с этим работать.

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

N>>Вот именно, что ты выбрал только один вариант из многих возможных. Но вариант в духе Си (не заметили вообще, что есть какая-то проблема) не сильно лучше.
WH>Переполнение для int16 не имеет смысла.

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

WH>Для uint16 возможны варианты.
WH>Но лично я бы предпочел отдельный тип. Например uintmod16 чтобы ясно дать понять что у нас тут арифметика по модулю.

Да, в статически типизированном языке это хороший вариант.

N>>Компилятор следит не за ограничениями, свойственными предметной области, а ограничениями, которые ты сам ввёл. У тебя есть промежуточный уровень для этого. И хорошо, если оно не позволит сложить секунды с километрами —
WH>Ты всегда работаешь с моделью предметной области.
WH>И у модели есть ограничения.
WH>Вот за ними компилятор и следит.

Нет, он за ними не следит. Следит за тем, что ты ввёл в модель типов. Проекцию же на неё выполняешь ты, как программист. Тебе это позволяет получать нужный результат, например, в духе твоего примера — невалидный HTML на выходе невозможен. Но это ты сделал, и ты контролируешь, например, что используются _только_ твои типы. Если у тебя выходная функция будет конвертировать выдачу в текст и приписывать к нему "<a<<<baba<<<galamaga<<<<", как у тебя это отловится? Да никак, потому что ты где-то по любому должен был перевести в текст, и тут к тебе врывается реальный мир.

N>>но если не позволит сложить int16 и int32, это не есть естественное ограничение, это специфика проекции на возможности компьютера.
WH>Ессно любой уважающий себя компилятор такое позволит.

Дааа? Ты зря так думаешь. В Go специально запретили такие вещи — более того, если у тебя int и int32 имеют одинаковую размерность, то всё равно нужна явная конверсия между ними. И мне кажется, что это значительно правильнее для дела ~~Света~~ статической типизации.

N>>И часто ты читаешь код ядра Windows для реализации своего проекта?
WH>А они где?

Для NT4 и части W2000 валяется на каждом углу. Для более нового не видел.

WH>Но вот код библиотек .НЕТ рефлектором смотреть приходилось.

Значит, плохая документация.

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

N>1) естественные ограничения (например, законы сохранения)
N>2) ограничения укладки в модель
N>3) ограничения укладки на возможности компьютера

N>и, во-первых, ты явно нечётко разделяешь (2) и (3).
А это одно и тоже.
Ибо нет смысла делать модель которую нельзя впихнуть в компьтер.

А номер 1 это вообще смех на палочке.
Какие "естественные" ограничения у компилятора? А у бугалтерской программы? А у веб сайта?...

Программ которые имеют дело с твоими "естественными" ограничениями ничтожно малое колличество.

N>Во-вторых, статическая типизация — это именно (3), в то время как человек, не зажатый явно в рамки применяемой системы типов, мыслит на уровне (1) и (2).
1 не существует для почти 100% задач. 2-3 одно и тоже ибо не имеет смысла строить модель программы в отрыве от того где эта программа будет исполняться.

N>Цена статики — та же, что её преимущество — чёткая определённость. Надо изменить возможности, особенно расширить — надо ломать интерфейс.
Это не цена. Это всегда преимущество.
Вот буквально вчера делал рефакторинг для дальнейшего расширения функциональности.
Началось все с:

     -         private _rule : Rule;
     +         private _rule : option[Rule];

И вот к чему привело http://code.google.com/p/nemerle/source/detail?r=9272
После этих правок все скомпилировалось и заработало с первой попытки.
В процессе ничего сломано небыло.
Все места для правки показал компилятор.

А теперь скажи мне как мне проделать тоже самое с динамической типизацией?
Я просто не представляю как можно провести столько изменений без помощи роботов и ничего не сломать.

Может программисты на динамически типизированных языках мега гении и могут держать в голове всю программу?
Тогда не ясно почему вы до сих пор не захватили мир?

N>В Erlang я могу передать любые уточнения как элементы списка свойств (proplist), если функция в принципе принимает подобные уточнения.
Ты блин не поверишь.
Если функция принимает подобные уточнения то я тебе тоже самое и в статически типизированном языке на раз сделаю.

N>Аналогично со всеми динамическими языками. В статике получаются монстры в стиле CreateFile(), которые тут же устаревают, не успев выпуститься (ты можешь указать в ней путь относительно каталога, заданного другим хэндлом, как в юниксовой openat()?)
Не делай мне смешно.
Это просто два разных подхода.
Мелкософты сделали одну навороченную функцию. Линуксойды сделали кучу специализарованных.
Никакого отношения к типизации это не имеет.

И лично я считаю что обе реализации говно.
Ибо завязаны на глобальные переменные.
Сам пойемешь где я их нашол или подсказать?
Хотя это тема для отдельного флейма.

N>Но на верхних уровнях ситуация совсем другая — в завивисимости от лагеря, это или ASN.1 с двоичными кодеками (ISO),
Ты опять делаешь мне смешно.
Приводить ASN.1 в качестве защиты динамики...
Нука раскажи что это такое если не описание типов:

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }

END

N>Этого не понял. В каком смысле оно не имеет смысла? Нельзя допускать, чтобы оно происходило? Ну так ведь допускают, если не попросить.

Ну в Сях много чего допускают что не имеет смысла.

N>Нет, он за ними не следит. Следит за тем, что ты ввёл в модель типов. Проекцию же на неё выполняешь ты, как программист. Тебе это позволяет получать нужный результат, например, в духе твоего примера — невалидный HTML на выходе невозможен. Но это ты сделал, и ты контролируешь, например, что используются _только_ твои типы. Если у тебя выходная функция будет конвертировать выдачу в текст и приписывать к нему "<a<<<baba<<<galamaga<<<<", как у тебя это отловится? Да никак, потому что ты где-то по любому должен был перевести в текст, и тут к тебе врывается реальный мир.
Если какойто гоблин начал специально обходить защиту компилятора это он сам себе злобный буратино.
Нормальный человек это делать не будет.
Так что мимо.

N>Дааа? Ты зря так думаешь. В Go специально запретили такие вещи — более того, если у тебя int и int32 имеют одинаковую размерность, то всё равно нужна явная конверсия между ними.
Про Go и его авторов у меня есть исключительно не цензурные соображения.

N>И мне кажется, что это значительно правильнее для дела ~~Света~~ статической типизации.
Ты обратился не по адресу.
Я исключительно прагматичен.

N>Значит, плохая документация.
Так а я о чем? И она вся такая.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>>1) естественные ограничения (например, законы сохранения)
N>>2) ограничения укладки в модель
N>>3) ограничения укладки на возможности компьютера
N>>и, во-первых, ты явно нечётко разделяешь (2) и (3).
WH>А это одно и тоже.
WH>Ибо нет смысла делать модель которую нельзя впихнуть в компьтер.

Нет. Потому что есть возможности компьютера, а есть _укладка_ на возможности компьютера. Чтобы чётче объяснить — компьютер может работать со сверхдлинными числами, но естественный размер — 16, 32, 64 бита.

WH>А номер 1 это вообще смех на палочке.
WH>Какие "естественные" ограничения у компилятора?

Например, то, что он не может выполнить бесконечный цикл при компиляции программы (напоминаю, что, например, язык шаблонов C++ тьюринг-полон).

WH> А у бугалтерской программы?

Правила схождения дебета с кредитом.

WH> А у веб сайта?...

Зависит от содержания сайта, но ряд общих правил работает и тут.

WH>Программ которые имеют дело с твоими "естественными" ограничениями ничтожно малое колличество.

Наоборот, таких очень много — почти все.

N>>Во-вторых, статическая типизация — это именно (3), в то время как человек, не зажатый явно в рамки применяемой системы типов, мыслит на уровне (1) и (2).
WH>1 не существует для почти 100% задач. 2-3 одно и тоже ибо не имеет смысла строить модель программы в отрыве от того где эта программа будет исполняться.

По сказанному выше это грубо неверно.

N>>Цена статики — та же, что её преимущество — чёткая определённость. Надо изменить возможности, особенно расширить — надо ломать интерфейс.
WH>Это не цена. Это всегда преимущество.
WH>Вот буквально вчера делал рефакторинг для дальнейшего расширения функциональности.
WH>Началось все с:
WH>

WH>     -         private _rule : Rule;
WH>     +         private _rule : option[Rule];
WH>

WH>И вот к чему привело http://code.google.com/p/nemerle/source/detail?r=9272
WH>После этих правок все скомпилировалось и заработало с первой попытки.
WH>В процессе ничего сломано небыло.
WH>Все места для правки показал компилятор.

WH>А теперь скажи мне как мне проделать тоже самое с динамической типизацией?

Не буду даже пытаться сказать, потому что не знаю Nemerle. Приведи plz пример на чём-то более общеупотребительном.

WH>Я просто не представляю как можно провести столько изменений без помощи роботов и ничего не сломать.

Если изменения внутренние, их может отработать компиляция. Далее — тестирование. Не собираюсь говорить, что это 100% эквивалентный подход, но практически он оказывается достаточно сходным по результатам, чтобы можно было использовать и не страдать об этом.

WH>Может программисты на динамически типизированных языках мега гении и могут держать в голове всю программу?

Зачем?

WH>Тогда не ясно почему вы до сих пор не захватили мир?

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

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

N>>В Erlang я могу передать любые уточнения как элементы списка свойств (proplist), если функция в принципе принимает подобные уточнения.
WH>Ты блин не поверишь.
WH>Если функция принимает подобные уточнения то я тебе тоже самое и в статически типизированном языке на раз сделаю.

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

N>>Аналогично со всеми динамическими языками. В статике получаются монстры в стиле CreateFile(), которые тут же устаревают, не успев выпуститься (ты можешь указать в ней путь относительно каталога, заданного другим хэндлом, как в юниксовой openat()?)
WH>Не делай мне смешно.
WH>Это просто два разных подхода.
WH>Мелкософты сделали одну навороченную функцию. Линуксойды сделали кучу специализарованных.

А, так ты даже описания не прочитал? Ну и расскажи, как эта одна навороченная функция поможет сделать то, что я описал? Как говорят коллеги, иди учи матчасть.

WH>И лично я считаю что обе реализации говно.
WH>Ибо завязаны на глобальные переменные.
WH>Сам пойемешь где я их нашол или подсказать?
WH>Хотя это тема для отдельного флейма.

Вот именно, что отдельного.

N>>Но на верхних уровнях ситуация совсем другая — в завивисимости от лагеря, это или ASN.1 с двоичными кодеками (ISO),
WH>Ты опять делаешь мне смешно.
WH>Приводить ASN.1 в качестве защиты динамики...
WH>Нука раскажи что это такое если не описание типов:
WH>

WH>FooProtocol DEFINITIONS ::= BEGIN

WH>    FooQuestion ::= SEQUENCE {
WH>        trackingNumber INTEGER,
WH>        question       IA5String
WH>    }

WH>    FooAnswer ::= SEQUENCE {
WH>        questionNumber INTEGER,
WH>        answer         BOOLEAN
WH>    }

WH>END
WH>

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

N>>Нет, он за ними не следит. Следит за тем, что ты ввёл в модель типов. Проекцию же на неё выполняешь ты, как программист. Тебе это позволяет получать нужный результат, например, в духе твоего примера — невалидный HTML на выходе невозможен. Но это ты сделал, и ты контролируешь, например, что используются _только_ твои типы. Если у тебя выходная функция будет конвертировать выдачу в текст и приписывать к нему "<a<<<baba<<<galamaga<<<<", как у тебя это отловится? Да никак, потому что ты где-то по любому должен был перевести в текст, и тут к тебе врывается реальный мир.
WH>Если какойто гоблин начал специально обходить защиту компилятора это он сам себе злобный буратино.
WH>Нормальный человек это делать не будет.
WH>Так что мимо.

Так в этом месте вообще защиты быть не может. Так что мимо

N>>Дааа? Ты зря так думаешь. В Go специально запретили такие вещи — более того, если у тебя int и int32 имеют одинаковую размерность, то всё равно нужна явная конверсия между ними.
WH>Про Go и его авторов у меня есть исключительно не цензурные соображения.

Ну и зря. Очень толковые ребята с неплохим результатом.

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

N>Нет. Потому что есть возможности компьютера, а есть _укладка_ на возможности компьютера. Чтобы чётче объяснить — компьютер может работать со сверхдлинными числами, но естественный размер — 16, 32, 64 бита.
И че? Мне оно до лампочки. Если мне нужны длянные числа у меня будут длинные числа.

N>Например, то, что он не может выполнить бесконечный цикл при компиляции программы (напоминаю, что, например, язык шаблонов C++ тьюринг-полон).
И что ты этим сказать то хотел?

WH>> А у бугалтерской программы?
N>Правила схождения дебета с кредитом.
И где они в природе?
Это модель придуманая человеком для ведения учета.

WH>> А у веб сайта?...
N>Зависит от содержания сайта, но ряд общих правил работает и тут.
Каких?
Только давай таких чтобы из природы.
Или бесконечный цикл и выжирание памяти все что можешь придумать?

WH>>А теперь скажи мне как мне проделать тоже самое с динамической типизацией?
N>Не буду даже пытаться сказать, потому что не знаю Nemerle. Приведи plz пример на чём-то более общеупотребительном.
Там был изменен тип одной переменной.
Раньше значение было всегда.
А теперь стало опциональным.
Теперь везде где идет обращение к этой переменной нужно вставить проверки.
В случае со статикой мне все места где нужно проверить показал компилятор.
В случае с динамикой мне никто и ничего не раскажет.

N>Если изменения внутренние, их может отработать компиляция. Далее — тестирование. Не собираюсь говорить, что это 100% эквивалентный подход, но практически он оказывается достаточно сходным по результатам, чтобы можно было использовать и не страдать об этом.
Другими словами нужно сделать много больше работы с не гарантированным результатом.
Ну и где профит?

WH>>Может программисты на динамически типизированных языках мега гении и могут держать в голове всю программу?
N>Зачем?

Чтобы не забыть все поправить.

N>Ты ответь на предыдущий вопрос — почему ты считаешь, что "программистам на динамически типизированных языках" надо держать в голове всю программу.
А как иначе понимать что вообще происходит?
От компилятора то подсказки недождешся.

N>Не спорю, сделаешь. Но как ты сделаешь, например, правило, что в случае наличия параметра X не может быть задан параметр Y, если Y поступает только в переменной части? Отработка этой проверки при компиляции невозможна, потому что невозможно знать, кто и с чем вызовет. Вот у тебя и получается в результате проверка в рантайме, сиречь та самая динамика.
Зависимыми типами я тебе что угодно проверю.
Было бы жилание.
Впорос в том а нахрена эти сложности вообще нужны?
Можешь привести пример?

N>А, так ты даже описания не прочитал? Ну и расскажи, как эта одна навороченная функция поможет сделать то, что я описал? Как говорят коллеги, иди учи матчасть.
Что учить?
И причем тут вообще динамика?
А функциональность этой функции вообще за гранью моего понимания.
Она не нужна.

N>Ну конечно, привёл пример фиксированной структуры и успокоился... Представь себе, что завтра выходит новая версия стандарта, где у этой sequence ещё три возможных компонента. И тут твой конвертер представлений резко сломался...
Какой конвертер?
Каких представлений?

WH>>Если какойто гоблин начал специально обходить защиту компилятора это он сам себе злобный буратино.
WH>>Нормальный человек это делать не будет.
WH>>Так что мимо.
N>Так в этом месте вообще защиты быть не может. Так что мимо

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

N>Ну и зря. Очень толковые ребята с неплохим результатом.
Я уже ругался на эту тему
http://www.rsdn.ru/forum/philosophy/3598807.1.aspx
И это не полный список.
Единственное что я не заметил при написании того сообщения это поддержку детерминированной финализации. В прочем она у них сделана столь дебильно что даже С++ и тот лучше.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

WH>>> А у веб сайта?...
N>>Зависит от содержания сайта, но ряд общих правил работает и тут.
WH>Каких?
WH>Только давай таких чтобы из природы.

одна комната много детей

Задача исключительно алгоритмической природы. Статика тут не поможет никак.

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

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

Потому что в web-е распространен подход — 'quick and dirty', то есть, мы быстро выкатываем первую версию приложения, в которой скорее всего будут баги и в которой не будет 90% нужного функционала, ны мы оперативно допилим это после. Почему такой подход получил распространение именно в web тоже достаточно легко объяснимо — именно там мы можем легко и оперативно заменить приложение сразу для всех пользователей.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

M>одна комната много детей
M>Задача исключительно алгоритмической природы. Статика тут не поможет никак.
1)Ограничения не естественные, а придуманные человеком.
2)Как тут поможет динамика?
3)Я рамках PEG прасера для немерле я решил почти идентичную задачу.

В задаче не сказано но я имею наглость предположит:
Список отелей меняется редко.
Правила в отеле еще реже.
Таким образом список паттернов у нас весьма стабилен. Даже изменение этого списка раз в час (хотя реально это будет несколько раз в месяц) не будет проблемой для моего решения.

Первое что нужно понять это то что у нас нет ни взрослых ни детей.
А образцы имеют вид не

1 ADL + 1 CHLD 0-6 + 1 CHLD 12-13
2 ADL + 2 CHLD 12-13

а

0-6 12-13 14-999
12-13 12-13 14-999 14-999

Каждый образец связан с кортежем (отель, тип комнаты, цена)

Теперь каждый образец мы превращаем в конечный автомат при достижении конца которого он выдает список кортежей соответствующих этому образцу.
Теперь все автоматы объеданяем а один НДКА. После чего трансформируем это дело в ДКА.
Теперь генерируем код.
Примерно как тут
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/LRPEGCC/Compiler/RuleCompiler.CompileRule.n
нужная секция идет после

| Fsm(fsm)               =>

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

DAS> Потому что в web-е распространен подход — 'quick and dirty',

И что из этого является препятствием для использования статически-типизированных языков?

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

L>И что из этого является препятствием для использования статически-типизированных языков?

Ты про Haskell что ли?

Да никаких.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

M>>одна комната много детей
M>>Задача исключительно алгоритмической природы. Статика тут не поможет никак.
WH>1)Ограничения не естественные, а придуманные человеком.

Что такое естественные ограничения? Для меня естественные — это именно придуманные человеком. Естественнее не бывает.

WH>2)Как тут поможет динамика?

А как тут поможет статика? Ты тут апологет того, что «статика — труъ и помогает всегда». Я показал пример задачи, которая должна решаться на веб-сайте, и где от того, какая типизация будет в языке, ни холодно ни жарко.

WH>3)Я рамках PEG прасера для немерле я решил почти идентичную задачу.

И?

WH> Решение задачи, автоматы и т.п. поскипано.

Ну и при чем тут статика? Или автоматы нельзя на динамике делать?

WH>Примерно как тут
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/LRPEGCC/Compiler/RuleCompiler.CompileRule.n
WH>нужная секция идет после
WH>

WH>| Fsm(fsm)               =>
WH>

WH>Гоняться с этим решением ты озвереешь.
WH>Ибо обогнать близкий к оптимальному машиннай код задачка не для слабонервных.

Опять начинается сферовакуум. В моем случае мне даром не надо что-либо обгонять, потому что узкое место в данном случае — попытка загнать результаты в базу данных или вообще любое хранилище. Вот и нахрена мне там непревзойденная скорость статики? Только чтобы потом пенисометрией на РСДН заниматься?

M>>Вот это — верх аргументации, ага.
WH>Ты бы почитал на что я отвечал.
WH>Одна из фраз вообще твоя. Я там просто несколько слов изменил для того чтобы продемонстрировать тебе ущербность твоей логики. Но похоже не помогло.

Там нет моих фраз.

M>>Никому не нужна сферовакуумная скорость в отрыве от задачи. Если динамически типизируемый Erlang дает мне обработать 5000 запросов в секунду при том, что у меня пиковая нагрузка 1000, то зачем мне нужен статически типизируемый C#, например?
WH>Это пока ты остаешься в рамках.
WH>Но шаг в сторону и превет.

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

WH>Если нужно что-то посчитать начинаются тормоза.

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

WH>Скажем при помощи этого http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser#peg-parser/CSharp
WH>Я могу парсить C#4 со скорость 2 мегабайта в секунду.
WH>Слабо повторить на ерланге?

Зачем? Но при желании, думаю можно приблизиться к этим цифрам. Другой вопрос — насколько часто это требуется.

M>>Ошибки на этапе компиляции — это очень малая часть всех ошиок, что встречаются в программировании. Даже здесь, в «философии программирвания» про это говорили, и не раз, со ссылками на исследования и т.п.
WH>Да мне плевать что кто-то что-то там писал.

Да тебе на все наплевать, кроме своих наркотиков

WH>http://www.impredicative.com/ur/
WH>Вот попробуй тестами гарантировать отсутствие перечисленных проблем.
WH>

WH>Not only do they not crash during particular page generations, but they also may not:
WH> * Suffer from any kinds of code-injection attacks

статика этого тоже не гарантирует

WH> * Return invalid HTML

статика этого тоже не гарантирует

WH> * Contain dead intra-application links

статика этого тоже не гарантирует

WH> * Have mismatches between HTML forms and the fields expected by their handlers

статика этого тоже не гарантирует

WH> * Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides

статика этого тоже не гарантирует

WH> * Attempt invalid SQL queries

статика этого тоже не гарантирует

WH> * Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

статика этого тоже не гарантирует

что ты хотел сказать-то?

M>>Процитирую
WH>Ты не забывай заголовки читать... а то смешно получается.
WH>

WH>Static Typing Where Possible, Dynamic Typing When Needed

WH>Если у тебя есть помойка со слабо структуированными данными то приходится как то выкручиваться.
WH>Но это очень редкий случай.

это самый распространенный на данный момент случай.

WH>Но и тут польза динамической типизации мягко говоря не очевидна.
WH>Ну во есть у тебя какая то байда в которой есть не поймешь что.
WH>И что дальше?
WH>Ну загрузил ты это все в объект.
WH>И что дальше?
WH>Обратишься к полю по имени? А если там ничего нет? Данные то у нас структуированы как попало.

case proplists:get_value(a, Object) of
    undefined ->
        {error, {undefined_value, a}}

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

WH>Что делать?
WH>Схлопывать ласты?
WH>Или проверять есть ли у объекта поле?
WH>И так на каждое поле. И каждый подобъект. И так до бесконечности.

если надо, проверим. если не надо, не проверим. в чем проблема-то?

WH>Теперь сравним со статикой:
WH>Описал тип.
WH>И макросом сгенерировал для этого типа читалку которая проверяет наличие всех нужных нам полей. Если поле опционально то Option никто не отменял.

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

о, например, в Lisp'е, раз ты о макросах завел речь.

WH>Итого:
WH>Статика:
WH>1)Проверка структуры декларативна.

что бы это ни значило

WH>2)Автокомплит, рефакторинг, навигация,...

и как это еу же JetBrains ухитряются то же для Питона делать, просто поражаюсь

WH>3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.

Очень малая часть ошибок.

WH>4)Скорость работы высокая.

Опять эта мифическая никому не нужная сферовакуумная скорость в отрыве от задачи.

WH>Динамика:
WH>1)Проверки структуры императивны и размазаны по всей программе.

Фиг его знает, что ты тут имеешь в виду.

WH>2)Поддержки IDE нет. Ибо структура объекта не извесна. И взять ее негде.

и как это еу же JetBrains ухитряются то же для Питона делать, просто поражаюсь

WH>3)Компилятор молчит.

Да ты что. Неужели.

WH>4)Тормоза.

Опять эта мифическая никому не нужная сферовакуумная скорость в отрыве от задачи.

WH>Где профит то?

Профит у людей, которые не думают о языках в терминах сферовакуумности того или иного языка.

M>>Нет. У меня есть опыт компании, разрабатывавшей Erlang, и использующей его в гигантском проекте. Оказалось, что преимуществ статическая типизация им не дает.
WH>У тебя есть демагогия: Аппеляция к толпе. Аппеляция к авторитету.
WH>Технических аргументов нет.

О да. Они есть у тебя. «Вот у меня есть сферовакуумный язык у него есть сферовакуумная скорость. А так, мои представления о динамических языках застыли на уровне конца 80-х годов»

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

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

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

DAS> Потому что в web-е распространен подход — 'quick and dirty', то есть, мы быстро выкатываем первую версию приложения, в которой скорее всего будут баги и в которой не будет 90% нужного функционала, ны мы оперативно допилим это после. Почему такой подход получил распространение именно в web тоже достаточно легко объяснимо — именно там мы можем легко и оперативно заменить приложение сразу для всех пользователей.

А что мешает делать тоже самое с java, c# и даже с++?

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

G>А что мешает делать тоже самое с java, c# и даже с++?

Тем, что 'quick' в c++ выходит у слишком 'dirty'. Хотя бы из-за неаккуратной работы с памятью.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

G>>А что мешает делать тоже самое с java, c# и даже с++?

DAS> Тем, что 'quick' в c++ выходит у слишком 'dirty'. Хотя бы из-за неаккуратной работы с памятью.

Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

WH>Итого:
WH>Статика:
WH>1)Проверка структуры декларативна.
WH>2)Автокомплит, рефакторинг, навигация,...
WH>3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.
WH>4)Скорость работы высокая.

После того появляется Tim Bray с WideFinder Benchmark и говорит:

There is a wrinkle; I'm pretty sure some of the numbers will get out of 32-bit integer range.

И все, приплыли. Если кто пропустит эту фразу, вылетит в рантайме с Exception'ом, который Мегаумный Компилятор, Который Ловит Все Ошибки (TM) отловить, естественно не сможет. Хотя скорость, соглашусь, будет большая. Правда, всего на порядок больше, чем у динамики. И, возможно, на 2 порядка больше кода. Но зато скорость!!!!одинодинодинодин.

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

G>Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

Ну, все это всего лишь мое мнение, но:

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

Они более многословны. Ну то есть, чтобы отдать одну строку барузеру в Java мне придется реализовать класс, в нем метод. При этом надо не забыть какие там области видимости указать и типы принимаемых и возвращаемых значений. Далее надо вспомнить, какие пакеты надо импортировать, чтобы реадизовать нужное. Естественно я не рассматриваю готовые фреймворки.

В Ruby/Python/Perl это достигается в одну строку.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

G>>>А что мешает делать тоже самое с java, c# и даже с++?

DAS>> Тем, что 'quick' в c++ выходит у слишком 'dirty'. Хотя бы из-за неаккуратной работы с памятью.

G>Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

Когда Веб взлетал, java проталкивалась на десктопы, а .NET только рождался. Сейчас и первый и второй в вебе представлены очень широко.

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

DAS> В Ruby/Python/Perl это достигается в одну строку.

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

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

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

G>>Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

DAS> Ну, все это всего лишь мое мнение, но:

DAS>

У них больше порог вхождения, чем у динамических языков. В Java надо знать что такое класс, как минимум. В Net, если не ошибаюсь, тоже.
DAS>

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

DAS> В Ruby/Python/Perl это достигается в одну строку.
А без готовых фреймворков?

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

G>>>>А что мешает делать тоже самое с java, c# и даже с++?

DAS>>> Тем, что 'quick' в c++ выходит у слишком 'dirty'. Хотя бы из-за неаккуратной работы с памятью.

G>>Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

M>Когда Веб взлетал, java проталкивалась на десктопы, а .NET только рождался. Сейчас и первый и второй в вебе представлены очень широко.
Да я то знаю, вот убеждение что на динамических языках что-то там проще делается меня удивляет.

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

ВВ>По поводу Perl не знаю, но то, что Ruby и Python ниже порого вхождения, чем, скажем, у C#... Эта мысль мне кажется несколько сомнительной. Ну начнем хотя бы с того, что там вообще-то тоже надо знать, что такое "класс".

Там полезно знать, что такое класс. Но можно писать и в функциональном стиле.

print "Hello, world"

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>Выделенное доставило

А в чем проблема то, я же рассматриваю Ruby и Python тоже без фреймворков.
Или ты предлагаешь Rails и Django подключить?

G>А без готовых фреймворков?

Да.

   print '<h1>Hello, world</h1>'

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ВВ>>По поводу Perl не знаю, но то, что Ruby и Python ниже порого вхождения, чем, скажем, у C#... Эта мысль мне кажется несколько сомнительной. Ну начнем хотя бы с того, что там вообще-то тоже надо знать, что такое "класс".
DAS> Там полезно знать, что такое класс. Но можно писать и в функциональном стиле.

Это уже двойные стандарты товарищ. На Шарпе или Джаве тоже можно писать, не имея понятия, что такое класс.
А писать в функциональном стиле на Руби (где нет первоклассных функций) да и на Питоне не очень-то удобны. Это в первую очередь объектно-ориентированные языки. Руби вообще создавался со стремлением сделать "правильный" и чистый ООЯ. И это далеко не примитивные языки. Примитивным был тот же C# в версии 1.0, Джава на ранних стадиях.

DAS> print "Hello, world"

Console.WriteLine("Hello, world!")?

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

DAS>

DAS>   print '<h1>Hello, world</h1>'
DAS>

Это на каком языке?

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

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

G>>Выделенное доставило

DAS> А в чем проблема то, я же рассматриваю Ruby и Python тоже без фреймворков.
DAS> Или ты предлагаешь Rails и Django подключить?
Конечно, разве без них кто-то пишет?

G>>А без готовых фреймворков?

DAS> Да.

DAS>

DAS>   print '<h1>Hello, world</h1>'
DAS>

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

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

ВВ>Console.WriteLine("Hello, world!")?

Но это ведь не будет работать, в отличии от приведенного мною примера

Давай я поправлю:

     public class HelloWorld {
        public static void main(String[] args) {
         System.out.println("Hello world!");
        }
     }

BB>А писать в функциональном стиле на Руби (где нет первоклассных функций)

Есть Proc и code-blocks. Но это как то в сторону разговор уходит.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ВВ>Это на каком языке?

Python. Если я заменю print на puts будет Ruby.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

G>Конечно, разве без них кто-то пишет?

Ну, тогда у меня вопрос — а что есть в Net уровня Django и Rails для web разработки?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ВВ>>Console.WriteLine("Hello, world!")?
DAS> Но это ведь не будет работать, в отличии от приведенного мною примера

Приведенный вами пример тоже работать не будет, так что все честно.

BB>>А писать в функциональном стиле на Руби (где нет первоклассных функций)
DAS> Есть Proc и code-blocks. Но это как то в сторону разговор уходит.

Это не первоклассные функции. Потом, извините, что за фигня? На ООП писать нельзя потому что слишком высокий порог вхождения, в функциональном стиле можно? Там порога вхождения нет что ли? Вы считаете, что ФП для новичков понятнее, чем ООП?

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

ВВ>>Это на каком языке?
DAS> Python. Если я заменю print на puts будет Ruby.

У интерпретаторов Питона и Руби есть встроенная поддержка обработки HTTP запросов?

Я скопировал ваш код в файл с расширением *.py, положил в виртуальную папку. Не работает. Что я сделал не так?
Подскажи, что мне надо настроить и какие фреймворки мне надо подключить, чтобы это заработало.

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

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

G>>Конечно, разве без них кто-то пишет?

DAS> Ну, тогда у меня вопрос — а что есть в Net уровня Django и Rails для web разработки?
В .NET нету монолитного фреймворка. Есть asp.net mvc для PL, EF\Linq2SQL для доступа к данным, MEF и Unity для композиции всего этого дела и бизнес-логикой. Еще куча сторонних фреймворков с подобной функциональность.

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

ВВ>Приведенный вами пример тоже работать не будет, так что все честно.

Почему это?

ВВ> Потом, извините, что за фигня? На ООП писать нельзя потому что слишком высокий порог вхождения, в функциональном стиле можно?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

G>>Конечно, разве без них кто-то пишет?

DAS> Ну, тогда у меня вопрос — а что есть в Net уровня Django и Rails для web разработки?

По популярности — ASP.NET Web Forms, ASP.NET MVC. С точки зрения порога вхождения там все гораздо *ЛУЧШЕ*, чем в том же РОРе.
Потому что новичок:

а) качает бесплатную и красивую RAD среду для разработки
б) Нажимает на кнопочку создать веб-проект с использованием Starter Kit
в) Получает готовый шаблон сайтика, который можно программировать мышкой, не имея ни малейшего понятия об ООП. Как, кстати, некоторые и программируют. Я вот ни раз встречал таких разработчиков.

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

ВВ>У интерпретаторов Питона и Руби есть встроенная поддержка обработки HTTP запросов?

Нет, это задача web — сервера.
В .net вы aspx файлы тоже наверное под IIS разворачиваете?

ВВ>Я скопировал ваш код в файл с расширением *.py, положил в виртуальную папку. Не работает. Что я сделал не так?
ВВ>Подскажи, что мне надо настроить и какие фреймворки мне надо подключить, чтобы это заработало.

Надо настроить web-сервер — Apache, IIS или что у вас там.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ВВ>>Приведенный вами пример тоже работать не будет, так что все честно.
DAS> Почему это?

А с чего это он должен работать? Питон — это не веб-сервер, это интерпретатор.

ВВ>> Потом, извините, что за фигня? На ООП писать нельзя потому что слишком высокий порог вхождения, в функциональном стиле можно?
DAS> А при чем тут вообще функциональный стиль..... ?
DAS> Когда я писал про простоту я имел в виду, что можно весь код оформлять в виде функций, без задействования элементов декларативного программирования, про которые зашла речь.

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

G>>>>>А что мешает делать тоже самое с java, c# и даже с++?

DAS>>>> Тем, что 'quick' в c++ выходит у слишком 'dirty'. Хотя бы из-за неаккуратной работы с памятью.

G>>>Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

M>>Когда Веб взлетал, java проталкивалась на десктопы, а .NET только рождался. Сейчас и первый и второй в вебе представлены очень широко.
G>Да я то знаю, вот убеждение что на динамических языках что-то там проще делается меня удивляет.

Ну, как бы оно до сих пор часто делается проще

PHP позволяет не уходить их HTML'я вообще (что не очень хорошо, но очень просто).
Coldfusion — агалогично (несмотря на платность он очень популярен в Штатах).
У Питона есть Django, в которм две строчки кода дают тебе мегаадминку и крутой сайт.
Ruby on Rails позволяют примерно похожее.

Для Java и ASP.NET аналогичное стало появляться только весьма недавно.

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

DAS> Надо настроить web-сервер — Apache, IIS или что у вас там.

Я еще раз спрошу — в интерпретаторе Питона есть встроенное средство для обработки HTTP запросов? Хватит уже ерунду писать. Чтобы приведенный вами код работал, надо по кр. мере подключить модуль, скажем, cgi. Но это, извините, уже "фреймворк". Так я и на дотнете могу.

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

G>В .NET нету монолитного фреймворка.

Ах, нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ВВ>По популярности — ASP.NET Web Forms, ASP.NET MVC. С точки зрения порога вхождения там все гораздо *ЛУЧШЕ*, чем в том же РОРе.

Да уж, ROR просто офигительно сложен: http://www.rubyonrails.ru/screencasts.html
Пример, "Как создать блог за 15 минут". Честная и наглядная демонстрация начиная от установки rails и заканчивая запуском блога.
При том, что 99% кода Rails там сам генерит.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

ВВ> Хватит уже ерунду писать.

Похоже, что беседа вас лично задела. Извините.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

DAS> Да уж, ROR просто офигительно сложен: http://www.rubyonrails.ru/screencasts.html
DAS> Пример, "Как создать блог за 15 минут". Честная и наглядная демонстрация начиная от установки rails и заканчивая запуском блога.
DAS> При том, что 99% кода Rails там сам генерит.

А в АСП.НЕТ еще проще:
http://www.asp.net/get-started

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

ВВ>> Хватит уже ерунду писать.
DAS> Похоже, что беседа вас лично задела. Извините.

Беседа меня не задела, но объяснения, почему print "Hello, world!" должен работать в Питоне, а Console.WriteLine("Hello, world!") не должен работать в Шарпе и Джаве я от вам так и не услышал.

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

N>>Нет. Потому что есть возможности компьютера, а есть _укладка_ на возможности компьютера. Чтобы чётче объяснить — компьютер может работать со сверхдлинными числами, но естественный размер — 16, 32, 64 бита.
WH>И че? Мне оно до лампочки. Если мне нужны длянные числа у меня будут длинные числа.
N>>Например, то, что он не может выполнить бесконечный цикл при компиляции программы (напоминаю, что, например, язык шаблонов C++ тьюринг-полон).
WH>И что ты этим сказать то хотел?

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

WH>>> А у бугалтерской программы?
N>>Правила схождения дебета с кредитом.
WH>И где они в природе?
WH>Это модель придуманая человеком для ведения учета.

Это свойство "корневой" модели области, независимой от конкретной реализации.

WH>>> А у веб сайта?...
N>>Зависит от содержания сайта, но ряд общих правил работает и тут.
WH>Каких?
WH>Только давай таких чтобы из природы.

Я не говорил "из природы", ты это сам додумал и раз додумал — с собой и спорь. Я говорил "естественные". Это подразумевает не только природные свойства, но и ограничения среды, в которой это происходит и на которые нельзя повлиять. В случае веб-сайта это, как правило (но не всегда) означает, что основной выходной формат данных — HTML в определённых пределах (от 3.2 до 4.x с ограниченными элементами пятого).

WH>Или бесконечный цикл и выжирание памяти все что можешь придумать?

Говоря твоими же словами, переход на личности — признак того, что аргументы кончились. А теперь объясни, зачем ты столько слов развёл на один далеко не основной аспект? Думаешь через эту сторону опровергуть проще?

WH>>>А теперь скажи мне как мне проделать тоже самое с динамической типизацией?
N>>Не буду даже пытаться сказать, потому что не знаю Nemerle. Приведи plz пример на чём-то более общеупотребительном.
WH>Там был изменен тип одной переменной.
WH>Раньше значение было всегда.
WH>А теперь стало опциональным.
WH>Теперь везде где идет обращение к этой переменной нужно вставить проверки.
WH>В случае со статикой мне все места где нужно проверить показал компилятор.
WH>В случае с динамикой мне никто и ничего не раскажет.

Спасибо за внятное объяснение (вместо кода на маргинальном языке

) Да, пример показательный. Но и против него есть как внутренние, так и внешние возражения.
Во-первых, анализ такого рода возможен и для динамических языков (буду пока называть так), для наиболее прямого варианта использования. Грубо и на Питоне говоря, если ты пишешь a.b, он сработает, если getattr(a,'b') — нет (хотя pychecker в этом случае говорит, а почему написать не просто a.b?)
Во-вторых, если у тебя кроме собственно выбора значения ещё логика по его использованию, тебе придётся делать тест. А в этом случае ты отловишь ситуацию и в динамике. (Да, я повторяюсь.)
В-третьих, ты на самом деле сделал больше, чем тебе нужно. Тебе пришлось, кроме случаев, когда явно надо проверять значение, вставить проверки и в те места, где она не нужна по логике. Я догадываюсь, ты взял намеренно "чистый" пример, где такая проверка не нужна. Я прав? Если бы у тебя была более сложная задача и какая-то ветка выполнения имела бы это значение всегда присутствующим — тебе бы пришлось "на ровном месте" вводить дополнительную переменную, не имеющую признака optional.

N>>Если изменения внутренние, их может отработать компиляция. Далее — тестирование. Не собираюсь говорить, что это 100% эквивалентный подход, но практически он оказывается достаточно сходным по результатам, чтобы можно было использовать и не страдать об этом.
WH>Другими словами нужно сделать много больше работы с не гарантированным результатом.
WH>Ну и где профит?

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

WH>>>Может программисты на динамически типизированных языках мега гении и могут держать в голове всю программу?
N>>Зачем?

WH>Чтобы не забыть все поправить.

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

И именно вопрос, что должно войти в проекцию, является наиболее сложным в определении рамок рассмотрения для изменения (анализа, etc.) Например, моя разработка — SIP softswitch — не имеет практически никаких проблем от собственно динамической среды: это даёт наиболее грубые виды ошибок, которые ловятся элементарными тестами. Существенные ошибки начинаются там, где возникают проблемы логики функционирования. Например, акаунтинг должен быть привязан к рауту, контроллеру или UA? И в какой момент — к кому из них? Что будет при перемещении UA между контроллерами (например, при зрячем трансфере), какие параметры должны перейти к новому контроллеру, потому что логически привязаны к UA, а какие — остаться у старого? Как организовать формирование биллинговых атрибутов в случае не pickup-on-call, а pickup-on-IwR, учитывая, что часть данных вообще недоступна (поскольку INVITE-with-Replaces не авторизуется), а часть должна быть получена от ещё не существующей ноги? И тэ дэ, и тэ пэ... И как ты думаешь, волнует меня здесь то, что я формально не знаю, число или строка в конкретной переменной?

Для моих задач все твои преимущества статики — примерно как преимущество спортивного руля на Мазде RX8 по сравнению с обычным с точки зрения машиниста электровоза — ну да, если ты не успеешь убраться с переезда, мне будет обидно (но пострадаешь ты

)

N>>Ты ответь на предыдущий вопрос — почему ты считаешь, что "программистам на динамически типизированных языках" надо держать в голове всю программу.
WH>А как иначе понимать что вообще происходит?
WH>От компилятора то подсказки недождешся.

Ну если у тебя выбор только между компилятором и головой программиста и нет даже банального grep (я не говорю про более серьёзные анализаторы кода)... да, здесь надо было проехаться по Windows, которая не даёт средств разработки, но это для другого треда.

N>>Не спорю, сделаешь. Но как ты сделаешь, например, правило, что в случае наличия параметра X не может быть задан параметр Y, если Y поступает только в переменной части? Отработка этой проверки при компиляции невозможна, потому что невозможно знать, кто и с чем вызовет. Вот у тебя и получается в результате проверка в рантайме, сиречь та самая динамика.
WH>Зависимыми типами я тебе что угодно проверю.
WH>Было бы жилание.
WH>Впорос в том а нахрена эти сложности вообще нужны?

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

WH>Можешь привести пример?

Так я и привёл, тебе недостаточно? Или ты считаешь, что

N>>А, так ты даже описания не прочитал? Ну и расскажи, как эта одна навороченная фнкция поможет сделать то, что я описал? Как говорят коллеги, иди учи матчасть.
WH>Что учить?

Я тебе про openat, а ты мне про "кучу специализированных функций", хотя её функциональность не покрывается CreateFile() ни в каком виде. Значит, ты ничего про неё не прочитал, но проигнорировать или прочитать не захотел. Это уже показатель уровня твоей полемики.

WH>И причем тут вообще динамика?
WH>А функциональность этой функции вообще за гранью моего понимания.
WH>Она не нужна.

Тогда зачем споришь о том, что за гранью твоего понимания?

N>>Ну конечно, привёл пример фиксированной структуры и успокоился... Представь себе, что завтра выходит новая версия стандарта, где у этой sequence ещё три возможных компонента. И тут твой конвертер представлений резко сломался...
WH>Какой конвертер?
WH>Каких представлений?

Внутренних во внешние и обратно.

WH>>>Если какойто гоблин начал специально обходить защиту компилятора это он сам себе злобный буратино.
WH>>>Нормальный человек это делать не будет.
WH>>>Так что мимо.
N>>Так в этом месте вообще защиты быть не может. Так что мимо

WH>Использование годных инструментов дебилами я обсуждать не намерен.

Сначала докажи, что дебилы. Встречный вопрос: какой дебил и зачем придумал конвертировать все из себя объектные твои построения в какой-то ужасный октетный поток и отдавать через совершенно нетипизированный TCP? Да ещё и в каком-то жутком transfer encoding, которое ломает всё представление?

N>>Ну и зря. Очень толковые ребята с неплохим результатом.
WH>Я уже ругался на эту тему
WH>http://www.rsdn.ru/forum/philosophy/3598807.1.aspx
WH>И это не полный список.
WH>Единственное что я не заметил при написании того сообщения это поддержку детерминированной финализации. В прочем она у них сделана столь дебильно что даже С++ и тот лучше.

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

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

ВВ>А писать в функциональном стиле на Руби (где нет первоклассных функций)

Мнэээ... точно нету?

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

G>>>>>>А что мешает делать тоже самое с java, c# и даже с++?

DAS>>>>> Тем, что 'quick' в c++ выходит у слишком 'dirty'. Хотя бы из-за неаккуратной работы с памятью.

G>>>>Ок, отбросим C++. Остались java и .NET, чем они не угодили для quick-and-durty?

M>>>Когда Веб взлетал, java проталкивалась на десктопы, а .NET только рождался. Сейчас и первый и второй в вебе представлены очень широко.
G>>Да я то знаю, вот убеждение что на динамических языках что-то там проще делается меня удивляет.

M>Ну, как бы оно до сих пор часто делается проще

M>PHP позволяет не уходить их HTML'я вообще (что не очень хорошо, но очень просто).
M>Coldfusion — агалогично (несмотря на платность он очень популярен в Штатах).
Аналогично ASP.NET и JSP.
Типизация на такое поведение вообще не влияет.

M>У Питона есть Django, в которм две строчки кода дают тебе мегаадминку и крутой сайт.
M>Ruby on Rails позволяют примерно похожее.
Dynamic Data для ASP.NET аналогично. Причем тут типизация?

M>Для Java и ASP.NET аналогичное стало появляться только весьма недавно.
А какая разница когда начало появляться, главное что оно есть сейчас.

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

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

G>>В .NET нету монолитного фреймворка.

DAS> Ах, нет.

Это к чему было?

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

ВВ>>А писать в функциональном стиле на Руби (где нет первоклассных функций)
N>Мнэээ... точно нету?

Есть возможность передать функцию через колл-бек, но это разве first class?
Вот тут например сравнение Питона и Руби по этому вопросу: http://dev.pocoo.org/~mitsuhiko/pythonruby.html#ruby-first-class-functions

Сами мне и скажите — это оно или нет.

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

G>Это к чему было?

Разочарование. Я уж надеялся.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

ВВ>>>А писать в функциональном стиле на Руби (где нет первоклассных функций)
N>>Мнэээ... точно нету?

ВВ>Есть возможность передать функцию через колл-бек, но это разве first class?
ВВ>Вот тут например сравнение Питона и Руби по этому вопросу: http://dev.pocoo.org/~mitsuhiko/pythonruby.html#ruby-first-class-functions

ВВ>Сами мне и скажите — это оно или нет.

Это костыль того же уровня, что делегаты с методами объектов в C# 1.0.
Я частично согласен с выводом — я знал, что можно фактически сделать first class function, но не знал, что в виде именованных функций оно так морочно. Но не следует забывать ещё про блоки кода — они покрывают существенную часть необходимости в first class functions.
Предлагаю оформить ответ — "они есть, но криво".

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

L>>И что из этого является препятствием для использования статически-типизированных языков?

DAS> Ты про Haskell что ли?

Да никаких.

Я к тому что quick & dirty можно писать на любом языке. Ну как минимум dirty — точно.

M>>>>Когда Веб взлетал, java проталкивалась на десктопы, а .NET только рождался. Сейчас и первый и второй в вебе представлены очень широко.
G>>>Да я то знаю, вот убеждение что на динамических языках что-то там проще делается меня удивляет.

M>>Ну, как бы оно до сих пор часто делается проще

M>>PHP позволяет не уходить их HTML'я вообще (что не очень хорошо, но очень просто).
M>>Coldfusion — агалогично (несмотря на платность он очень популярен в Штатах).
G>Аналогично ASP.NET и JSP.

G>Типизация на такое поведение вообще не влияет.

M>>У Питона есть Django, в которм две строчки кода дают тебе мегаадминку и крутой сайт.
M>>Ruby on Rails позволяют примерно похожее.
G>Dynamic Data для ASP.NET аналогично. Причем тут типизация?

M>>Для Java и ASP.NET аналогичное стало появляться только весьма недавно.
G>А какая разница когда начало появляться, главное что оно есть сейчас.

Ну дык. Оно-то есть только сейчас. А для всего остального оно уже было

За место под солнцем еще бороться надо

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

N>Это костыль того же уровня, что делегаты с методами объектов в C# 1.0.
N>Я частично согласен с выводом — я знал, что можно фактически сделать first class function, но не знал, что в виде именованных функций оно так морочно. Но не следует забывать ещё про блоки кода — они покрывают существенную часть необходимости в first class functions.
N>Предлагаю оформить ответ — "они есть, но криво".

Все же термин "первоклассная функция" говорит скорее о поддержке таковых как first class citizen в компиляторе. Однако в отношении Руби и в отношении даже C# (и не обязательно 1.0) речь идет скорее о механизме, который позволяет симулировать первоклассные функции. В действительности же функция не является таким же значением, как, скажем, целые числа, ни в C#, ни в Руби. Т.е. функция на самом деле — это не первоклассное значение, первоклассным значением является специальная обвертка над фукнцией (тот же делегат в Шарпе).

И можно было бы закрыть глаза на этот факт, если бы он не приводил к тому, что использование функций в качестве first class в том же Руби приводит к определенным неудобствам по сравнению с языками, где функции действительно first class. Взять хоть ДжаваСкрипт.

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

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

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

G>>Это к чему было?

DAS> Разочарование. Я уж надеялся.

На что?

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

ВВ>Все же термин "первоклассная функция" говорит скорее о поддержке таковых как first class citizen в компиляторе. Однако в отношении Руби и в отношении даже C# (и не обязательно 1.0) речь идет скорее о механизме, который позволяет симулировать первоклассные функции. В действительности же функция не является таким же значением, как, скажем, целые числа, ни в C#, ни в Руби. Т.е. функция на самом деле — это не первоклассное значение, первоклассным значением является специальная обвертка над фукнцией (тот же делегат в Шарпе).

Не могу возразить формально

ВВ>И можно было бы закрыть глаза на этот факт, если бы он не приводил к тому, что использование функций в качестве first class в том же Руби приводит к определенным неудобствам по сравнению с языками, где функции действительно first class. Взять хоть ДжаваСкрипт.

ВВ>Короче, мне сложно представить функциональный код на Руби. Да, кстати, и на Питоне тоже. Под совсем другие парадигмы затачивались эти языки.

Что есть "функциональный код"? На Ruby не писал, но на Питоне пишу постоянно. Для тех задач, которые на нём делаются, и для пределов его возможностей такого достаточно. На Питоне ты можешь породить функцию на ходу с любым необходимым поведением и передать её как данное (аргумент), над ней можно построить другую, и т.д. Что ещё нужно от данного механизма?

DAS>> Да уж, ROR просто офигительно сложен: http://www.rubyonrails.ru/screencasts.html
DAS>> Пример, "Как создать блог за 15 минут". Честная и наглядная демонстрация начиная от установки rails и заканчивая запуском блога.
DAS>> При том, что 99% кода Rails там сам генерит.

ВВ>А в АСП.НЕТ еще проще:
ВВ>http://www.asp.net/get-started

The MVC Music Store tutorial explains step-by-step how to use ASP.NET MVC and Visual Studio to build an application:

Только вот когда появился ASP.NET, ASP.NET MVC даже в планах не было. ASP.NET MVC 1.0 — это 2009-й год. Ruby on Rails 1.0 — это 2005-й год. И да, "Как создать блог за 15 минут на RoR" тоже появился примерно тогда же. Django тоже выпущен на публику был в 2005-м году.

В 2005-м RoR и Django были прорывом. Тогда не было ни единого фреймворка, которые были бы настолько же легки в использовании. Это сейчас можно говорить, что мол, в других языках дела обстоят не хуже. Но это только сейчас

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

M>В 2005-м RoR и Django были прорывом. Тогда не было ни единого фреймворка, которые были бы настолько же легки в использовании. Это сейчас можно говорить, что мол, в других языках дела обстоят не хуже. Но это только сейчас

Речь не была о том, когда эти технологии появились. Речь была — у РОР более низкий порог вхождения, чем у АСП.НЕТ "с сиськами" (т.е. РАД-ы, контролы и прочие туториалы). С чем, собственно, и спорим.

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

N>Что есть "функциональный код"? На Ruby не писал, но на Питоне пишу постоянно. Для тех задач, которые на нём делаются, и для пределов его возможностей такого достаточно. На Питоне ты можешь породить функцию на ходу с любым необходимым поведением и передать её как данное (аргумент), над ней можно построить другую, и т.д. Что ещё нужно от данного механизма?

Формально — определить невозможно

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

Я обычно все же исхожу из того, функциональное программирование есть подвид декларативного. Соответственно, язык должен позволять писать в декларативном стиле и писать так должно быть более удобно, чем в императивном. И с этим уже как-то грустно в Питоне по сравнению с настоящим ФЯ.

Скажем, будет ли рекурсия более удобным средством для разбора списков, чем циклы? Связные списки вообще в Питоне-то есть? А как будет выглядеть композиция или каррирование функций? А есть ли паттерн-матчинг?

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

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

N>>Что есть "функциональный код"? На Ruby не писал, но на Питоне пишу постоянно. Для тех задач, которые на нём делаются, и для пределов его возможностей такого достаточно. На Питоне ты можешь породить функцию на ходу с любым необходимым поведением и передать её как данное (аргумент), над ней можно построить другую, и т.д. Что ещё нужно от данного механизма?

ВВ>Формально — определить невозможно

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

ВВ>Я обычно все же исхожу из того, функциональное программирование есть подвид декларативного. Соответственно, язык должен позволять писать в декларативном стиле и писать так должно быть более удобно, чем в императивном. И с этим уже как-то грустно в Питоне по сравнению с настоящим ФЯ.

Так на это он никогда и не претендовал: нет, например, хвостовой рекурсии.

ВВ>Скажем, будет ли рекурсия более удобным средством для разбора списков, чем циклы? Связные списки вообще в Питоне-то есть?

Списки есть. Думаю, если ввести функции

def car(x):
  return x[0]
def cdr(x):
  if not x:
    raise ValueError, 'empty list'
  return x[1:]

результат удовлетворит любого

ВВ> А как будет выглядеть композиция или каррирование функций?
ВВ> А есть ли паттерн-матчинг?

Конечно, нету. А надо? Это всё-таки другое направление. Вообще, непонятно смещение темы. Начали всего-то про first class functions.

M>>В 2005-м RoR и Django были прорывом. Тогда не было ни единого фреймворка, которые были бы настолько же легки в использовании. Это сейчас можно говорить, что мол, в других языках дела обстоят не хуже. Но это только сейчас

ВВ>Речь не была о том, когда эти технологии появились. Речь была — у РОР более низкий порог вхождения, чем у АСП.НЕТ "с сиськами" (т.е. РАД-ы, контролы и прочие туториалы). С чем, собственно, и спорим.

Возможно, он ниже психологически

В том плане, что когда говорят Ruby+Web, подразумевают RoR. 15 минут туториала и вперед. Когда говорят ASP.NET... То MVC далеко не первое, что приходит в голову.

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

ВВ>>Я обычно все же исхожу из того, функциональное программирование есть подвид декларативного. Соответственно, язык должен позволять писать в декларативном стиле и писать так должно быть более удобно, чем в императивном. И с этим уже как-то грустно в Питоне по сравнению с настоящим ФЯ.
N>Так на это он никогда и не претендовал: нет, например, хвостовой рекурсии.

Ну вот, что за функциональный язык без хвостовой рекурсии

N>Списки есть. Думаю, если ввести функции
N>

N>def car(x):
N>  return x[0]
N>def cdr(x):
N>  if not x:
N>    raise ValueError, 'empty list'
N>  return x[1:]
N>

N>результат удовлетворит любого

Эээ... Это не списки, это индексированные массивы. Просто в питоне придумали (заметьте — опять костыль), некий механизм, который позволяет имитировать связные списки на массивах, т.е. аналог операции "получить хвост", но для индексированного массива.

ВВ>> А как будет выглядеть композиция или каррирование функций?
ВВ>> А есть ли паттерн-матчинг?
N>Конечно, нету. А надо? Это всё-таки другое направление. Вообще, непонятно смещение темы. Начали всего-то про first class functions.

В смысле смещение темы? Вы сами спросили "что есть функциональный код", т.е. почему тот же Питон не подходит для программирования в функциональном стиле. Я вам ответил, какие возможности на мой взгляд должны быть в языке, чтобы он позволял полноценно писать с использованием ФП.

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

ВВ>Речь не была о том, когда эти технологии появились. Речь была — у РОР более низкий порог вхождения, чем у АСП.НЕТ "с сиськами" (т.е. РАД-ы, контролы и прочие туториалы). С чем, собственно, и спорим.

Ну, вообще, тема называлась "почему в вебе распространены именно динамические языки программирования?". На тот момент, когда занималась ниша разработки под web — Ruby и Python действительно имели более низкий порог вхождения и больше возможностей, чем тот же ASP. Все — это всего лишь мое мнение, которое я и написал.

Теперь же обсуждение скатилось на тему — что круче ASP или Rails. Да разве про это шла речь?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

M>Возможно, он ниже психологически

В том плане, что когда говорят Ruby+Web, подразумевают RoR. 15 минут туториала и вперед. Когда говорят ASP.NET... То MVC далеко не первое, что приходит в голову.

А что первое? Веб-формы разве сложнее?
Я лично видел, как люди с АСП (читай — ВБскрипт) переходили на Веб-формс и программировали, не особенно вдаваясь в детали ООП там или не ООП.

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

DAS> Ну, вообще, тема называлась "почему в вебе распространены именно динамические языки программирования?". На тот момент, когда занималась ниша разработки под web — Ruby и Python действительно имели более низкий порог вхождения и больше возможностей, чем тот же ASP. Все — это всего лишь мое мнение, которое я и написал.
DAS> Теперь же обсуждение скатилось на тему — что круче ASP или Rails. Да разве про это шла речь?

Ну тема в идеале предполагает обсуждение возможных причин распространения именно динамических языков. В числе таких причин вы привели то, что порог вхождения, скажем, у РОР ниже, чем порог вхождения, скажем, у АСП.НЕТ. Вот конкретно эта причина мне кажется сомнительной. Все. О "крутизне" этих технологий тут вроде бы и слова не было, разве нет?

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

N>>Конечно, нету. А надо? Это всё-таки другое направление. Вообще, непонятно смещение темы. Начали всего-то про first class functions.
ВВ>В смысле смещение темы? Вы сами спросили "что есть функциональный код", т.е. почему тот же Питон не подходит для программирования в функциональном стиле.

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

M>>Возможно, он ниже психологически

В том плане, что когда говорят Ruby+Web, подразумевают RoR. 15 минут туториала и вперед. Когда говорят ASP.NET... То MVC далеко не первое, что приходит в голову.

ВВ>А что первое? Веб-формы разве сложнее?
ВВ>Я лично видел, как люди с АСП (читай — ВБскрипт) переходили на Веб-формс и программировали, не особенно вдаваясь в детали ООП там или не ООП.

Возможно, не спорю

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

M>В 2005-м RoR и Django были прорывом. Тогда не было ни единого фреймворка, которые были бы настолько же легки в использовании. Это сейчас можно говорить, что мол, в других языках дела обстоят не хуже. Но это только сейчас

Так и надо рассматривать что сейчас, а не десять-пять-год назад.

Здравствуйте, DemAS, Вы писали:
>print "Hello, world"

Странно что еще матрица не всплыла. Порог они там снизели до минимума.

          @foreach(var row in db.Query("SELECT * FROM Product ORDER BY Name")){
            <tr>
               <td>@row.Id</td>
                   <td>@row.Name</td>
                   <td>@row.Description</td>
                   <td>@row.Price</td>
            </tr>
           }

И никакие классы не нужны. Хотя она все равно работает в пользу динамики.
http://www.asp.net/webmatrix

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

M>Там нет моих фраз.
У тебя скалероз?
Re[20]: почему в вебе распространены именно динамические язы

M>Угу. Вот ты рядом мне начал рассказывать про это сказки. Прикинь, тормоза у меня не в расчетах, а в сохранении этих расчетов.
У тебя тормоза в решении задачи.
Я тебе показал как ее решить быстро.
Если решение тормозит нужно просто подходить с другой стороны.

M>Зачем? Но при желании, думаю можно приблизиться к этим цифрам. Другой вопрос — насколько часто это требуется.
Языком.

WH>>http://www.impredicative.com/ur/
WH>>Вот попробуй тестами гарантировать отсутствие перечисленных проблем.
хъ
M>что ты хотел сказать-то?
Чукча не читатель?
Там статически типизируемый язык который это гарантирует.

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

M>

M>case proplists:get_value(a, Object) of
M>    undefined ->
M>        {error, {undefined_value, a}}
M>

M>вау. действительно. я же тупой. я же не знаю, что за данные мне приходят.
Об этом я и говорю.
Этот мусор не нужен.

M>если надо, проверим. если не надо, не проверим. в чем проблема-то?
Практика показывает что всегда надо.

M>ага, некий гипотетический абстрактный язык, где это возмжоно. странно,
Язык вполне конкретный. Немерле называется.

M>то же самое можно сделать в некотором гипотетическом абстрактном динамически-типизированом языке.
С тормозами, без помощи компилятора и IDE...

WH>>Статика:
WH>>1)Проверка структуры декларативна.
M>что бы это ни значило
Дурку не включай.

WH>>2)Автокомплит, рефакторинг, навигация,...
M>и как это еу же JetBrains ухитряются то же для Питона делать, просто поражаюсь

Я не поленился и скачал.
Возможности PyCharm соответствуют моим ожиданиям.
Ибо чудес не бывает.

class Test1:
    def asd(self, a):
        return a.asd(a)

class Test2:
    def asd(self, a):
        return a.asd(a)

    def qew(self, a):
        return a.asd(a)

При попытки переименовать любой из методов asd она переименовавает все три вызова при этом не переименовывает второй метод.
Это блин ломающий рефакторинг...

При попытке нажать ctrl+spase после a.q нет вариантов.
Если гдето написать a.qweqwrwevcsreg то начинает подсказывать qweqwrwevcsreg но qwe всеравно нету.
Кстати qweqwrwevcsreg нигде не объявлено но "IDE" молчит.

И это коммерческая IDE которую люди пишут полный рабочий день.

Страни с IDE для немерле.
Рефакторанг там просто не реализован. Ибо не очень надо и как следствие никто этим не занимался.
За то автокомплит, навигация и подсветка ошибок работают как часы.
И это при том что ее делают в свободное от работы время.

Так что IDE для динамики больше не вспоминай. Это блокноты с раскраской синтаксиса.

WH>>3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.
M>Очень малая часть ошибок.
Лично у меня почти все ошибки сводятся к этому...

WH>>4)Скорость работы высокая.
M>Опять эта мифическая никому не нужная сферовакуумная скорость в отрыве от задачи.
Я еще не видел задач в которых не нужна скорость.

WH>>Динамика:
WH>>1)Проверки структуры императивны и размазаны по всей программе.
M>Фиг его знает, что ты тут имеешь в виду.
Ту грязь что ты понаписал выше.

WH>>2)Поддержки IDE нет. Ибо структура объекта не извесна. И взять ее негде.
M>и как это еу же JetBrains ухитряются то же для Питона делать, просто поражаюсь

См выше.

WH>>3)Компилятор молчит.
M>Да ты что. Неужели.
Конечно молчит. Информации то у него нет.

WH>>4)Тормоза.
M>Опять эта мифическая никому не нужная сферовакуумная скорость в отрыве от задачи.
Томоза самые реальные.
Ну а то что ты тупо отрицаешь недостатки своих игрушек чести тебе не делает.

M>Профит у людей, которые не думают о языках в терминах сферовакуумности того или иного языка.
В воображении.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Что такое естественные ограничения? Для меня естественные — это именно придуманные человеком. Естественнее не бывает.

1) естественные ограничения (например, законы сохранения)

(С)netch80

M>А как тут поможет статика? Ты тут апологет того, что «статика — труъ и помогает всегда». Я показал пример задачи, которая должна решаться на веб-сайте, и где от того, какая типизация будет в языке, ни холодно ни жарко.
В данном случае как минимум скоростью.

M>Ну и при чем тут статика? Или автоматы нельзя на динамике делать?

Можно. Только производительность будет меньше на порядок другой.

M>Опять начинается сферовакуум. В моем случае мне даром не надо что-либо обгонять, потому что узкое место в данном случае — попытка загнать результаты в базу данных или вообще любое хранилище. Вот и нахрена мне там непревзойденная скорость статики? Только чтобы потом пенисометрией на РСДН заниматься?
Ты уперся рогом в базу данных.
И зря.
Базы данных на такой сценарий не расчитаны.
Как следствие нужно альтернативное решение.
Но ты даже не попытался понять о чем я написал.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>Это свойство "корневой" модели области, независимой от конкретной реализации.
Тем не менее это все придумано человеком.

N>Я не говорил "из природы", ты это сам додумал и раз додумал — с собой и спорь. Я говорил "естественные".

1) естественные ограничения (например, законы сохранения)

N>Говоря твоими же словами, переход на личности — признак того, что аргументы кончились. А теперь объясни, зачем ты столько слов развёл на один далеко не основной аспект? Думаешь через эту сторону опровергуть проще?
Начнем с того что равел ты...

N>Спасибо за внятное объяснение (вместо кода на маргинальном языке

) Да, пример показательный. Но и против него есть как внутренние, так и внешние возражения.
N>Во-первых, анализ такого рода возможен и для динамических языков (буду пока называть так), для наиболее прямого варианта использования. Грубо и на Питоне говоря, если ты пишешь a.b, он сработает, если getattr(a,'b') — нет (хотя pychecker в этом случае говорит, а почему написать не просто a.b?)

То-то PyCharm в 10 строках запутался.

N>Во-вторых, если у тебя кроме собственно выбора значения ещё логика по его использованию, тебе придётся делать тест. А в этом случае ты отловишь ситуацию и в динамике. (Да, я повторяюсь.)
1)У меня один здоровый функциональный тесть на все.
2)Это преобразование я провол до того как появился код который может привести к тому что там не будет значения.
3)Код ради которого все затевалось еще даже не написан.

N>В-третьих, ты на самом деле сделал больше, чем тебе нужно.
Ну да... тебе конечно виднее

N>Тебе пришлось, кроме случаев, когда явно надо проверять значение, вставить проверки и в те места, где она не нужна по логике.
Например?

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

N>Если бы у тебя была более сложная задача и какая-то ветка выполнения имела бы это значение всегда присутствующим — тебе бы пришлось "на ровном месте" вводить дополнительную переменную, не имеющую признака optional.
Да у меня полно таких веток.
Проверка осуществляется до того как в них попадает управление.

N>Профит озвучивался раньше: например, ускорение разработки, сокращение цикла изменения. Были и другие выгоды. Перечитай.
По сравнению с С++.
Но по сравнению с немерле их нет!

N>Никто никогда не держит всю программу в голове, ты зря загинаешь лишнего. Полемические приёмы такого рода действуют только на тех, кто "заводится". Всегда рассматривается какая-то "проекция" задачи, и вопрос зависит от качества её выделения и рассмотрения.
А как без этого делать то что я показал?

N>И именно вопрос, что должно войти в проекцию, является наиболее сложным в определении рамок рассмотрения для изменения (анализа, etc.) Например, моя разработка — SIP softswitch — не имеет практически никаких проблем от собственно динамической среды: это даёт наиболее грубые виды ошибок, которые ловятся элементарными тестами. Существенные ошибки начинаются там, где возникают проблемы логики функционирования. Например, акаунтинг должен быть привязан к рауту, контроллеру или UA? И в какой момент — к кому из них? Что будет при перемещении UA между контроллерами (например, при зрячем трансфере), какие параметры должны перейти к новому контроллеру, потому что логически привязаны к UA, а какие — остаться у старого? Как организовать формирование биллинговых атрибутов в случае не pickup-on-call, а pickup-on-IwR, учитывая, что часть данных вообще недоступна (поскольку INVITE-with-Replaces не авторизуется), а часть должна быть получена от ещё не существующей ноги? И тэ дэ, и тэ пэ...
Маладца. Убил тонной подробностей из своей предметной области о которых я даже не слышал.
Так держать. Авось чтонибудь да докажешь.

N>И как ты думаешь, волнует меня здесь то, что я формально не знаю, число или строка в конкретной переменной?

А ты вообще статикой то пользоваться умеешь?
Я это к тому что статика и близко не сволдится к различию между целыми и строками.

N>Ну если у тебя выбор только между компилятором и головой программиста и нет даже банального grep (я не говорю про более серьёзные анализаторы кода)... да, здесь надо было проехаться по Windows, которая не даёт средств разработки, но это для другого треда.
У меня есть самый серьезнай из возможных анализаторов кода.
Компилятор.

N>Ты куда-то постоянно спешишь? Уровень проблем с орфографией такой, что невозможно игнорировать.
Нечего ответиь. Цепляешься к опечаткам. Слив засчитан.

WH>>Можешь привести пример?
N>Так я и привёл, тебе недостаточно? Или ты считаешь, что
Что?

N>Я тебе про openat, а ты мне про "кучу специализированных функций", хотя её функциональность не покрывается CreateFile() ни в каком виде. Значит, ты ничего про неё не прочитал, но проигнорировать или прочитать не захотел.
Я прочтиал. Но не понял нахрены ты этот оффтопик вообще приплел?
Причем тут динамика?

N>Это уже показатель уровня твоей полемики.
Нет. Твоей. Ибо ты что-то пытаешься доказать оффтопиком.

N>Тогда зачем споришь о том, что за гранью твоего понимания?
И зачем нужна эта функция?
Приведи пример?

N>>>Ну конечно, привёл пример фиксированной структуры и успокоился... Представь себе, что завтра выходит новая версия стандарта, где у этой sequence ещё три возможных компонента. И тут твой конвертер представлений резко сломался...
WH>>Какой конвертер?
WH>>Каких представлений?
N>Внутренних во внешние и обратно.
Что и почему должно сломаться?
Ничего не понял.

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

N>Встречный вопрос: какой дебил и зачем придумал конвертировать все из себя объектные твои построения в какой-то ужасный октетный поток и отдавать через совершенно нетипизированный TCP? Да ещё и в каком-то жутком transfer encoding, которое ломает всё представление?
Это то тут причем?

N>Это тема отдельного обсуждения, но как минимум половина твоих доводов не по адресу или опровергается с ходу.
Они все кроме одного по адресу и там не полный список.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

D>И никакие классы не нужны. Хотя она все равно работает в пользу динамики.
D>http://www.asp.net/webmatrix
Посмотри тут: http://www.impredicative.com/ur/
Чистая статика...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

M>>Что такое естественные ограничения? Для меня естественные — это именно придуманные человеком. Естественнее не бывает.
WH>

WH>1) естественные ограничения (например, законы сохранения)

WH>(С)netch80

M>>А как тут поможет статика? Ты тут апологет того, что «статика — труъ и помогает всегда». Я показал пример задачи, которая должна решаться на веб-сайте, и где от того, какая типизация будет в языке, ни холодно ни жарко.
WH>В данном случае как минимум скоростью.

Опять та скорость. Нахрена мне нужна скорость, если все упрется

M>>Ну и при чем тут статика? Или автоматы нельзя на динамике делать?

WH>Можно. Только производительность будет меньше на порядок другой.

На порядок максимум. Что для 99.9999999% случаев более, чем достаточно.

M>>Опять начинается сферовакуум. В моем случае мне даром не надо что-либо обгонять, потому что узкое место в данном случае — попытка загнать результаты в базу данных или вообще любое хранилище. Вот и нахрена мне там непревзойденная скорость статики? Только чтобы потом пенисометрией на РСДН заниматься?
WH>Ты уперся рогом в базу данных.
WH>И зря.
WH>Базы данных на такой сценарий не расчитаны.
WH>Как следствие нужно альтернативное решение.

Выделенное выше.

WH>Но ты даже не попытался понять о чем я написал.

По выделенному выше видно как ты читал, ага.

Повторю в пятидесятый раз. Сферовакуумная скорость никому не интересна. Всегда есть задача — сделать столько-то и столько0то в таких-то пределах. Скорость ради скорости нужна, судя по всему, только тебе.

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

N>>Это свойство "корневой" модели области, независимой от конкретной реализации.
WH>Тем не менее это все придумано человеком.

N>>Я не говорил "из природы", ты это сам додумал и раз додумал — с собой и спорь. Я говорил "естественные".
WH>

WH>1) естественные ограничения (например, законы сохранения)

У тебя явные проблемы с логикой, если ты один частный пример воспринимаешь как правило и ограничение.

N>>Говоря твоими же словами, переход на личности — признак того, что аргументы кончились. А теперь объясни, зачем ты столько слов развёл на один далеко не основной аспект? Думаешь через эту сторону опровергуть проще?
WH>Начнем с того что равел ты...

И что? Расскажи подробнее. Ах да, я с тобой спорю и осмеливаюсь с тобой не соглашаться...

N>>Спасибо за внятное объяснение (вместо кода на маргинальном языке

) Да, пример показательный. Но и против него есть как внутренние, так и внешние возражения.
N>>Во-первых, анализ такого рода возможен и для динамических языков (буду пока называть так), для наиболее прямого варианта использования. Грубо и на Питоне говоря, если ты пишешь a.b, он сработает, если getattr(a,'b') — нет (хотя pychecker в этом случае говорит, а почему написать не просто a.b?)
WH>

То-то PyCharm в 10 строках запутался.

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

N>>Во-вторых, если у тебя кроме собственно выбора значения ещё логика по его использованию, тебе придётся делать тест. А в этом случае ты отловишь ситуацию и в динамике. (Да, я повторяюсь.)
WH>1)У меня один здоровый функциональный тесть на все.
WH>2)Это преобразование я провол до того как появился код который может привести к тому что там не будет значения.
WH>3)Код ради которого все затевалось еще даже не написан.

Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz.

N>>В-третьих, ты на самом деле сделал больше, чем тебе нужно.
WH>Ну да... тебе конечно виднее

Тут надо было добавить, что в общем случае сделал бы. В частном — да, возможно, не больше.

N>>Я догадываюсь, ты взял намеренно "чистый" пример, где такая проверка не нужна. Я прав?
WH>Я взял первый попавшейся пример.
WH>Хватит искать заговоры.

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

N>>Если бы у тебя была более сложная задача и какая-то ветка выполнения имела бы это значение всегда присутствующим — тебе бы пришлось "на ровном месте" вводить дополнительную переменную, не имеющую признака optional.
WH>Да у меня полно таких веток.
WH>Проверка осуществляется до того как в них попадает управление.

Тогда зачем проверять ещё раз в ветке? А ведь по сказанному тобой у тебя нет выбора — иначе компилятор не пустит код скомпилироваться. Или ты (опять) что-то недоговариваешь?

N>>Профит озвучивался раньше: например, ускорение разработки, сокращение цикла изменения. Были и другие выгоды. Перечитай.
WH>По сравнению с С++.
WH>Но по сравнению с немерле их нет!

Существует вариант Nemerle в виде чистого интерпретатора, без компиляции? Если нет — твоё утверждение уже неверно.
И почему ты так уверен в недостатках C++?

N>>Никто никогда не держит всю программу в голове, ты зря загинаешь лишнего. Полемические приёмы такого рода действуют только на тех, кто "заводится". Всегда рассматривается какая-то "проекция" задачи, и вопрос зависит от качества её выделения и рассмотрения.
WH>А как без этого делать то что я показал?

Что именно ты показал? Не понимаю вопроса.

N>>И именно вопрос, что должно войти в проекцию, является наиболее сложным в определении рамок рассмотрения для изменения (анализа, etc.) Например, моя разработка — SIP softswitch — не имеет практически никаких проблем от собственно динамической среды: это даёт наиболее грубые виды ошибок, которые ловятся элементарными тестами. Существенные ошибки начинаются там, где возникают проблемы логики функционирования. Например, акаунтинг должен быть привязан к рауту, контроллеру или UA? И в какой момент — к кому из них? Что будет при перемещении UA между контроллерами (например, при зрячем трансфере), какие параметры должны перейти к новому контроллеру, потому что логически привязаны к UA, а какие — остаться у старого? Как организовать формирование биллинговых атрибутов в случае не pickup-on-call, а pickup-on-IwR, учитывая, что часть данных вообще недоступна (поскольку INVITE-with-Replaces не авторизуется), а часть должна быть получена от ещё не существующей ноги? И тэ дэ, и тэ пэ...
WH>Маладца. Убил тонной подробностей из своей предметной области о которых я даже не слышал.

Зато это полностью живой, настоящий пример, из которого ничего не упрощено. И да, он приведен для того, чтобы показать, насколько сложности ТЗ и спецификации преобладают над проблемами кодирования. Вот относительно свежий пример — исправление одного долго тянущегося бага свелось к перестановке одной команды (отцепить UA от контроллера) на строку выше, чтобы UA успел получить штатный сигнал дисконнекта. Никакие _типы_ этому не помогут, если в функционирование типа не вложишь полную FSM работы UA. И зачем это делать через тип, если проще напрямую?

WH>Так держать. Авось чтонибудь да докажешь.

Ещё один переход на личности. Сливаешь?

N>>И как ты думаешь, волнует меня здесь то, что я формально не знаю, число или строка в конкретной переменной?

WH>А ты вообще статикой то пользоваться умеешь?
WH>Я это к тому что статика и близко не сволдится к различию между целыми и строками.

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

N>>Ну если у тебя выбор только между компилятором и головой программиста и нет даже банального grep (я не говорю про более серьёзные анализаторы кода)... да, здесь надо было проехаться по Windows, которая не даёт средств разработки, но это для другого треда.
WH>У меня есть самый серьезнай из возможных анализаторов кода.
WH>Компилятор.

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

N>>Ты куда-то постоянно спешишь? Уровень проблем с орфографией такой, что невозможно игнорировать.
WH>Нечего ответиь. Цепляешься к опечаткам. Слив засчитан.

Это у тебя систематический слив уже пятое письмо.

N>>Я тебе про openat, а ты мне про "кучу специализированных функций", хотя её функциональность не покрывается CreateFile() ни в каком виде. Значит, ты ничего про неё не прочитал, но проигнорировать или прочитать не захотел.
WH>Я прочтиал. Но не понял нахрены ты этот оффтопик вообще приплел?
WH>Причем тут динамика?

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

N>>Это уже показатель уровня твоей полемики.
WH>Нет. Твоей. Ибо ты что-то пытаешься доказать оффтопиком.

Это ты даже секунду не пытаешься потратить на то, чтобы понять собеседника.

N>>>>Ну конечно, привёл пример фиксированной структуры и успокоился... Представь себе, что завтра выходит новая версия стандарта, где у этой sequence ещё три возможных компонента. И тут твой конвертер представлений резко сломался...
WH>>>Какой конвертер?
WH>>>Каких представлений?
N>>Внутренних во внешние и обратно.
WH>Что и почему должно сломаться?
WH>Ничего не понял.

Как ты во внутреннем представлении передашь новое поле пришедшей записи?

N>>Встречный вопрос: какой дебил и зачем придумал конвертировать все из себя объектные твои построения в какой-то ужасный октетный поток и отдавать через совершенно нетипизированный TCP? Да ещё и в каком-то жутком transfer encoding, которое ломает всё представление?
WH>Это то тут причем?

При том, что с твоим текстом, сделанным в лучших побуждениях "Don't ever generate invalid HTML", начинают обращаться внешние ресурсы, которые могут с ним сделать что угодно. Кстати, если ты решишь, что это проблемы уже внешних средств и граница чётко обозначена — подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам, или отображение твоего кода в чужом фрейме.

N>>Это тема отдельного обсуждения, но как минимум половина твоих доводов не по адресу или опровергается с ходу.
WH>Они все кроме одного по адресу и там не полный список.

Что неполный — верю. Остальное — сомнительно. Например, пункт 5 — сознательные ограничения и если тебя они не устраивают, это только вопрос вкусовщины. Пункт 2 — я бы согласился, но авторы регулярно прорабатывают тему исключений и, возможно, введут их. Пункт 1 — проблемы твоего восприятия, ты бы такое же рассказывал про Erlang. Tutorial просто не успели выправить. Так можно долго продолжать, истинно здесь только одно: ты настолько односторонне хочешь видеть мир, что отказываешься принимать запросы других.

M>>Угу. Вот ты рядом мне начал рассказывать про это сказки. Прикинь, тормоза у меня не в расчетах, а в сохранении этих расчетов.
WH>У тебя тормоза в решении задачи.
WH>Я тебе показал как ее решить быстро.

Нет, ты мне не показал, как ее решить быстро. Ты решил, что ты — единственный, который знает такие умные термины, как ДКА, НДКА и т.п.

WH>Если решение тормозит нужно просто подходить с другой стороны.

Подходи. Мы уперлись в то, что нам даром не нужна сферовакуумная скорость какого-то там языка. Потому что скорость генерации данных и так высока — доли секунды. Все упирается в запись этих данных. Но нет. ТАМ ЖИ СКОРАСТЬ!!!!!адынадынадын

M>>Зачем? Но при желании, думаю можно приблизиться к этим цифрам. Другой вопрос — насколько часто это требуется.
WH>Языком.

Мде. На что был этот ответ неизвестно никому.

WH>>>http://www.impredicative.com/ur/
WH>>>Вот попробуй тестами гарантировать отсутствие перечисленных проблем.
WH>хъ
M>>что ты хотел сказать-то?
WH>Чукча не читатель?
WH>Там статически типизируемый язык который это гарантирует.

Ах. Да, действительно. Вах. некий эксперимаентальный язык, который действительно, в случае системы типов, более строгой, чем в Хаскелле, позволяет это сделать.

Только строгая типизация != статическая типизация.
Итак. Что ты хотел сказать-то?

M>>это самый распространенный на данный момент случай.
WH>Только я его ни разу не видел.
WH>Все что я видел всегда имело структуру.

И твой опыт, видимо, является единственным и всеобъемлющим. Ага. Так мы и поверили.
Веб сам по себе — это сплошная слабоструктурированная информация. Из недавнего. http://www.janrain.com/ позволяет унифицировать логин на сайте через всякие твиттеры, фейсбуки и т.п. В возвращаемых значениях из 16 полей они могут гарантировать наличие аж 2-х.

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

M>>

M>>case proplists:get_value(a, Object) of
M>>    undefined ->
M>>        {error, {undefined_value, a}}
M>>

M>>вау. действительно. я же тупой. я же не знаю, что за данные мне приходят.
WH>Об этом я и говорю.
WH>Этот мусор не нужен.

Если не нужен, мы его не пишем. Делов-то ЖчяЖ

M>>если надо, проверим. если не надо, не проверим. в чем проблема-то?
WH>Практика показывает что всегда надо.

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

M>>ага, некий гипотетический абстрактный язык, где это возмжоно. странно,
WH>Язык вполне конкретный. Немерле называется.

M>>то же самое можно сделать в некотором гипотетическом абстрактном динамически-типизированом языке.
WH>С тормозами, без помощи компилятора и IDE...

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

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

WH>>>Статика:
WH>>>1)Проверка структуры декларативна.
M>>что бы это ни значило
WH>Дурку не включай.

Не включаю. Вообще не понимаю, что ты имеешь под декларативной проверкой структуры.

WH>>>2)Автокомплит, рефакторинг, навигация,...
M>>и как это еу же JetBrains ухитряются то же для Питона делать, просто поражаюсь

WH>Я не поленился и скачал.
WH>Возможности PyCharm соответствуют моим ожиданиям.
WH>Ибо чудес не бывает.
WH>

WH>class Test1:
WH>    def asd(self, a):
WH>        return a.asd(a)

WH>class Test2:
WH>    def asd(self, a):
WH>        return a.asd(a)

WH>    def qew(self, a):
WH>        return a.asd(a)
WH>

WH>При попытки переименовать любой из методов asd она переименовавает все три вызова при этом не переименовывает второй метод.
WH>Это блин ломающий рефакторинг...

Скачал IDEA для Java. В пяти попытках рефакторинга она мне предложила такой же ломающий рефакторинг. И это — на статистически типизированом языке, в котором это должно быть раз плюнуть, не?

WH>При попытке нажать ctrl+spase после a.q нет вариантов.
WH>Если гдето написать a.qweqwrwevcsreg то начинает подсказывать qweqwrwevcsreg но qwe всеравно нету.
WH>Кстати qweqwrwevcsreg нигде не объявлено но "IDE" молчит.

WH>И это коммерческая IDE которую люди пишут полный рабочий день.

И не парятся. Потому что

WH>Страни с IDE для немерле.
WH>Рефакторанг там просто не реализован. Ибо не очень надо и как следствие никто этим не занимался.

Ты или эта — одинаковые стандарты используй или вообще никакие. Для Немерле, значит, рефакторинг не нужен, а для любого сравниваемого с ним языка — ВНЕЗАПНО нужен?

WH>За то автокомплит, навигация и подсветка ошибок работают как часы.
WH>И это при том что ее делают в свободное от работы время.

WH>Так что IDE для динамики больше не вспоминай. Это блокноты с раскраской синтаксиса.

WH>>>3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.
M>>Очень малая часть ошибок.
WH>Лично у меня почти все ошибки сводятся к этому...

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

WH>>>4)Скорость работы высокая.
M>>Опять эта мифическая никому не нужная сферовакуумная скорость в отрыве от задачи.
WH>Я еще не видел задач в которых не нужна скорость.

Никому не нужна просто скорость. Нужна скорость в рамках поставленной задачи.

Есть у меня сайтец один. На HYH/ Два раза были проблемы с производительностью. Первый раз — с Апачем, замена на nginx помогла. Второй раз — с MySQL, тюнинг MySQL'я помог. Ни разу проблема с производительностью не упиралась в HYH/

Скорость у него.

Завязвай с наркотиками. Сферовакуумных коней и сферовакуумных скоростей не существует.

Я не зря ссылку на widefinder приводил. Можешь вдумчиво покурить результаты. Хотя ты там все равно ни хрена не увидишь. У тебя же СКОРАСТЬ!!!!!!одинодинодинодинодин

А умные люди увидят, что:
— mainstream динамика (Python) дает результаты, приемлемые в подавляющем большинстве случаев (22 секунды) по сравнению с meinstream статикой (java, 13 секунд) и является гораздо более приемлемым решением, чем вырвишлазный звиздец в 2000 LoC на C++ (но там же аж на один порядок быстрее!!!!!!одинодинодинодинодинодин).

WH>>>Динамика:
WH>>>1)Проверки структуры императивны и размазаны по всей программе.
M>>Фиг его знает, что ты тут имеешь в виду.
WH>Ту грязь что ты понаписал выше.

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

WH>>>4)Тормоза.
M>>Опять эта мифическая никому не нужная сферовакуумная скорость в отрыве от задачи.
WH>Томоза самые реальные.
WH>Ну а то что ты тупо отрицаешь недостатки своих игрушек чести тебе не делает.

Я их не отрицаю. Я тебе тупо твержу одну вещь: никого не интересует сферовакуумная скорость

M>>Профит у людей, которые не думают о языках в терминах сферовакуумности того или иного языка.
WH>В воображении.

исключительно в твоем. исключительно в твоем.

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

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

D>>И никакие классы не нужны. Хотя она все равно работает в пользу динамики.
D>>http://www.asp.net/webmatrix
WH>Посмотри тут: http://www.impredicative.com/ur/
WH>Чистая статика...
А что я там должен увидеть? По сути тоже самое
http://www.impredicative.com/ur/demo/sql.ur.html

Нужно румами обяъявлять тип.
table t : { A : int, B : float, C : string, D : bool }
PRIMARY KEY A

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

WH>>>http://www.impredicative.com/ur/
WH>>>Вот попробуй тестами гарантировать отсутствие перечисленных проблем.
WH>хъ
M>>что ты хотел сказать-то?
WH>Чукча не читатель?
WH>Там статически типизируемый язык который это гарантирует.

Про Ur

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

Что так он «гарантирует»...

- Attempt invalid SQL queries
— Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

Хм... Вот тут есть то же самое, практически, только для Erlang'а: http://code.google.com/p/erlyweb/source/browse/#svn/trunk/src/erlydb

При чем тут типы? А не при чем. Похожие библиотеки есть и для других языков (ActiveRecord для Ruby, модели и QuerySets из Django для Питона и т.п.).

Что тут дает статика? А ничего она не дает.

D>>>И никакие классы не нужны. Хотя она все равно работает в пользу динамики.
D>>>http://www.asp.net/webmatrix
WH>>Посмотри тут: http://www.impredicative.com/ur/
WH>>Чистая статика...
D>А что я там должен увидеть? По сути тоже самое
D>http://www.impredicative.com/ur/demo/sql.ur.html

D>Нужно румами обяъявлять тип.
D>table t : { A : int, B : float, C : string, D : bool }
D> PRIMARY KEY A

Помимо это, а где хваленая гарантия валидности генерируемого HTML'я?

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

M>Помимо это, а где хваленая гарантия валидности генерируемого HTML'я?
А почему ее там может не быть? <a></b> наверное не скомпилируется.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

M>>Помимо это, а где хваленая гарантия валидности генерируемого HTML'я?
D>А почему ее там может не быть? <a></b> наверное не скомпилируется.

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

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

D>А что я там должен увидеть? По сути тоже самое
Ну да. Кода столькоже но все статически типизированно и с проверкой компилятора.
И кому после этого нужна динамика?

D>Нужно румами обяъявлять тип.
А в динамике типа этот код не нужен?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>У тебя явные проблемы с логикой, если ты один частный пример воспринимаешь как правило и ограничение.
Если уж вводишь термины то делай их как следует.

N>И что? Расскажи подробнее. Ах да, я с тобой спорю и осмеливаюсь с тобой не соглашаться...\
Про естественность/искуственность ограничений начал ты Re[27]: почему в вебе распространены именно динамические язы
Я говорил просто о ограничениях.

N>Я не видел PyCharm и не хочу про него говорить, пока не поработал с ним. У тебя другой аргумент есть? Или ты уже второй раз пытаешься частный случай возвести во всеобщий закон?
Это к мамуту. Он тут пытался меня в этот PyCharm тыкать. Типа там все работает.
Да нихрена там не работает.

N>Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz.
Да все просто. Нет теста. И еще не скоро будет. Но я и так знаю что все впорядке.

N>>>В-третьих, ты на самом деле сделал больше, чем тебе нужно.
WH>>Ну да... тебе конечно виднее

N>Тут надо было добавить, что в общем случае сделал бы. В частном — да, возможно, не больше.
Ты хоть один пример найди.

N>Я не ищу заговоры, но тенденция использовать наиболее показательные примеры настолько очевидна, что предполагать обратное бессмысленно.
Ну так я и показал первый попавшейся пример где статика помогла мне отвефакторить кучу кода.
Могу еще комиты с подобным действом найти но смысл?

N>У тебя есть более жизненный пример?
Сто значит более жизненны?

N>Или у тебя все задачи такие?
Какие такие?

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

N>Тогда зачем проверять ещё раз в ветке? А ведь по сказанному тобой у тебя нет выбора — иначе компилятор не пустит код скомпилироваться. Или ты (опять) что-то недоговариваешь?
А где я сказал что проверяю еще раз?
Я получил option[Rule]. Проверил. Если пусто пошол по одному пути. Если что-то есть получил тип Rule и болше ничего не проверяю.

N>Существует вариант Nemerle в виде чистого интерпретатора, без компиляции? Если нет — твоё утверждение уже неверно.
А нахрена мне интерпритатор?
Он не имеет смысла.

N>И почему ты так уверен в недостатках C++?
Я его как бы очень хорошо знаю.

N>>>Никто никогда не держит всю программу в голове, ты зря загинаешь лишнего. Полемические приёмы такого рода действуют только на тех, кто "заводится". Всегда рассматривается какая-то "проекция" задачи, и вопрос зависит от качества её выделения и рассмотрения.
WH>>А как без этого делать то что я показал?
N>Что именно ты показал? Не понимаю вопроса.
Я все про тот рефакторинг.
Заменил в одном месле Rule на option[Rule] и нужно поменять все части программы где есть обращение.

N>Зато это полностью живой, настоящий пример, из которого ничего не упрощено. И да, он приведен для того, чтобы показать, насколько сложности ТЗ и спецификации преобладают над проблемами кодирования.
Я не могу на этот твой пример ничего ответить просто по тому что я не понял половину слов.
Сленг который ты использовал для меня ничего не значит.

N>Вот относительно свежий пример — исправление одного долго тянущегося бага свелось к перестановке одной команды (отцепить UA от контроллера) на строку выше, чтобы UA успел получить штатный сигнал дисконнекта. Никакие _типы_ этому не помогут, если в функционирование типа не вложишь полную FSM работы UA.
Вот! Сам же знаешь ответ.
И заложить в тип FSM это очень просто. Для этого даже зависимые типы не нужны.
Можно даже LL(1) закатать не особо напрягаясь.

N>И зачем это делать через тип, если проще напрямую?
Ну это смотря как делать.

WH>>Так держать. Авось чтонибудь да докажешь.
N>Ещё один переход на личности. Сливаешь?
Где?
Я просто говорю про ущербность подобной аргументации.

N>Так попытайся хотя бы навскидку предложить мне такое различие, которое бы помогло отловить все эти вещи на компиляции. А что ты думал — покажешь пару школьных примеров и этим кого-то убедишь?
Что значит выделенное?
И чем тот пример с изменением кучи кода школьный?

N>>>Ну если у тебя выбор только между компилятором и головой программиста и нет даже банального grep (я не говорю про более серьёзные анализаторы кода)... да, здесь надо было проехаться по Windows, которая не даёт средств разработки, но это для другого треда.
WH>>У меня есть самый серьезнай из возможных анализаторов кода.
WH>>Компилятор.
N>Бессмысленное утверждение, пропускаешь.
Что я пропускаю?
Выражайся яснее.

N>При том, что если функция промежуточного уровня имеет возможность добавлять аргументы, то я могу не ломать существующее API для получения новой функциональности. Но добавлять их придётся чисто динамическими методами.
Ты вообще о чем? http://linux.die.net/man/2/openat

N>Как ты во внутреннем представлении передашь новое поле пришедшей записи?
В каком представлении?
Какое поле?
Кокой заяц?
Какой орел?

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

N>При том, что с твоим текстом, сделанным в лучших побуждениях "Don't ever generate invalid HTML", начинают обращаться внешние ресурсы, которые могут с ним сделать что угодно. Кстати, если ты решишь, что это проблемы уже внешних средств и граница чётко обозначена —
Именно так я и решу.
Я не могу ничего контролировать после того как HTML покинул мою программу.
И что характерно в подавляющем большенстве случаев этот HTML без единого изменения достигнет браузера пользователя.

N>подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам,
И в чем проблема?

N>или отображение твоего кода в чужом фрейме.
Почему это должно меня волновать?

N>Что неполный — верю. Остальное — сомнительно. Например, пункт 5 — сознательные ограничения и если тебя они не устраивают, это только вопрос вкусовщины.
Исли мне каждый раз явно придется писать привидения от потомка к базе то я прокляну все на свете.

Перегрузка функций механизм крайне полезный.
Экономит кучу букв.
А что касается перегрузки операторов то мне и этого мало.
Я сейчас работаю над парсером для немерле2 там можно будет вообще как угодно над синтаксисом издеваться.
Что позволит сделать произвольный ДСЛ.

N>Пункт 2 — я бы согласился, но авторы регулярно прорабатывают тему исключений и, возможно, введут их.
И поломают весь существующий код.
Или нужно объяснять что код либо сразу нужно писать так чтобы он был безопасен к исключениям или потом его будет проще по новой переписать.

N>Пункт 1 — проблемы твоего восприятия, ты бы такое же рассказывал про Erlang.
А что в эрланге у нас уже можно шарить изменяемые данные?

N>Tutorial просто не успели выправить. Так можно долго продолжать, истинно здесь только одно: ты настолько односторонне хочешь видеть мир, что отказываешься принимать запросы других.
Ну да. Использование глобальных переменных это конечно правильно.
А я один кому это категорически не нравится.
Вот как это надо делать:

[CommandLineParser]
class Options
{
    [HelpMessage("don't print final newline")]
    [Name("n")]
    public OmitNewline : bool = false;
}

Может чуть больше слов за то понятно даже не зная как это все работает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

D>>А что я там должен увидеть? По сути тоже самое
WH>Ну да. Кода столькоже но все статически типизированно и с проверкой компилятора.
WH>И кому после этого нужна динамика?
Тем людям у которых очень редко возникают ошибки компиляции?

D>>Нужно румами обяъявлять тип.
WH>А в динамике типа этот код не нужен?

Я же привер пример кода. Для его работы больше ничего не нужно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>>Ну да. Кода столькоже но все статически типизированно и с проверкой компилятора.
WH>>И кому после этого нужна динамика?
D>Тем людям у которых очень редко возникают ошибки компиляции?
Не понял логики.

D>Я же привер пример кода. Для его работы больше ничего не нужно.
И скрипты генерации базы данных не нужны?

Кстати а как у этого твоего фреймворка с эскейпом строк? А с защитой от инекций кода? А с генерацией не валидного HTML?..

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

N>>>И часто ты читаешь код ядра Windows для реализации своего проекта?
WH>>А они где?

N>Для NT4 и части W2000 валяется на каждом углу. Для более нового не видел.

:offtopic:

1500 инсталляций винды (белых, естессно) в юрлице в правильной стране (см. страны НАТО +- пара изменений), пара НДА и будет вам любой исходный код. Линк лениво искать, если сильно надо — найду.

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

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

WH>>>Ну да. Кода столькоже но все статически типизированно и с проверкой компилятора.
WH>>>И кому после этого нужна динамика?
D>>Тем людям у которых очень редко возникают ошибки компиляции?
WH>Не понял логики.
Можно подобрать такое соотношение размера проекта и нормальной ide, что код будет написан с минимальным количеством тех ошибок которые мог бы отловить компилятор. Какой тогда от него толк кроме как как лишней траты времени на компиляцию?

D>>Я же привер пример кода. Для его работы больше ничего не нужно.
WH>И скрипты генерации базы данных не нужны?

База может уже быть или

@foreach(var row in internet.Query("http://test.com/getproducts.json")){
            <tr>
               <td>@row.Id</td>
                   <td>@row.Name</td>
                   <td>@row.Description</td>
                   <td>@row.Price</td>
            </tr>
           }

WH>Кстати а как у этого твоего фреймворка с эскейпом строк?
Фреймворк микрософта, Все эксейпится.
WH>А с защитой от инекций кода?
Присутствует.
WH>А с генерацией не валидного HTML?..
Мелочи.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

M>Нет, ты мне не показал, как ее решить быстро. Ты решил, что ты — единственный, который знает такие умные термины, как ДКА, НДКА и т.п.
Ты похоже их не знаешь.

M>Подходи. Мы уперлись в то, что нам даром не нужна сферовакуумная скорость какого-то там языка. Потому что скорость генерации данных и так высока — доли секунды. Все упирается в запись этих данных. Но нет.
Тут ты вполне однозначно говоришь что тебе нужен быстрый поиск.
Re[2]: Поможите. Одна комната, много детей :)
Я тебе сказал как сделать предельно быстрый поиск.
Но ты похоже уперся в то что искать должна БД.
Но все что вы на пару с Синклером придумали это линейный поиск.
Что и не удивительно. Ибо БД на подобную работу не затачивалась.

M>Мде. На что был этот ответ неизвестно никому.
Ты за разговором то следишь? Или не в состояни подняться на одно сообщение в верх?

M>Ах. Да, действительно. Вах. некий эксперимаентальный язык, который действительно, в случае системы типов, более строгой, чем в Хаскелле, позволяет это сделать.
Те ты признал что статика таки это может.
Уже хорошо.

M>Только строгая типизация != статическая типизация.
M>Итак. Что ты хотел сказать-то?
Ну да. Я могу сделать эти проверки в динамике.
Но нахрена мне такое счастье если вместо ошибок компиляции все эти проверки будут делаться рантаймом.
Что мне это даст?
Где профит?

M>Веб сам по себе — это сплошная слабоструктурированная информация. Из недавнего. http://www.janrain.com/ позволяет унифицировать логин на сайте через всякие твиттеры, фейсбуки и т.п. В возвращаемых значениях из 16 полей они могут гарантировать наличие аж 2-х.
Гы.
Там есть имена и типы всех данных.
А то что данные могут отсутствовать так на то у нас option есть...

M>Если не нужен, мы его не пишем. Делов-то ЖчяЖ
В том то и дело что в динамике оно всегда нужно.

WH>>С тормозами, без помощи компилятора и IDE...
M>Опять начинаются какие-то сферовакуумные кони.
M>Ты можешь написать генератор кода для получения данных на макросах на Немерле.
M>Ты можешь написать генератор кода для получения данных на макросах на Лиспе.
Но ты всеравно не получишь ни автокомплита ни проверок компилятора.

M>Не включаю. Вообще не понимаю, что ты имеешь под декларативной проверкой структуры.
Описал структуру и оно само все проверилось.

M>Скачал IDEA для Java. В пяти попытках рефакторинга она мне предложила такой же ломающий рефакторинг. И это — на статистически типизированом языке, в котором это должно быть раз плюнуть, не?
Сколько пользовался ReSharper'ом ни разу такого небыло.

WH>>И это коммерческая IDE которую люди пишут полный рабочий день.
M>И не парятся. Потому что
Почему?

M>Ты или эта — одинаковые стандарты используй или вообще никакие. Для Немерле, значит, рефакторинг не нужен, а для любого сравниваемого с ним языка — ВНЕЗАПНО нужен?
Рефакторинга нет ибо автокомплит более приоритетен, а ресурсов мало. По этому автокомплит сделали, а до рефакторинга просто руки не дошли. Но вся нужная информация у нас уже есть.
Вот собственно все что я хотел сказать.

Но PyCharm даже автокомплит и навигацию не умеет.
И я об этом уже писал:

WH>>За то автокомплит, навигация и подсветка ошибок работают как часы.
WH>>И это при том что ее делают в свободное от работы время.

WH>>Так что IDE для динамики больше не вспоминай. Это блокноты с раскраской синтаксиса.

Но ты включил избирательное чтение.
То что тебе не нравится игнорируешь.

M>У меня ошибки сводятся к алгоритмическим. Может, потому что часть мозга, которая у тебя занята поисками нужных типов для задачи, выделяется для собственно решения задачи?
Нет. Я просто пишу код так что алгоритмические ошибки почти всегда сводятся к ошибкам типизации.

M>Есть у меня сайтец один. На HYH/ Два раза были проблемы с производительностью. Первый раз — с Апачем, замена на nginx помогла. Второй раз — с MySQL, тюнинг MySQL'я помог. Ни разу проблема с производительностью не упиралась в HYH/
HYH? Что это?
Может PHP?
Ну от того что с твоей карликовой нагрузкой у тебя с ним нет проблем это не значит что у других нет.

M>Хотя ты там все равно ни хрена не увидишь.
Что сразу слив засчитываем?

M>А умные люди увидят, что:
Что сравниваются куча не понятных реализаций.
Бенчмарки без исходников фуфло полное.
Всегда.

M>СКОРАСТЬ!!!!!!одинодинодинодинодин
M>!!!!!!одинодинодинодинодинодин).
Тебя заклинило?

M>Я их не отрицаю. Я тебе тупо твержу одну вещь: никого не интересует сферовакуумная скорость
У тебя похоже все сферовакуумное.
И скорость. И надежность.

M>>>Профит у людей, которые не думают о языках в терминах сферовакуумности того или иного языка.
WH>>В воображении.
M>исключительно в твоем. исключительно в твоем.
Это разве я тут твержу о профите динамики?
Я наоборот говорю что его нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Гарантирует не язык, а описаные ручками типы из стандартной библиотеки. То есть, они гаранируют до тех пор, пока нет ошибок в реализации этих типов.
Ну так разумеется никто не будет в язык конкретные типы хардкодить.
Но сами то типы проверяет компилятор.

M>Что так он «гарантирует»...
Чтение у тебя как всегда изберательное. Осилил жа 2 пункта из 7.

M>Хм... Вот тут есть то же самое, практически, только для Erlang'а: http://code.google.com/p/erlyweb/source/browse/#svn/trunk/src/erlydb
Послал так послал.
Ты мне прикладной код покажи.

M>Что тут дает статика? А ничего она не дает.
Ну так если упорно игнорировать факты то...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Опять та скорость. Нахрена мне нужна скорость, если все упрется
Во что? В БД? Так я тебе и говорю что БД тут нахрен не нужна.

У тебя задача "найти", а не "найти в БД".

M>На порядок максимум.
Не максимум, а минимум.

M>Повторю в пятидесятый раз. Сферовакуумная скорость никому не интересна. Всегда есть задача — сделать столько-то и столько0то в таких-то пределах. Скорость ради скорости нужна, судя по всему, только тебе.
То-то ты плакался на форуме что у тебя все тормозит.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

D>Можно подобрать такое соотношение размера проекта и нормальной ide, что код будет написан с минимальным количеством тех ошибок которые мог бы отловить компилятор.
С учетом того что IDE для динамики говно это может быть либо очень маленький проект либо статически типизированный язык.

D>Какой тогда от него толк кроме как как лишней траты времени на компиляцию?
Скорость. Надежность. Работающая IDE.
Мало?

D>База может уже быть или
Это маловероятно.

D>

D>@foreach(var row in internet.Query("http://test.com/getproducts.json")){
D>

И как система отреагирует на отсутствие одного из полей?
А на облом запроса?

WH>>Кстати а как у этого твоего фреймворка с эскейпом строк?
D>Фреймворк микрософта, Все эксейпится.
WH>>А с защитой от инекций кода?
D>Присутствует.
Я думаю ты ошибаешься
http://www.google.ru/search?q=security+webmatrix+&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ru:official&client=firefox#hl=ru&newwindow=1&client=firefox&hs=SwD&rls=org.mozilla:ru:official&&sa=X&ei=HXW8TLD2IYWCOrDp_IcH&ved=0CCIQBSgA&q=code+injection+webmatrix&spell=1&fp=f1309cfaab7a60fb

WH>>А с генерацией не валидного HTML?..
D>Мелочи.
Хренасе мелочи.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>>>А с генерацией не валидного HTML?..
D>>Мелочи.
WH>Хренасе мелочи.

Валидный HTML (т.е. который проходит валидатор от w3c) — действительно мелочи.

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

WH>Скорость. Надежность. Работающая IDE.
В вебе не нужна. Что то абстрактное. Думаю пройдет лет пять и иде для динамики будут на уровне.
WH>Мало?
Да.

D>>База может уже быть или
WH>Это маловероятно.
Если сайт прикручивается к уже существующий системе, то нет.

D>>

D>>@foreach(var row in internet.Query("http://test.com/getproducts.json")){
D>>

WH>И как система отреагирует на отсутствие одного из полей?
WH>А на облом запроса?
Как реализуете, так и будет, может упасть а может и промолчать.
А как ur отреагирует на эти пункты?

WH>Я думаю ты ошибаешься
Нет, ну понятно что если человек стреляет себе в голову, то его никто не остановит.
Как ur себя поведет с "Select Count(*) From Users Where Username = '" + @Request["username"] + "' And Password = '" + @Request["password"] + "'"?

WH>>>А с генерацией не валидного HTML?..
D>>Мелочи.
WH>Хренасе мелочи.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

WH>>Скорость. Надежность. Работающая IDE.
D>В вебе не нужна.
Смотря кому.

D>Что то абстрактное.
Поиск ошибок это весьма конкретное.

D>Думаю пройдет лет пять и иде для динамики будут на уровне.
Не будут.
Там фундаментальные проблемы.
Я тут уже приводил кусок кода.
Понять какие методы нужно переименовывать, а какие нет невозможно как ни крутись.

WH>>Мало?
D>Да.
Странно. Плюсы есть. Минусов нет. А всеравно берешь динамику.
Как-то не рационально. Не находишь?

D>Если сайт прикручивается к уже существующий системе, то нет.
В любом случае одну сроку едвали можно назвать оверхедом.

D>Как реализуете, так и будет, может упасть а может и промолчать.
Из этого кода совершенно не ясно.

D>А как ur отреагирует на эти пункты?
Не знаю сделано ли это в ur'е но я бы сделал типизированный запрос и тогда этот вызов вернул бы либо ошибку либо гранатированно верный результат.
Причем он компилятор заставил бы тебя обработать оба варианта.
И это правильно. Ибо игнорирование ошибок это само по себе ошибка.

WH>>Я думаю ты ошибаешься
D>Нет, ну понятно что если человек стреляет себе в голову, то его никто не остановит.
D>Как ur себя поведет с "Select Count(*) From Users Where Username = '" + @Request["username"] + "' And Password = '" + @Request["password"] + "'"?
А никак. Это просто не будет скомпилировано.

В этом и есть надежность которая для тебя нечто абстрактное.

D>Ну может я какой то особенный, но как то сразу получается писать валидный html, да иногда можно ошибится, но при открытии страницы, плагин к браузеру скажет что есть ошибка. Да было бы полезно, но реально мелочь.
Видимо в этом между нами разница.
Я не считаю ошибки молочью.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ВВ>По поводу Perl не знаю, но то, что Ruby и Python ниже порого вхождения, чем, скажем, у C#... Эта мысль мне кажется несколько сомнительной. Ну начнем хотя бы с того, что там вообще-то тоже надо знать, что такое "класс".

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

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

ВВ>У интерпретаторов Питона и Руби есть встроенная поддержка обработки HTTP запросов?

У питона есть в стандартной библиотеке http://docs.python.org/library/internet.html

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

ВВ>А я вам ответил, что Руби и Питон как языки по крайней мере НЕ проще. И порог вхождения там никак не может быть ниже. А писать без знания ООП можно и на Джаве с Шарпом, что многие вполне успешно делают.

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

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

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

WH>>>Скорость. Надежность. Работающая IDE.
D>>В вебе не нужна.
WH>Смотря кому.

D>>Что то абстрактное.
WH>Поиск ошибок это весьма конкретное.

D>>Думаю пройдет лет пять и иде для динамики будут на уровне.
WH>Не будут.
WH>Там фундаментальные проблемы.
WH>Я тут уже приводил кусок кода.
WH>Понять какие методы нужно переименовывать, а какие нет невозможно как ни крутись.
Думаю проблеммы не фундаментальные, человек же как то понимае что нужно переименовывать, добавить еще пару тон логики и взлетит. Вообще, версия только 1.0, если уж пинать кого нужно было так это RubyMine.

WH>Как-то не рационально. Не находишь?
Тут так получается, если статика, то приходится либо C# либо Java. И тут вылазиют минусы, много букв, отсутвие мп и пр. Да в сферическом вакууме с нормальными языками, статика это хорошо, но то что сейчас можно использовать это не особо интересно.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

ВВ>>А я вам ответил, что Руби и Питон как языки по крайней мере НЕ проще. И порог вхождения там никак не может быть ниже. А писать без знания ООП можно и на Джаве с Шарпом, что многие вполне успешно делают.
FR>Как языки да не проще, но порог вхождения при этом ниже и существенно, сам не раз наблюдал, дизайнеры и даже художники разработчики игр
FR>вполне быстро осваивают.

Ну дело в том, что я нечто похожее наблюдал и для дотнета. К слову, тот VB.NET + Option Explicit Off + Option Strict Off — это по сути тот же VBScript.

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

FR>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>У интерпретаторов Питона и Руби есть встроенная поддержка обработки HTTP запросов?
FR>У питона есть в стандартной библиотеке http://docs.python.org/library/internet.html

С библиотеками все понятно, но тут человек утверждает, что у него print "Hello, world!" будет законченным веб-приложением на питоне "без всяких фреймворков".

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

D>Думаю проблеммы не фундаментальные, человек же как то понимае что нужно переименовывать, добавить еще пару тон логики и взлетит. Вообще, версия только 1.0, если уж пинать кого нужно было так это RubyMine.
Ну и как ты в том коде поймешь что переименовавать?
Это не возможно.

D>Тут так получается, если статика, то приходится либо C# либо Java. И тут вылазиют минусы, много букв, отсутвие мп и пр. Да в сферическом вакууме с нормальными языками, статика это хорошо, но то что сейчас можно использовать это не особо интересно.
Языки вполне конкретные.
Немерле например. Не скажу за другие но он вполне продакшен качества. И даже очень не плохая IDE есть.
Похуже чем для жабошарпов (у нас нет людей которые полный рабочей день писали бы код) но много лучше чем даже насквозь коммерчиские IDE для динамики.

D>Вообще ветка была про порог вхождения, и лишняя строка это порог поднимает.
Ну просто звездец как поднимает что аж невозможно понять что к чему.
Кстати а как у этого вебматрика с аяксом?
До UR'а хотябы дотягивает?
И имей в виду что в случае UR'а весь код пишется на одном языке. И о жабоскрипте не нужно даже знать.
Как по твоему это влияет на порог вхождения?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ВВ>С библиотеками все понятно, но тут человек утверждает, что у него print "Hello, world!" будет законченным веб-приложением на питоне "без всяких фреймворков".

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

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

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

D>>Думаю проблеммы не фундаментальные, человек же как то понимае что нужно переименовывать, добавить еще пару тон логики и взлетит. Вообще, версия только 1.0, если уж пинать кого нужно было так это RubyMine.
WH>Ну и как ты в том коде поймешь что переименовавать?
WH>Это не возможно.
Очевидно что будет какой то дополнительный код, из контекста которого можно понять что к чему.

D>>Тут так получается, если статика, то приходится либо C# либо Java. И тут вылазиют минусы, много букв, отсутвие мп и пр. Да в сферическом вакууме с нормальными языками, статика это хорошо, но то что сейчас можно использовать это не особо интересно.
WH>Языки вполне конкретные.
WH>Немерле например. Не скажу за другие но он вполне продакшен качества. И даже очень не плохая IDE есть.
WH>Похуже чем для жабошарпов (у нас нет людей которые полный рабочей день писали бы код) но много лучше чем даже насквозь коммерчиские IDE для динамики.
Да, но завтра Владу на голово упадет кирпич или например микрософт таки сделает мп у шарпа,
и Немерле уйдет в небытье. Риски большие и доказать мифическую выгоду сложно.

D>>Вообще ветка была про порог вхождения, и лишняя строка это порог поднимает.
WH>Ну просто звездец как поднимает что аж невозможно понять что к чему.
Вы поставте себя на место новичка. Каждую лишнюю конструкцию нужно держать в голове.
Идею взял что захотел и начал использовать проще понять чем, извини у нас тут статическая типизация, которая непонятно зачем тебе нужна но ты должен написать еще вот это и вот это.
WH>Кстати а как у этого вебматрика с аяксом?
WH>До UR'а хотябы дотягивает?
WH>И имей в виду что в случае UR'а весь код пишется на одном языке. И о жабоскрипте не нужно даже знать.
WH>Как по твоему это влияет на порог вхождения?
На порог вхождение это влияет конечно положительно. Но у нас всетаки динамика вс статика.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

D>Очевидно что будет какой то дополнительный код, из контекста которого можно понять что к чему.
Контекстом я тебе еще больше все запутаю...

D>Да, но завтра Владу на голово упадет кирпич или например микрософт таки сделает мп у шарпа, и Немерле уйдет в небытье. Риски большие и доказать мифическую выгоду сложно.
Ну там далеко не только Влад все делает.
А что касается МП в C# не смешите мои тапочки.
МП без сравнения с образцом, алгебраических типов и квазицитирования настолько убого что аж жуть.
Думаешь МС пойдет на столь радикальные изменения в C#?
Да ни в жизнь.
Это язык для индусов.
А они это не поймут.

D>Вы поставте себя на место новичка. Каждую лишнюю конструкцию нужно держать в голове.
Давай определимся.
Либо новичек. Либо база данных уже есть.
А раз базы нет то эту строчку придется написать как ни крути.

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

D>На порог вхождение это влияет конечно положительно. Но у нас всетаки динамика вс статика.
Ну так покажи как с этим динамика справится.
Начни с того как она определит какой код нужно скомпилировать в С, какой в жабаскрипт, а какой и так и так.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>>Пункт 1 — проблемы твоего восприятия, ты бы такое же рассказывал про Erlang.
WH>А что в эрланге у нас уже можно шарить изменяемые данные?

Да в общем-то давно можно.

init_globals() ->
  ets:new(globals, [named_table, set, public]).

set_foo(X) ->
  ets:insert(globals, {foo, X}).

get_foo() ->
  [{_, X}] = ets:lookup(globals, foo),
  X.

Главное здесь — слово public. Если protected, посторонний процесс сможет только читать, а private — не сможет даже читать.

Некоторые приложения, как стандартный application, принципиально опираются на этот механизм.

Между разными нодами это не сработает напрямую, но тебе ничто не мешает завести процесс-холдер.

N>>У тебя явные проблемы с логикой, если ты один частный пример воспринимаешь как правило и ограничение.
WH>Если уж вводишь термины то делай их как следует.

Мы всё-таки пока не монографии пишем. Это не отмазка, но факт.

Термины будут отработаны по ходу.

N>>И что? Расскажи подробнее. Ах да, я с тобой спорю и осмеливаюсь с тобой не соглашаться...\
WH>Про естественность/искуственность ограничений начал ты

Верно. Потому что ты смешал совершенно разные классы ограничений, пришлось вмешаться.

N>>Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz.
WH>Да все просто. Нет теста. И еще не скоро будет. Но я и так знаю что все впорядке.

Святым духом знаешь? Мне бы такую уверенность...

N>>Я не ищу заговоры, но тенденция использовать наиболее показательные примеры настолько очевидна, что предполагать обратное бессмысленно.
WH>Ну так я и показал первый попавшейся пример где статика помогла мне отвефакторить кучу кода.
WH>Могу еще комиты с подобным действом найти но смысл?

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

N>>Если да, тогда они мне просто неинтересны — у тебя другой мир, в котором, возможно, статическая типизация и способна сыграть настолько важную роль.
WH>А может я просто использую правильные языки и грамотно подхожу к тому чтобы уложить задачу в типы?

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

N>>Зато это полностью живой, настоящий пример, из которого ничего не упрощено. И да, он приведен для того, чтобы показать, насколько сложности ТЗ и спецификации преобладают над проблемами кодирования.
WH>Я не могу на этот твой пример ничего ответить просто по тому что я не понял половину слов.
WH>Сленг который ты использовал для меня ничего не значит.

А он тут и не сильно важен (хотя может быть освоен за 5 минут). Если ты просто нарисуешь по квадратику для каждой названной сущности и протянешь стрелки связей — уже увидишь сложность ситуации.

N>>Вот относительно свежий пример — исправление одного долго тянущегося бага свелось к перестановке одной команды (отцепить UA от контроллера) на строку выше, чтобы UA успел получить штатный сигнал дисконнекта. Никакие _типы_ этому не помогут, если в функционирование типа не вложишь полную FSM работы UA.
WH>Вот! Сам же знаешь ответ.

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

WH>И заложить в тип FSM это очень просто. Для этого даже зависимые типы не нужны.
WH>Можно даже LL(1) закатать не особо напрягаясь.

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

WH>>>Так держать. Авось чтонибудь да докажешь.
N>>Ещё один переход на личности. Сливаешь?
WH>Где?
WH>Я просто говорю про ущербность подобной аргументации.

Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно".

N>>Так попытайся хотя бы навскидку предложить мне такое различие, которое бы помогло отловить все эти вещи на компиляции. А что ты думал — покажешь пару школьных примеров и этим кого-то убедишь?
WH>Что значит выделенное?
WH>И чем тот пример с изменением кучи кода школьный?

Тем, что показывает наиболее примитивное применение типа и компилятора.

WH>Если ты о том что нужно в протокол добавить поддержку расширения это ни разу не проблема.

Ну расскажи, как ты это будешь делать.

N>>подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам,
WH>И в чем проблема?

Ну и как ты это будешь решать?

N>>или отображение твоего кода в чужом фрейме.
WH>Почему это должно меня волновать?

Потому, что понятие valid HTML может иметь достаточно тонкие зависимости от такого вложения.

N>>Что неполный — верю. Остальное — сомнительно. Например, пункт 5 — сознательные ограничения и если тебя они не устраивают, это только вопрос вкусовщины.
WH>Исли мне каждый раз явно придется писать привидения от потомка к базе то я прокляну все на свете.

По-моему, именно такие приведения там не нужны.

WH>А что касается перегрузки операторов то мне и этого мало.
WH>Я сейчас работаю над парсером для немерле2 там можно будет вообще как угодно над синтаксисом издеваться.
WH>Что позволит сделать произвольный ДСЛ.

Y A C C по новой, да?

N>>Tutorial просто не успели выправить. Так можно долго продолжать, истинно здесь только одно: ты настолько односторонне хочешь видеть мир, что отказываешься принимать запросы других.
WH>Ну да. Использование глобальных переменных это конечно правильно.
WH>А я один кому это категорически не нравится.

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

WH>Вот как это надо делать:
WH>

WH>[CommandLineParser]
WH>class Options
WH>{
WH>    [HelpMessage("don't print final newline")]
WH>    [Name("n")]
WH>    public OmitNewline : bool = false;
WH>}
WH>

WH>Может чуть больше слов за то понятно даже не зная как это все работает.

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

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

ВВ>Я так понимаю, ты представляешь тут другое направление в споре динамика вс. статика. Т.е. пытаешься динамику выводом типов лечить. Так вот — лечить динамику выводом типов не надо. Динамика — это не болезнь

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

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

Еще динамика — это чудовищное количество ошибок порождающее чудовищное количество тестов.

Так что плата очень даже зримая.

Что же касается позднего связывания и вытекающих из этого какой-то "просто чудовищной гибкости", то не надо ля-ля. Динамика дает два бенефита:
* Повсеместный динамический полиморфизм. Не факт что это преимущество. Для меня — человека делающего не мало ошибок — это скорее зло. Аналог этого свойства в статике виртуальные методы, интерфейсы и вариантные типы с паттерн-матчингом. Все перечисленное конечно требует несколько большего применения мозга для использования, но при наличии незначительных зачатков образования не так уж сложны в применении.
* Динамическое метапрограммирование. Я уже не говорю, что это фича реализуется далеко не в каждом скрипте. Но там где она реализуется кроме гибкости она создает не мало проблем. Это и дичайшие тормоза. И невозможность эффективной джит-компиляции или пре-компиляции такого кода. И трудно-уловимые ошибки. Ну, а замена этому делу в статике — это макросы. Мы просто переносим все это дело во время компиляции и делаем процесс детерминированным и проверяемым.

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

WH>Автоматический рефакторинг для динамики сделать нельзя. Вообще никак. В лучшем случае получится что-то типа текстовой замены когда одно имя заменяется сразу во всей программе.

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

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

L>Тесты же.

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

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

N>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции?

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

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

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

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

M>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.

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

.

Другими словами, какова аудитория, таковы и ответы.

Спросили бы они у меня, и я бы ответил утвердительно. Хотя как они это сделали бы я понять не могу.

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

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

Тесты нужны и для статики. Но таки — да — объем тестов для динамики нужен существенно больший.
А вот с тем, что динамика дает существенный выигрышь в объеме кода вообще не соглашусь. Язык с паттерн-матчингом, вводом типов и макрами позволяет иметь приблизительно такой же объем кода что и у динамики. Иногда больше, а иногда и меньше (причем существенно).

Тут существенными фичами сокращающими объем кода становятся наличие метапрограммировния и паттерн-матчинга. Если в скрипте их нет (как например в Визуал Васике), то такой скрипт сосет по полной программе.

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

N>С другой стороны, есть достаточно мало ситуаций (по моему опыту), которые требуют специфических тестов именно для динамики: если тест прошёл — то код работает правильно, и все операции с типами выполнены правильно.

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

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

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

) Если ты пользуешься только теми возможностями, которые обычно ассоциируются со статическими языками, то у тебя даже простейший duck typing не будет работать.

Не кажется. Статика != старье и убогость. Статика не менее динамична за счет компонентного подхода и динамического полиморфизма (но контролируемого во время компиляции).

N>"Никаких проблем", если ты фактически принесёшь с собой компилятор (может, ещё и с JIT).

А в чем проблема то? Компилятор — это мелка длл-ка (от 100 КБ, до 3 МБ).

N> Во многих случаях это удовольствие сильно дороже, чем просто интерпретатор.

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

WH>>И таки да. Вы все знаете о каком языке я говорю.

N>Неужели Algol 68?

Ах да, он на дотнете не работает...

Точно! В дырочку! Разбегаемся.

N>P.S[2]. А расскажите мне, каким образом в ASP.NET (я не перепутал название?) делается смена кода на ходу. Интересны именно механизмы и их ограничения.

За счет динамической компиляции и компонентного подхода. Я заработал пятерку?

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

WH>И этот движок разбирает C# со скоростью более 2х мегабайт в секунду на моей машине.
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser

На моей ~ 3.

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

N>>P.S[2]. А расскажите мне, каким образом в ASP.NET (я не перепутал название?) делается смена кода на ходу. Интересны именно механизмы и их ограничения.

VD>За счет динамической компиляции и компонентного подхода. Я заработал пятерку?

Не-а, потому что это ответ уровня "Как едет машина? — на энергии сгорания". Он годится только для того, чтобы отличить от других подходов на ресурсном уровне, но не для сколь-нибудь внятного описания и внутренних процессов, и процессов управления.

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

Без этих данных ответ годится только на двойку, не выше.

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

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

N>>В первой строчке тела ошибка в коэффициенте. Как ты предлагаешь с помощью статической типизации выловить эту ошибку на этапе компиляции?

VD>Ошибка будет выявлена когда твой код будет использован в функциональном тесте. Он просто даст неверный результат.

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

VD>Но даже при наличии юнит-тестов их будет нужно намного меньше. Это тоже практика.

Верю. Хотя для моих задач практической разницы нет.

M>>Гарантирует не язык, а описаные ручками типы из стандартной библиотеки. То есть, они гаранируют до тех пор, пока нет ошибок в реализации этих типов.
WH>Ну так разумеется никто не будет в язык конкретные типы хардкодить.
WH>Но сами то типы проверяет компилятор.

Где и когда он их проверяет? При генерации SQL'я на основе данных, полученных от пользователя во время работы программы? При генерации HTML'я на основе данных, вытягиваемых из базы данных? Не смешите мои тапочки. Runtime Exception в случае неверных данных там гарантировано.

M>>Что так он «гарантирует»...
WH>Чтение у тебя как всегда изберательное. Осилил жа 2 пункта из 7.

Ко всему остальному там точно так же.

M>>Хм... Вот тут есть то же самое, практически, только для Erlang'а: http://code.google.com/p/erlyweb/source/browse/#svn/trunk/src/erlydb
WH>Послал так послал.
WH>Ты мне прикладной код покажи.

примеры по досаточно старой версии тут: http://yarivsblog.com/articles/2006/08/29/introducing-erlydb-the-erlang-twist-on-database-abstraction/

поновее тут: http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/

везде гарантируется валидность SQL-кода.

M>>Что тут дает статика? А ничего она не дает.
WH>Ну так если упорно игнорировать факты то...

Ну и расскажи мне, что она там делает в http://www.impredicative.com/ur/demo/sql.ur.html в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции.

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

Ну и расскажи мне, что как оно само работает в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции.

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

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

Тормознута в основном не динамика, тормознуты интерпретаторы по вполне очевидным причинам. Я тебе приводил разницу между V8 и JScript по производительности. При этом ECMAScript весьма беспредельный язык, в котором характеристика "динамичный" относится далеко не только к типизации.

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

VD>Еще динамика — это чудовищное количество ошибок порождающее чудовищное количество тестов.

Много ли ты писал на языках с динамической типизацией? Это "детский страх", не более того. Заметь сейчас многие крупные компании активно используют динамические языки — тот же Гугл и Питон. Их может не устраивать производительность, но вот динамичность почему-то устраивает всех. В противном случае, зачем бы он был нужен. От того, что на RSDN-е теоретизируют о "чудовищном количестве ошибок" и "чудовищном количестве тестов" эти языки не станут менее удобными.

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

VD>Так что плата очень даже зримая.

Бесспорно. Точно так же, как и за статику.

VD>Что же касается позднего связывания и вытекающих из этого какой-то "просто чудовищной гибкости", то не надо ля-ля. Динамика дает два бенефита:
VD>* Повсеместный динамический полиморфизм. Не факт что это преимущество. Для меня — человека делающего не мало ошибок — это скорее зло. Аналог этого свойства в статике виртуальные методы, интерфейсы и вариантные типы с паттерн-матчингом. Все перечисленное конечно требует несколько большего применения мозга для использования, но при наличии незначительных зачатков образования не так уж сложны в применении.

Вообще-то все несколько интереснее, чем ты тут пытаешь представить. Простая, так сказать, наивная статика засовывает программиста в жесткие тиски прямой как известная кишка системы типов — ни вправо, ни влево, ни даже развернуться не получается. Зато все достаточно просто, понятно, и все под контролем у компилятора. *Естественно*, что такое положение дел не устраивает никакого.
И тут начинается — притягиваем параметрический полиморфизм, экзистенциальные типы, row type полиморфизм и прочая и прочая. В итоге языки концептуально дико усложняются, компиляторы усложняются с соответствующими последствиями, изучать все это добро становится непросто, еще немного и впору будет диссертации по этим языкам писать.
А это, к чему приходим-то в итоге? Посмотри вот на полиморфные варианты в том же ОКамл — это ж та же динамика, вид сбоку, со всеми своими недостатками.

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

VD>* Динамическое метапрограммирование. Я уже не говорю, что это фича реализуется далеко не в каждом скрипте. Но там где она реализуется кроме гибкости она создает не мало проблем. Это и дичайшие тормоза. И невозможность эффективной джит-компиляции или пре-компиляции такого кода. И трудно-уловимые ошибки. Ну, а замена этому делу в статике — это макросы. Мы просто переносим все это дело во время компиляции и делаем процесс детерминированным и проверяемым.

А каким образом Гугл умудряется Джитить ECMAScript?

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

ВВ>>С библиотеками все понятно, но тут человек утверждает, что у него print "Hello, world!" будет законченным веб-приложением на питоне "без всяких фреймворков".
FR>Ну в общем так и есть питон из коробки дает возможность очень легко делать простенькие веб приложения.

Из коробки "с батарейками"? Ну в самом деле, что значит "из коробки"?
Без библиотек и фреймворков ни Питон, ни какой-нибудь Си-шарп веб-приложения писать не позволяют. А сделать в дотнете специальный "модуль", благодаря которому Console.WriteLine("Hello, world!") предвратится в веб-приложение тоже проблем не составляет.

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

ВВ>>По поводу Perl не знаю, но то, что Ruby и Python ниже порого вхождения, чем, скажем, у C#... Эта мысль мне кажется несколько сомнительной. Ну начнем хотя бы с того, что там вообще-то тоже надо знать, что такое "класс".
FR>В питоне необязательно, помню поддерживал довольно объемный код чистейшая процедурщина в стиле старого паскаля.

Ну вот мне интересно. Сейчас вот вполне серьезно обсуждается возможность сделать С# более "scripty". Т.е. появится возможность писать код без всякого объявления классов (как уже можно, кстати, в Немерле). Если эту возможность добавят, то порог вхождения сразу снизится что ли?

А с процедурным стилем и так все вроде отлично обстоит.

M>>Нет, ты мне не показал, как ее решить быстро. Ты решил, что ты — единственный, который знает такие умные термины, как ДКА, НДКА и т.п.
WH>Ты похоже их не знаешь.

О да, все тупые, один Wolfhound д'артаньян.

M>>Подходи. Мы уперлись в то, что нам даром не нужна сферовакуумная скорость какого-то там языка. Потому что скорость генерации данных и так высока — доли секунды. Все упирается в запись этих данных. Но нет.
WH>Тут ты вполне однозначно говоришь что тебе нужен быстрый поиск.
WH>Re[2]: Поможите. Одна комната, много детей :)
WH>Я тебе сказал как сделать предельно быстрый поиск.

К сожалению, он не учитывает тонны мелких нюансов.

WH>Но ты похоже уперся в то что искать должна БД.
WH>Но все что вы на пару с Синклером придумали это линейный поиск.
WH>Что и не удивительно. Ибо БД на подобную работу не затачивалась.

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

M>>Ах. Да, действительно. Вах. некий эксперимаентальный язык, который действительно, в случае системы типов, более строгой, чем в Хаскелле, позволяет это сделать.
WH>Те ты признал что статика таки это может.
WH>Уже хорошо.

Не может она. Ты не знаешь, что у тебя за данные будут на этапе компиляции.

M>>Только строгая типизация != статическая типизация.
M>>Итак. Что ты хотел сказать-то?
WH>Ну да. Я могу сделать эти проверки в динамике.
WH>Но нахрена мне такое счастье если вместо ошибок компиляции все эти проверки будут делаться рантаймом.
WH>Что мне это даст?
WH>Где профит?

Оно так или иначе будет делаться рантаймом. Ты не знаешь, что у тебя будет в row.T.A когда программа будет работать.

M>>Веб сам по себе — это сплошная слабоструктурированная информация. Из недавнего. http://www.janrain.com/ позволяет унифицировать логин на сайте через всякие твиттеры, фейсбуки и т.п. В возвращаемых значениях из 16 полей они могут гарантировать наличие аж 2-х.
WH>Гы.
WH>Там есть имена и типы всех данных.
WH>А то что данные могут отсутствовать так на то у нас option есть...

Я тебе пример с JanRain приводил. Заманаешься на все option'ы ставить.

M>>Если не нужен, мы его не пишем. Делов-то ЖчяЖ
WH>В том то и дело что в динамике оно всегда нужно.

Не всегда.

WH>>>С тормозами, без помощи компилятора и IDE...
M>>Опять начинаются какие-то сферовакуумные кони.
M>>Ты можешь написать генератор кода для получения данных на макросах на Немерле.
M>>Ты можешь написать генератор кода для получения данных на макросах на Лиспе.
WH>Но ты всеравно не получишь ни автокомплита ни проверок компилятора.

Которые, судя даже по рекламируемому тобой Ur'у все равно тебя не спасут.

M>>Не включаю. Вообще не понимаю, что ты имеешь под декларативной проверкой структуры.
WH>Описал структуру и оно само все проверилось.

Код в студию или не было.

M>>Скачал IDEA для Java. В пяти попытках рефакторинга она мне предложила такой же ломающий рефакторинг. И это — на статистически типизированом языке, в котором это должно быть раз плюнуть, не?
WH>Сколько пользовался ReSharper'ом ни разу такого небыло.

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

WH>>>И это коммерческая IDE которую люди пишут полный рабочий день.
M>>И не парятся. Потому что
WH>Почему?

Сорри, отвлекли, пока отвечал. Потом учто пробелмы типизации — это наименьшее из проблем, с которой сталкиваешься.

M>>Ты или эта — одинаковые стандарты используй или вообще никакие. Для Немерле, значит, рефакторинг не нужен, а для любого сравниваемого с ним языка — ВНЕЗАПНО нужен?
WH>Рефакторинга нет ибо автокомплит более приоритетен, а ресурсов мало. По этому автокомплит сделали, а до рефакторинга просто руки не дошли. Но вся нужная информация у нас уже есть.
WH>Вот собственно все что я хотел сказать.

Так не очень надо или нед ресурсов? Ты уже определись, да?

WH>Но PyCharm даже автокомплит и навигацию не умеет.
WH>И я об этом уже писал:
WH>

WH>>>За то автокомплит, навигация и подсветка ошибок работают как часы.
WH>>>И это при том что ее делают в свободное от работы время.

WH>>>Так что IDE для динамики больше не вспоминай. Это блокноты с раскраской синтаксиса.

WH>Но ты включил избирательное чтение.
WH>То что тебе не нравится игнорируешь.

Это взаимное.

M>>У меня ошибки сводятся к алгоритмическим. Может, потому что часть мозга, которая у тебя занята поисками нужных типов для задачи, выделяется для собственно решения задачи?
WH>Нет. Я просто пишу код так что алгоритмические ошибки почти всегда сводятся к ошибкам типизации.

Ну а пишу код так, что проблем с типизацией составляют хорошо, если 1% от моих ошибок.

M>>Есть у меня сайтец один. На HYH/ Два раза были проблемы с производительностью. Первый раз — с Апачем, замена на nginx помогла. Второй раз — с MySQL, тюнинг MySQL'я помог. Ни разу проблема с производительностью не упиралась в HYH/
WH>HYH? Что это?
WH>Может PHP?

PHP. PuntoSwitcher шаоит.

WH>Ну от того что с твоей карликовой нагрузкой у тебя с ним нет проблем это не значит что у других нет.

именно об этом я и говорю
СФЕРОВАКУУМНАЯ. СКОРОСТЬ. В. ОТРЫВЕ. ОТ. ЗАДАЧИ. НИКОГО. НЕ. ИНТЕРЕСУЕТ.

Сколько раз это еще сказать?

M>>Хотя ты там все равно ни хрена не увидишь.
WH>Что сразу слив засчитываем?

Твой? Безусловно.

M>>А умные люди увидят, что:
WH>Что сравниваются куча не понятных реализаций.
WH>Бенчмарки без исходников фуфло полное.
WH>Всегда.

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

СФЕРОВАКУУМНАЯ. СКОРОСТЬ. В. ОТРЫВЕ. ОТ. ЗАДАЧИ. НИКОГО. НЕ. ИНТЕРЕСУЕТ.

M>>СКОРАСТЬ!!!!!!одинодинодинодинодин
M>>!!!!!!одинодинодинодинодинодин).
WH>Тебя заклинило?

Заклинило именно тебя.

M>>Я их не отрицаю. Я тебе тупо твержу одну вещь: никого не интересует сферовакуумная скорость
WH>У тебя похоже все сферовакуумное.
WH>И скорость. И надежность.

Нет. Для тупых повторяю в нцатый раз: никого не интересует сферовакуумная скорость.

M>>>>Профит у людей, которые не думают о языках в терминах сферовакуумности того или иного языка.
WH>>>В воображении.
M>>исключительно в твоем. исключительно в твоем.
WH>Это разве я тут твержу о профите динамики?
WH>Я наоборот говорю что его нет.

Нет, именно ты твердишь о сферовакуумных понятиях. Сказочник.

M>>Опять та скорость. Нахрена мне нужна скорость, если все упрется
WH>Во что? В БД? Так я тебе и говорю что БД тут нахрен не нужна.

WH>У тебя задача "найти", а не "найти в БД".

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

M>>На порядок максимум.
WH>Не максимум, а минимум.

В указаной задаче — максимум.

M>>Повторю в пятидесятый раз. Сферовакуумная скорость никому не интересна. Всегда есть задача — сделать столько-то и столько0то в таких-то пределах. Скорость ради скорости нужна, судя по всему, только тебе.
WH>То-то ты плакался на форуме что у тебя все тормозит.

Где я плакался?

N>>С другой стороны, есть достаточно мало ситуаций (по моему опыту), которые требуют специфических тестов именно для динамики: если тест прошёл — то код работает правильно, и все операции с типами выполнены правильно.

VD>Тут такое дело... Если код прошел тесты, то мы можем гарантировать, что он будет работать в таких же условиях. В статике не так трудно проверить граничные условия параметров и тем самым покрыть большую часть случаев использования. В динамике же любая функция полиморфна, что означает, что написать тесты покрывающие все возможные граничные случаи невозможно. Так что использование кода в "непривычных для него" условиях неминуемо приведет к появления рантайм-ошибок которые не отловят тесты.

Со строгой типизацией можно отловить и это. При программировании в Erlang-овском стиле тем более.

M>>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.

VD>Им надо было прийти к продавцам на рынок и спросить куда надо засунуть Элнанг. Думаю им тоже подходящее местечко подсказали бы

.

VD>Другими словами, какова аудитория, таковы и ответы.

VD>Спросили бы они у меня, и я бы ответил утвердительно. Хотя как они это сделали бы я понять не могу.

Вывод. В отрыве от задач говорить о каких-либо преимуществах чего-либо над чем-либо как минимум не стоит.

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

N>В частности, не раскрыты следующие вопросы:
N>1. Срок жизни скомпилированного кода.
N>2. Пределы возможностей параллельного существования версий одинаково названного кода.
N>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.

При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

N>Я не видел, чтобы люди думали, например, "uint32", а не "целое число"

Я тоже не видел, бо томограф с собой не таскаю.

N>Получается иное: что человек в принципе не начинает с чёткого мышления о сущностях, и тем более о их типизации.

Не начинает. Но заканчивает. В итоге пока что любая программа обязана быть четкой и на 100% формальной спецификацией. Хоть в динамике, хоть в статике.

N> Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

N>>В частности, не раскрыты следующие вопросы:
N>>1. Срок жизни скомпилированного кода.
N>>2. Пределы возможностей параллельного существования версий одинаково названного кода.
N>>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.

AVK>При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.

В .NET 4 научились выгружать динамически генерируемые сборки

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

M>Вывод. В отрыве от задач говорить о каких-либо преимуществах чего-либо над чем-либо как минимум не стоит.

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

M>>Вывод. В отрыве от задач говорить о каких-либо преимуществах чего-либо над чем-либо как минимум не стоит.

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

1. Вычисления вычислению рознь.
2. Сферовакуумная скрость и сферовакуумная производительность никого не интересуют.

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

M>>>Гарантирует не язык, а описаные ручками типы из стандартной библиотеки. То есть, они гаранируют до тех пор, пока нет ошибок в реализации этих типов.
WH>>Ну так разумеется никто не будет в язык конкретные типы хардкодить.
WH>>Но сами то типы проверяет компилятор.

M>Где и когда он их проверяет? При генерации SQL'я на основе данных, полученных от пользователя во время работы программы? При генерации HTML'я на основе данных, вытягиваемых из базы данных? Не смешите мои тапочки. Runtime Exception в случае неверных данных там гарантировано.
Я начинаю сомневатся что я вообще с программистом разговариваю.

Типы в статически типизированном языке проверяет компилятор на этапе компиляции.
Твой к.о.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Ну и расскажи мне, что как оно само работает в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции.
Она его ескепит.
Твой к.о.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

M>>>>Гарантирует не язык, а описаные ручками типы из стандартной библиотеки. То есть, они гаранируют до тех пор, пока нет ошибок в реализации этих типов.
WH>>>Ну так разумеется никто не будет в язык конкретные типы хардкодить.
WH>>>Но сами то типы проверяет компилятор.

M>>Где и когда он их проверяет? При генерации SQL'я на основе данных, полученных от пользователя во время работы программы? При генерации HTML'я на основе данных, вытягиваемых из базы данных? Не смешите мои тапочки. Runtime Exception в случае неверных данных там гарантировано.
WH>Я начинаю сомневатся что я вообще с программистом разговариваю.

WH>Типы в статически типизированном языке проверяет компилятор на этапе компиляции.
WH>Твой к.о.

Еще раз. Что тебе дадут эти типы в процессе работы приложения?

Объясняю на пальцах, раз до тебя не доходит:

fun list () =
    rows <- queryX (SELECT * FROM t)
            (fn row => <xml><tr>
              <td>{[row.T.A]}</td> <td>{[row.T.B]}</td> <td>{[row.T.C]}</td> <td>{[row.T.D]}</td>
              <td><form><submit action={delete row.T.A} value="Delete"/></form></td>
            </tr></xml>);

Запустили программу на следующих данных:

A            B        C           D
--          --        --          --
/>          <j        <x = "a"    <a=a=a===>

Чем тебе помогло то, что компилятор уверен, что вернется правильный XML? Ничем. Потому что — сюрприз! сюрприз! — данные ВНЕЗАПНО появляются не на этапе компиляции, а на этапе работы программы.

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

M>>Ну и расскажи мне, что как оно само работает в случае, если в row.T.A невалидный XML. Только не надо мне рассказывать, что это известно на момент компиляции.
WH>Она его ескепит
WH>Твой к.о.

Ничем не отличается от динамики. Твой генералиссимус о.

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

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

N>>В частности, не раскрыты следующие вопросы:
N>>1. Срок жизни скомпилированного кода.
N>>2. Пределы возможностей параллельного существования версий одинаково названного кода.
N>>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.

AVK>При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.

"Последняя страница книги оказалась написана по-китайски" (tm). Что такое домен приложения? Догадка навскидку — это весь код в пределах какой-то логической группировки ("приложение"). Так?

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

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

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

N>>>В частности, не раскрыты следующие вопросы:
N>>>1. Срок жизни скомпилированного кода.
N>>>2. Пределы возможностей параллельного существования версий одинаково названного кода.
N>>>3. Принципы обновления данных долгоживущего кода, включая сгенерированные функции.

AVK>>При замене кода ASP.NET перегружает домен приложения. Осюда — ответы на твои вопросы тривиальны.

N>"Последняя страница книги оказалась написана по-китайски" (tm). Что такое домен приложения? Догадка навскидку — это весь код в пределах какой-то логической группировки ("приложение"). Так?

Нет.

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

N>Да в общем-то давно можно.

жуть
N>Главное здесь — слово public. Если protected, посторонний процесс сможет только читать, а private — не сможет даже читать.
N>Некоторые приложения, как стандартный application, принципиально опираются на этот механизм.
Но тут по крайне мере можно эту таблице залочить.
В go же данные никак и ничем не контролируются.
Те несколько потоков могут корежить один и тотже объект без какой либо синхронизации.
А это уже ужос ужос.

N>Мы всё-таки пока не монографии пишем. Это не отмазка, но факт.

Термины будут отработаны по ходу.
Просто из за косах терминов которые никто толком не понимает случается тупой флуд ибо испорченый телефон.

N>Верно. Потому что ты смешал совершенно разные классы ограничений, пришлось вмешаться.
Я всетки не вижу разници.
У нас есть задача.
У нас есть решатель.
Решение будет ограничено ограничениями и задачи и решателя.
И так как решатель у нас один и других не предвидится и не вижу смысла разделять эти понятия.

N>>>Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz.
WH>>Да все просто. Нет теста. И еще не скоро будет. Но я и так знаю что все впорядке.
N>Святым духом знаешь? Мне бы такую уверенность...
Существующая функциональность не сломалась. На это тест есть.

N>Смысл ровно тот же, с которым ты вообще сюда что-то пишешь: хочешь высказать свою точку зрения, кого-то убедить, от кого-то получить полезные комментарии. Но если ты будешь приводить примеры школьного уровня, это ни для кого не будет убедительным, скорее наоборот.
Почему ты считаешь этот пример школьным?
Реальный комит. В реальном проекте. Причем я бы сказал весьма не простом проекте.

N>Ну покажи более интересный пример. Сейчас в твоих примерах и высказываниях просто не за что зацепиться — всё предельно плоское, школьное и суконное.
Вышел я из возроста когда мне было в кайф наворотить веселые мегашаблоны на С++.
Теперь у меня весь код скучный. Даже тот который решает очень сложные задачи.

N>А он тут и не сильно важен (хотя может быть освоен за 5 минут). Если ты просто нарисуешь по квадратику для каждой названной сущности и протянешь стрелки связей — уже увидишь сложность ситуации.
Не увижу.
У меня мозг работает по другому.

N>Нет, не знаю. Видимо, потому, что ситуация таки сложнее, чем это кажется со стороны.
Но ты же его написал.
Вводим FSM на уровень системы типов. И все.

N>Во-первых, я говорил о необходимом условии, а не достаточном. Во-вторых, тут получается хитрая корреляция состояний разных автоматов... впрочем, что я это рассказываю, если ты всё равно смотреть не будешь?
Чтобы мне это все осознать мне нужно понять предметную область.

N>Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно".
Я тут уже который раз задаю вопрос: Где профит?
И ответа по существу нет.
Ни одного.
Повторю еще раз свои аргументы против динамики:
1)Скорость исполнения всегда ниже.
2)Компилятор не ловит ошибки. Совсем.
3)IDE фундаментально убогие.
А что у нас в плюсе?
Меньше кода?
По сравнению с С++, C# и Java? Да!
По сравнению с немерле? Нет!
Метапрограммирование? Так в немерле оно есть.
В чем профит?
Ну хоть что-то?

А если есть очевидные недостатки но не видно достоинств то зачем оно нужно?

Ответь хотябы ты.
На Мамута я уже не расчитываю.

N>Тем, что показывает наиболее примитивное применение типа и компилятора.
А оно всегда примитивное.
Но из кучи такого примитива строятся тучи контрактов за которыми невозможно следить без помощи роботов.

WH>>Если ты о том что нужно в протокол добавить поддержку расширения это ни разу не проблема.
N>Ну расскажи, как ты это будешь делать.
Ты действительно хочешь чтобы я тебе тут чиста ради флема спроектировал расширяемый протокол?
Причем под что-то сферовакуумное?
Это слишком большой объем работы.

N>>>подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам,
WH>>И в чем проблема?
N>Ну и как ты это будешь решать?
Что решать?
Пример проблемы пожилуста.

N>>>или отображение твоего кода в чужом фрейме.
WH>>Почему это должно меня волновать?
N>Потому, что понятие valid HTML может иметь достаточно тонкие зависимости от такого вложения.
Ты не понял. Почему меня должно волновать что кто-то засунет мой сайт в фрейм?
Это не мои проблемы.
Моя задача как разработчика сайта чтобы сайт в правильно работал в популярных браузерах. Не более того.

WH>>А что касается перегрузки операторов то мне и этого мало.
WH>>Я сейчас работаю над парсером для немерле2 там можно будет вообще как угодно над синтаксисом издеваться.
WH>>Что позволит сделать произвольный ДСЛ.
N>Y A C C по новой, да?
А что уже позволяет сделать так:

SomeFunction() : ...
{
    using XMLDsl;//Тут мы расширяем грамматику XML литералами
    def xml = <asd>$someVar</asd>;
}//А тут эта грамматика отключается

Причем вместе с ДСЛ подключаются автокомплит, подсветка и навигация по коду.
Так что як нервно курит в углу.
Благодоря статическо типизации если someVar будет иметь тип XML ее значение будет вставлено без изменений иначе оно будет сконвертировано в строку и заэскеплено.

Имея в руках подобное колдунство я любую динамику по объему кода уделаю...

N>Мне в общем-то пофиг, как ты назовёшь аналог getopt в твоей среде. Вопрос в том, как ты будешь потом эти данные использовать. Глобальные данные класса — это хак ровно того же уровня, что и просто глобальные переменные.
Ты имеешь в виду статические переменные класса?
Если да то полностью согласен.
Я уже давно пришол к выводу что их нужно запретить.
Пользы нет, а вред существенный.

Кстати с запретом глобальных переменных нужно запрещать всякие CreateFile ибо они по сути маскируют глобальные переменные.
Проблемы из-за них вполне конкретные.
Например я не могу взять и запустить какой попало код. Ибо злобный хацкер сможет сотворить что попало.
Чтобы с этим бороться мелкософт наворотил мега костыль по имени code access security который больше мешает чем помогает.

А всего то надо было при старте программы передавать в процесс сервис имен через который можно все что можно процессу.
В таком случае можно будет выполнить что попало. Все что нужно сделать для того чтобы это что попало не сделало гадость это не давать ему сервис имен.
Получаем http://en.wikipedia.org/wiki/Capability-based_security

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Еще раз. Что тебе дадут эти типы в процессе работы приложения?
RTFM

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

ВВ>Из коробки "с батарейками"? Ну в самом деле, что значит "из коробки"?

Это значит используя только стандартную библиотеку, которая обязательно идет с дистрибутивом питона.

ВВ>Без библиотек и фреймворков ни Питон, ни какой-нибудь Си-шарп веб-приложения писать не позволяют. А сделать в дотнете специальный "модуль", благодаря которому Console.WriteLine("Hello, world!") предвратится в веб-приложение тоже проблем не составляет.

Наверно, но насколько я понимаю в отличии от питона в коробку не положили.

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

ВВ>Ну вот мне интересно. Сейчас вот вполне серьезно обсуждается возможность сделать С# более "scripty". Т.е. появится возможность писать код без всякого объявления классов (как уже можно, кстати, в Немерле). Если эту возможность добавят, то порог вхождения сразу снизится что ли?

По моему да.

ВВ>А с процедурным стилем и так все вроде отлично обстоит.

Угу, но не для тех кто с нуля изучает.

M>>Еще раз. Что тебе дадут эти типы в процессе работы приложения?
WH>RTFM

Ссылку в студию. Если там начнутся сказки про автоматический искейпинг, то то же самое делается и в динамике.

N>>Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно".
WH>Я тут уже который раз задаю вопрос: Где профит?
WH>И ответа по существу нет.
WH>Ни одного.
WH>Повторю еще раз свои аргументы против динамики:
WH>1)Скорость исполнения всегда ниже.
WH>2)Компилятор не ловит ошибки. Совсем.
WH>3)IDE фундаментально убогие.
WH>А что у нас в плюсе?
WH>Меньше кода?
WH>По сравнению с С++, C# и Java? Да!
WH>По сравнению с немерле? Нет!
WH>Метапрограммирование? Так в немерле оно есть.
WH>В чем профит?
WH>Ну хоть что-то?

ВНЕЗАПНО.
Было вся динамика против всей статики. Стало динамика против одного только Немерле.

А на немерле уже есть веб-сервер, который по производительности приближается или равен nginx'у? А то тут голимая динамика, которая всегда медленне статики (тм) ВНЕЗАПНО равна ему по производительности. Бида-бида. Как с таким парадоксом жить.

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

ВВ>Я тоже раньше к динамике относился весьма негативно. По ровно тем же причинам, которые ты сейчас высказываешь. А потом действительно попробовал использовать. И оказалось, что разница между теорией и практикой весьма существенная.

Я ту же эволюцию проделал, тем кто не прошел бесполезно объяснять, любимый парадокс Влада в действии.

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

M>Объясняю на пальцах, раз до тебя не доходит:

Получение html/sql/xml/etc путем конкатенации строки, это, хм..., не очень хорошая практика, скажем так. Соответственно пример на редкость негодный.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

M>А на немерле уже есть веб-сервер, который по производительности приближается или равен nginx'у?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

M>>Объясняю на пальцах, раз до тебя не доходит:

AVK>Получение html/sql/xml/etc путем конкатенации строки, это, хм..., не очень хорошая практика, скажем так. Соответственно пример на редкость негодный.

Стоп-стоп-стоп. Как это негодный? Это — официальный пример с официального сайта.

Я не прошу многого. Я прошу малого.

Сайт заявляет, среди прочего:

Ur/Web programs "don't go wrong" in a very broad sense. Not only do they not crash during particular page generations, but they also may not:

— Suffer from any kinds of code-injection attacks
— Return invalid HTML
— Contain dead intra-application links
— Have mismatches between HTML forms and the fields expected by their handlers
— Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
— Attempt invalid SQL queries
— Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

This type safety is just the foundation of the Ur/Web methodology.

И дан этот пример: http://www.impredicative.com/ur/demo/sql.ur.html

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

Ответы. Цитирую:

Она ескейпит. Твой к.о.

RTFM

Вау. Это меня действительно заставило забросить всю динамику к чертям и срочно переводить все на статику. Ведь она ескейпит!

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

ВВ>>Из коробки "с батарейками"? Ну в самом деле, что значит "из коробки"?
FR>Это значит используя только стандартную библиотеку, которая обязательно идет с дистрибутивом питона.

ОК, а такой вариант прокатит:

<%= "Hello, world!" %>

Копируем в *.aspx файлик, файлик в виртуальную папочку. Все работает. Вроде лаконичность на уровне?

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

ВВ>Ну вот мне интересно. Сейчас вот вполне серьезно обсуждается возможность сделать С# более "scripty"

Кем обсуждается?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

FR>Наверно, но насколько я понимаю в отличии от питона в коробку не положили.

ASP.NET там с первой версии.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

M>>А на немерле уже есть веб-сервер, который по производительности приближается или равен nginx'у?

AVK>Вот только заслуга в этом не динамики, а хорошо реализованного рантайма. Написанного, замечу, совсем не на динамическом языке.

Я так и знал, что этот аргумент возникнет

У РНР рантайм написан на С, но РНР, как известно, достаточно медленный язык. Гуано
У Ruby рантайм написан на С (емнип), но Ruby, как известно, достаточно медленный язык. Гуано
У Python'а рантайм написан на С (емнип), но Python для местных гуру достаточно медленный язык. Гуано
У JavaScript'а рантайм написан на С/C++, но Javascript для местных гуру достаточно медленный язык. Гуано
У _любимы_скриптовый_язык_ рантайм написан на скорее_всего_с_или_другой_язык_со_статической_типизацией, но динамика по определению тормозит, ага. Гуано.

И только у Erlang'а рантайм написан на С (статически типизированый язык), поэтому его скорость — это заслуга рантайма.

Может быть эта... Все же не будем применять двойные стандарты, а?

Или, если брать за данность, что у Erlang'а скорость лежит в рантайме, то и у любого другого (ну или многих других) динамического языка такая же скорость достижима за счет рантайма? О чем здесь уже говорили на примере того, как Javascript рванул в скорости с улучшением рантайма. Но нет же — динамика сакс. и только Erlang — за счет рантайма

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

ВВ>Копируем в *.aspx файлик, файлик в виртуальную папочку. Все работает. Вроде лаконичность на уровне?

<%= => не обязательно, можно просто Hello, world!

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Ну вот мне интересно. Сейчас вот вполне серьезно обсуждается возможность сделать С# более "scripty"
AVK>Кем обсуждается?

У Липперта было. Что-то вроде этого: http://blogs.msdn.com/b/ericlippert/archive/2009/06/24/it-already-is-a-scripting-language.aspx

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

M>Может быть эта... Все же не будем применять двойные стандарты, а?

Двойных стандартов не увидел.

M>Или, если брать за данность, что у Erlang'а скорость лежит в рантайме, то и у любого другого (ну или многих других) динамического языка такая же скорость достижима за счет рантайма?

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

M> О чем здесь уже говорили на примере того, как Javascript рванул в скорости с улучшением рантайма.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Ну вот мне интересно. Сейчас вот вполне серьезно обсуждается возможность сделать С# более "scripty"
AVK>Кем обсуждается?

Вот более правильная ссылка: http://blogs.msdn.com/b/ericlippert/archive/2009/06/22/why-doesn-t-c-implement-top-level-methods.aspx

M>>Может быть эта... Все же не будем применять двойные стандарты, а?
AVK>Двойных стандартов не увидел.

Я их специально для тебя выписал. Можешь перечитать

M>>Или, если брать за данность, что у Erlang'а скорость лежит в рантайме, то и у любого другого (ну или многих других) динамического языка такая же скорость достижима за счет рантайма?

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

Опять начинаются сферовакуумные кони. Хотелось бы увидеть полноценный аналог этого «примитива» на сверхуспербыстром статическом немерле.

M>> О чем здесь уже говорили на примере того, как Javascript рванул в скорости с улучшением рантайма.

AVK>При этом рванул он там, где движку удалось интерпретировать код как статический. PyPy в ветке уже обсуждали, ситуация там точно такая же.

Видимо рантайм Erlanga способен на голимой динамике © поинтерпретировать все достаточно хорошо, несмотря на генетическую ущербность © этой самой динамики

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

M>А на немерле уже есть веб-сервер, который по производительности приближается или равен nginx'у? А то тут голимая динамика, которая всегда медленне статики (тм) ВНЕЗАПНО равна ему по производительности. Бида-бида. Как с таким парадоксом жить.
Немерле использован как пример того что статика может быть лаконичной и поддерживать метапрограммирование.
И честно говоря я думаю что любому инженеру очевидно что если это удалось реализовать для одного статически типизированного языка то это можно реализовать и для любого другого.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

FR>Я ту же эволюцию проделал, тем кто не прошел бесполезно объяснять, любимый парадокс Влада в действии.
Может тогда ты объяснишь в чем профит динамики?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

AVK>>Двойных стандартов не увидел.

M>Я их специально для тебя выписал. Можешь перечитать

Я их там не увидел, иначе бы не спрашивал.

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

M>Опять начинаются сферовакуумные кони.

Сфеовакуумный конь это приведенный тобой игрушечный тест.

M>Видимо рантайм Erlanga способен на голимой динамике © поинтерпретировать все достаточно хорошо, несмотря на генетическую ущербность © этой самой динамики

А на js, к примеру, можно вызвать DX фильтр или запустить ролик в html5. И работать будет не хуже плюсового аналога. ВОт только это ничего не говорит о скоости js.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

AVK>>>Двойных стандартов не увидел.
M>>Я их специально для тебя выписал. Можешь перечитать
AVK>Я их там не увидел, иначе бы не спрашивал.

Ну как же.

— Динамика — гуано. Тармазит!!!!!
— Ну, а как же, например Erlang?
— А там рантайм!!!
— Хм. У других тоже рантайм — и?
— Не, там все равно рантайм!!!!!

AVK>>>Проблема в том, что как только мы выходим за рамки тестового примитива и пишем более менее серьезный код при отработке запросов, преимущества быстрого рантайма потихоньку улетучиваются.
M>>Опять начинаются сферовакуумные кони.
AVK>Сфеовакуумный конь это приведенный тобой игрушечный тест.

Это лучше, чем вопли «динамика тормозит!!!!!!!одинодинодин» в отрыве от каких-либо задач.

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

M>>Видимо рантайм Erlanga способен на голимой динамике © поинтерпретировать все достаточно хорошо, несмотря на генетическую ущербность © этой самой динамики

AVK>А на js, к примеру, можно вызвать DX фильтр или запустить ролик в html5. И работать будет не хуже плюсового аналога. ВОт только это ничего не говорит о скоости js.

При чем тут вызов DX-фильтра? Правильно — не причем.

Дано: Erlang — динамически типизируемый язык (как и многие другие динамические языки). Компилируется в байткод, который потом выполняется рантаймом (как и в других динамическиъ языках).

Так нет же ж. Только показываешь пару графиков, которые идут вразрез с воплями «динамика тормозит!!!одинодинодин», как тут же начинается: ой, а там рантайм. Ну и других тоже рантайм и что?

Если мы используем один стандарт в подходе, то должны, как минимум признать, что динамические языки (да — засчет рантайма, я и не спорю) могут показывать хорошую (или даже отличную) производительность.

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

M>Ну как же.

M>— Динамика — гуано. Тармазит!!!!!
M>— Ну, а как же, например Erlang?
M>— А там рантайм!!!
M>— Хм. У других тоже рантайм — и?
M>— Не, там все равно рантайм!!!!!

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

AVK>>Сфеовакуумный конь это приведенный тобой игрушечный тест.

M>Это лучше, чем вопли «динамика тормозит!!!!!!!одинодинодин» в отрыве от каких-либо задач.

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

M>При чем тут вызов DX-фильтра?

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

M>Так нет же ж. Только показываешь пару графиков, которые идут вразрез с воплями «динамика тормозит!!!одинодинодин», как тут же начинается: ой, а там рантайм. Ну и других тоже рантайм и что?

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

M>Если мы используем один стандарт в подходе, то должны, как минимум признать, что динамические языки (да — засчет рантайма, я и не спорю) могут показывать хорошую (или даже отличную) производительность.

Языки — могут, динамика — нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

AVK>Получение html/sql/xml/etc путем конкатенации строки, это, хм..., не очень хорошая практика, скажем так. Соответственно пример на редкость негодный.
Да нет там никакой текстовой конкатенации.
Там хитрый код который на этапе компиляции смотрит какой тип у данных и соответствующим образом трансформирует их в XML.
Собственно XML оставляет без изменений все остальное конвертирует в строку и эскейпит.
Тк все делает робот нет никаких шансов ошибиться.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

AVK>Сфеовакуумный конь это приведенный тобой игрушечный тест.

Предложи другой тест, не "игрушечный".

AVK>>>Сфеовакуумный конь это приведенный тобой игрушечный тест.

M>>Это лучше, чем вопли «динамика тормозит!!!!!!!одинодинодин» в отрыве от каких-либо задач.

AVK>Воплей здесь не было. И таки да, динамика тормозит. Не ерланг, или питон там, а именно динамика. И если конкретный кусок кода на конкретном языке удается превратить в статический и рантайм это умеет, то потенциальных проблем на этом куске получить производительность компилятора нет. Только это уже не будет динамикой.

А это уже не суть важно.

M>>При чем тут вызов DX-фильтра?
AVK>При том, что ситуация та же — производительность определяется кодом, написанным совсем не на динамическом языке.
M>>Так нет же ж. Только показываешь пару графиков, которые идут вразрез с воплями «динамика тормозит!!!одинодинодин», как тут же начинается: ой, а там рантайм. Ну и других тоже рантайм и что?

AVK>Ты фантазируешь на ходу. Никто тут не вопит, кроме тебя, и не обвиняет твой любимый ерланг. Успокойся.

Я не воплю. Я гиперболизирую.

M>>Если мы используем один стандарт в подходе, то должны, как минимум признать, что динамические языки (да — засчет рантайма, я и не спорю) могут показывать хорошую (или даже отличную) производительность.

AVK>Языки — могут, динамика — нет.

С точки зрения пользователя (программиста) — фиолетово.

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

AVK>>Воплей здесь не было. И таки да, динамика тормозит. Не ерланг, или питон там, а именно динамика. И если конкретный кусок кода на конкретном языке удается превратить в статический и рантайм это умеет, то потенциальных проблем на этом куске получить производительность компилятора нет. Только это уже не будет динамикой.

M>А это уже не суть важно.

Именно это и важно.

AVK>>Языки — могут, динамика — нет.

M>С точки зрения пользователя (программиста) — фиолетово.

Не совсем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

AVK>>Получение html/sql/xml/etc путем конкатенации строки, это, хм..., не очень хорошая практика, скажем так. Соответственно пример на редкость негодный.
WH>Да нет там никакой текстовой конкатенации.
WH>Там хитрый код который на этапе компиляции смотрит какой тип у данных и соответствующим образом трансформирует их в XML.
WH>Собственно XML оставляет без изменений все остальное конвертирует в строку и эскейпит.

Учитывая, что на этапе компиляции неизвестно, что же у нас будет в базе данных во время работы программы, в чем профит? Оставить XML без изменений, а остальное конвертнуть в строку и ескейпнуть я и в динамике смогу.

WH>Тк все делает робот нет никаких шансов ошибиться.

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

Если я не ошибаюсь, «магическая» реализация заключается тут (привожу только кусок):

        case e of
            EApp (
            (EApp (
             (EApp (
              (EApp (
               (ECApp (
                (ECApp (
                 (ECApp (
                  (ECApp (
                   (ECApp (
                    (ECApp (
                     (ECApp (
                      (ECApp (
                       (EFfi ("Basis", "tag"),
                        loc), given), _), absent), _), outer), _), inner), _),
                   useOuter), _), useInner), _), bindOuter), _), bindInner), _),
               class), _),
              attrs), _),
             tag), _),
            xml) =>
            (case attrs of
                 (ERecord xets, _) =>
                 let
                     val (xets, s) =
                         ListUtil.foldlMap (fn ((x, e, t), s) =>
                                               let
                                                   fun tagIt' (ek, newAttr) =
                                                       let
                                                           val (e', s) = tagIt (e, ek, newAttr, s)
                                                           val t = (CFfi ("Basis", "string"), loc)
                                                       in
                                                           (((CName newAttr, loc), e', t), s)
                                                       end
                                               in
                                                   case x of
                                                       (CName "Link", _) => tagIt' (Link, "Link")
                                                     | (CName "Action", _) => tagIt' (Action ReadWrite, "Action")
                                                     | _ => ((x, e, t), s)
                                               end)
                                           s xets
                 in
                     (EApp (
                      (EApp (
                       (EApp (
                        (EApp (
                         (ECApp (
                          (ECApp (
                           (ECApp (
                            (ECApp (
                             (ECApp (
                              (ECApp (
                               (ECApp (
                                (ECApp (
                                 (EFfi ("Basis", "tag"),
                                  loc), given), loc), absent), loc), outer), loc), inner), loc),
                             useOuter), loc), useInner), loc), bindOuter), loc), bindInner), loc),
                         class), loc),
                        (ERecord xets, loc)), loc),
                       tag), loc),
                      xml), s)
                 end
               | _ => (e, s))

          | EFfiApp ("Basis", "url", [(ERel 0, _)]) => (e, s)

Ну, таким образом можно гарантировать валидность XML'я и в javascript'е с PHP

AVK>>>Воплей здесь не было. И таки да, динамика тормозит. Не ерланг, или питон там, а именно динамика. И если конкретный кусок кода на конкретном языке удается превратить в статический и рантайм это умеет, то потенциальных проблем на этом куске получить производительность компилятора нет. Только это уже не будет динамикой.

M>>А это уже не суть важно.

AVK>Именно это и важно.

Но пользоваться динамическими языками ты мне не запрещаешь, надеюсь?

AVK>>>Языки — могут, динамика — нет.

M>>С точки зрения пользователя (программиста) — фиолетово.

AVK>Не совсем.

Это наверное как-то связано со скоростью?

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

FR>>Я ту же эволюцию проделал, тем кто не прошел бесполезно объяснять, любимый парадокс Влада в действии.
WH>Может тогда ты объяснишь в чем профит динамики?

Нет, единственно могу посоветовать попробовать на ней немного пописать.

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

FR>>Я ту же эволюцию проделал, тем кто не прошел бесполезно объяснять, любимый парадокс Влада в действии.
WH>Может тогда ты объяснишь в чем профит динамики?

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

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

M>Но пользоваться динамическими языками ты мне не запрещаешь, надеюсь?

Ты опять воюешь с мельницами. Я тебе и не пытался запретить.

AVK>>>>Языки — могут, динамика — нет.

M>>>С точки зрения пользователя (программиста) — фиолетово.

AVK>>Не совсем.

M>Это наверное как-то связано со скоростью?

Это связано с тем, что обсуждают здесь не конкретные языки, а собственно динамику. Какой смысл в этом контексте рассматривать JIT или рантайм, если в обоих случаях никакой динамики нету? Не нравится тебе, когда не так говорят про ерланг (хотя ты сам его в топик засунул) — возьми б-гомерзкий C# 4. Суть от этого не изменится.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>Заметь, какая забавная ситуация получается. Вот к вам время от времени заглядывают люди с вопросами вроде "объясните, в чем профит Немерле". Казалось бы кто, как ни вы, должен этот самый "профит" разложить по полочкам. Однако что-то я не припомню, чтобы подобные темы часто заканчивались "обращением" в ваш стан. Как правило — превращаются просто во флейм, а то и в срач.
Те кто способен слушать "обращаются" в наш стан.
Но для того чтобы слушать должно быть что слушать. И оно у нас есть.

ВВ>Что мы наблюдаем и здесь, собственно.
Нет. Здесь мы наблюдаем полное отсутствие технических аргументов в пользу динамической типизации.
Есть только вопли о том что преимущества статики никому нахрен не нужны.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

FR>Нет, единственно могу посоветовать попробовать на ней немного пописать.
Я с нее начинал.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>>>А на немерле уже есть веб-сервер, который по производительности приближается или равен nginx'у?

AVK>>Вот только заслуга в этом не динамики, а хорошо реализованного рантайма. Написанного, замечу, совсем не на динамическом языке.

M>Я так и знал, что этот аргумент возникнет

M>У РНР рантайм написан на С, но РНР, как известно, достаточно медленный язык. Гуано
M>У Ruby рантайм написан на С (емнип), но Ruby, как известно, достаточно медленный язык. Гуано
M>У Python'а рантайм написан на С (емнип), но Python для местных гуру достаточно медленный язык. Гуано
M>У JavaScript'а рантайм написан на С/C++, но Javascript для местных гуру достаточно медленный язык. Гуано
M>У _любимы_скриптовый_язык_ рантайм написан на скорее_всего_с_или_другой_язык_со_статической_типизацией, но динамика по определению тормозит, ага. Гуано.

M>И только у Erlang'а рантайм написан на С (статически типизированый язык), поэтому его скорость — это заслуга рантайма.

Ну, чисто статистически, когда-нибудь, у кого-то, должен же был получиться хороший рантайм на С?

P.S: Афигеть, что противостояние систем типизации делает. Сторонник C# защищает Nemerle от нападок сторонника Python, размахивающего здесь Erlang'ом

Мне даже попкорн в рот не лезет

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

KV>P.S: Афигеть, что противостояние систем типизации делает. Сторонник C# защищает Nemerle от нападок сторонника Python, размахивающего здесь Erlang'ом

Мне даже попкорн в рот не лезет

Блин вот мне придется наверно разорваться я тут пишу на питон + ocaml.

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

FR>>Нет, единственно могу посоветовать попробовать на ней немного пописать.
WH>Я с нее начинал.

VB?

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

KV>Ну, чисто статистически, когда-нибудь, у кого-то, должен же был получиться хороший рантайм на С?

Ну тут эрланг не один такой, лиспы, J и все APL'образная компания, OCaml ( интерпретатор

) lua, ему и фору могут кое-где дать.

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

AVK>Это связано с тем, что обсуждают здесь не конкретные языки, а собственно динамику. Какой смысл в этом контексте рассматривать JIT или рантайм, если в обоих случаях никакой динамики нету? Не нравится тебе, когда не так говорят про ерланг (хотя ты сам его в топик засунул) — возьми б-гомерзкий C# 4. Суть от этого не изменится.

Можно взять интерпретируемые статические языки (OCaml байткод, раннюю яву, да и даже у моно если не путаю есть режим интерпретации)
и посмотреть виновата ли только динамика.

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

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

KV>>P.S: Афигеть, что противостояние систем типизации делает. Сторонник C# защищает Nemerle от нападок сторонника Python, размахивающего здесь Erlang'ом

Мне даже попкорн в рот не лезет

FR>Блин вот мне придется наверно разорваться я тут пишу на питон + ocaml.

А я — на python + nemerle

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

AVK>>>Вот только заслуга в этом не динамики, а хорошо реализованного рантайма. Написанного, замечу, совсем не на динамическом языке.

M>>Я так и знал, что этот аргумент возникнет

M>>У РНР рантайм написан на С, но РНР, как известно, достаточно медленный язык. Гуано
M>>У Ruby рантайм написан на С (емнип), но Ruby, как известно, достаточно медленный язык. Гуано
M>>У Python'а рантайм написан на С (емнип), но Python для местных гуру достаточно медленный язык. Гуано
M>>У JavaScript'а рантайм написан на С/C++, но Javascript для местных гуру достаточно медленный язык. Гуано
M>>У _любимы_скриптовый_язык_ рантайм написан на скорее_всего_с_или_другой_язык_со_статической_типизацией, но динамика по определению тормозит, ага. Гуано.

M>>И только у Erlang'а рантайм написан на С (статически типизированый язык), поэтому его скорость — это заслуга рантайма.

KV>Ну, чисто статистически, когда-нибудь, у кого-то, должен же был получиться хороший рантайм на С?

А то

KV>P.S: Афигеть, что противостояние систем типизации делает. Сторонник C# защищает Nemerle от нападок сторонника Python, размахивающего здесь Erlang'ом

Мне даже попкорн в рот не лезет

Да ладно

Я сам последнее время 50/50 на обоих системах пишу. Тяжела и неказиста жизнь простого программиста

M>>>>С точки зрения пользователя (программиста) — фиолетово.
AVK>>>Не совсем.
M>>Это наверное как-то связано со скоростью?

AVK>Это связано с тем, что обсуждают здесь не конкретные языки, а собственно динамику. Какой смысл в этом контексте рассматривать JIT или рантайм, если в обоих случаях никакой динамики нету?

AVK>Не нравится тебе, когда не так говорят про ерланг (хотя ты сам его в топик засунул)

Мне не нравится, когда размахивают лозунгами «тормозит», «скорость не та» абсолютно без привязки к чему-либо. Так, сферовакуумные тормоза сферовакуумной скорости.

Когда показываешь, что нет, не тормозит, начинаются рассуждения о рантайме

Понятно, конечно, что компилятор/интерпретатор будет стараться выводить типы — это никто и не оспаривал

Но ВНЕЗАПНО оказалось, что вывод этих типов и всякий там JIT доступен не только для статически-типизированых языков

И что скорость у них может быть не ниже

Как там Wolfhound сказал, «статическая типизация — оптимизация и для человека и для компилятора». ВНЕЗАПНО оказалось, что не всегда это нужно, так как компилятор (как случае с Erlang'ом) и сам справится

Про оптимизацию для человека тоже можно поспорить(ПМ рулит, ага

).

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

M>Понятно, конечно, что компилятор/интерпретатор будет стараться выводить типы — это никто и не оспаривал

Но ВНЕЗАПНО оказалось, что вывод этих типов и всякий там JIT доступен не только для статически-типизированых языков

\

Опять языков? Извини, но ты зря обвиняешь других в размахивании флагом — ты сам это делаешь здесь куда больше остальных.

M> И что скорость у них может быть не ниже

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

M>Как там Wolfhound сказал, «статическая типизация — оптимизация и для человека и для компилятора».

Обрати внимание — типизация. Еще раз — не язык, а типизация.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Что мы наблюдаем и здесь, собственно.
WH>Нет. Здесь мы наблюдаем полное отсутствие технических аргументов в пользу динамической типизации.
WH>Есть только вопли о том что преимущества статики никому нахрен не нужны.

О! Гениальная иллюстрация того тезиса, что если держать в руках молоток, то всё вокруг кажется гвоздями.
Сначала мы тихой сапой вводим тезис, что аргументы должны быть технические (что бы это ни значило). Затем из всех технических аргументов выбираем сферовакуумную ((с) Mamut) скорость и удобство управления наиболее простыми и декларируемыми в коде свойствами. И вуаля — с помощью такого двойного тулупа создан чёткий образ.

WH>Те кто способен слушать "обращаются" в наш стан.

Я так и знал, что это религия.

WH>Но для того чтобы слушать должно быть что слушать. И оно у нас есть.

У последователей Распятого оно тоже есть, и что немаловажно — у обратившихся даже в основном работает.

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

WH>>Те кто способен слушать "обращаются" в наш стан.
N>Я так и знал, что это религия.
Ну да конечно. Цепляемся к слову которое еще и не я сказал и переводим все в тупой флуд.
Что по существу совсем нечего сказать?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

WH>>>Те кто способен слушать "обращаются" в наш стан.
N>>Я так и знал, что это религия.
WH>Ну да конечно. Цепляемся к слову которое еще и не я сказал и переводим все в тупой флуд.

Уж кто бы говорил про тупой флуд...

WH>Что по существу совсем нечего сказать?

По существу я достаточно сказал рядом.

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

N>По существу я достаточно сказал рядом.
Что-то не заметно. И вот это сообщение какбы не заметил. А там у меня к тебе куча вопросов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>>Да в общем-то давно можно.

WH>жуть

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

N>>Главное здесь — слово public. Если protected, посторонний процесс сможет только читать, а private — не сможет даже читать.
N>>Некоторые приложения, как стандартный application, принципиально опираются на этот механизм.
WH>Но тут по крайне мере можно эту таблице залочить.
WH>В go же данные никак и ничем не контролируются.
WH>Те несколько потоков могут корежить один и тотже объект без какой либо синхронизации.
WH>А это уже ужос ужос.

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

Это уж я не вспоминаю, какие варианты подхода нужно где-то применять — где-то нужен мьютекс вокруг доступа (как ты намекаешь), а где-то нужен вместо этого read-copy-update, а мьютекс будет просто запрещён. Затем затачивать себя на один, заведомо ограниченный, подход? Ладно Erlang, там общих данных практически нет, но это и сильное ограничение его возможностей. А на Go зачем?

N>>Верно. Потому что ты смешал совершенно разные классы ограничений, пришлось вмешаться.
WH>Я всетки не вижу разници.
WH>У нас есть задача.
WH>У нас есть решатель.
WH>Решение будет ограничено ограничениями и задачи и решателя.
WH>И так как решатель у нас один и других не предвидится и не вижу смысла разделять эти понятия.

Если у тебя "решатель" ограничен требованием писать только на Nemerle и только одним образом — да, верю. Но как правильно такие ограничения не возникают естественным образом: это уже чьи-то тараканы. В более распространённом случае и базовые средства к задаче могут быть разнообразными, и метод решения внутри выбирается по задаче с учётом всех соображений, от технических до социальных и маркетинговых (это я уже отвечаю на твоё соседнее письмо).

N>>>>Я не смог понять этот абзац — даже после исправления описок он не приобретает смысла. Объясни другими словами, plz.
WH>>>Да все просто. Нет теста. И еще не скоро будет. Но я и так знаю что все впорядке.
N>>Святым духом знаешь? Мне бы такую уверенность...
WH>Существующая функциональность не сломалась. На это тест есть.

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

N>>Смысл ровно тот же, с которым ты вообще сюда что-то пишешь: хочешь высказать свою точку зрения, кого-то убедить, от кого-то получить полезные комментарии. Но если ты будешь приводить примеры школьного уровня, это ни для кого не будет убедительным, скорее наоборот.
WH>Почему ты считаешь этот пример школьным?
WH>Реальный комит. В реальном проекте. Причем я бы сказал весьма не простом проекте.

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

N>>Ну покажи более интересный пример. Сейчас в твоих примерах и высказываниях просто не за что зацепиться — всё предельно плоское, школьное и суконное.
WH>Вышел я из возроста когда мне было в кайф наворотить веселые мегашаблоны на С++.
WH>Теперь у меня весь код скучный. Даже тот который решает очень сложные задачи.

N>>А он тут и не сильно важен (хотя может быть освоен за 5 минут). Если ты просто нарисуешь по квадратику для каждой названной сущности и протянешь стрелки связей — уже увидишь сложность ситуации.
WH>Не увижу.
WH>У меня мозг работает по другому.

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

N>>Нет, не знаю. Видимо, потому, что ситуация таки сложнее, чем это кажется со стороны.
WH>Но ты же его написал.
WH>Вводим FSM на уровень системы типов. И все.

Значит, я не смог объяснить реальные проблемы. Забей.

N>>Она значительно менее ущербна, чем твоя позиция "что бы ты не делал — если делаешь на динамике, делаешь это неправильно".
WH>Я тут уже который раз задаю вопрос: Где профит?
WH>И ответа по существу нет.
WH>Ни одного.
WH>Повторю еще раз свои аргументы против динамики:
WH>1)Скорость исполнения всегда ниже.
WH>2)Компилятор не ловит ошибки. Совсем.
WH>3)IDE фундаментально убогие.
WH>А что у нас в плюсе?
WH>Меньше кода?
WH>По сравнению с С++, C# и Java? Да!
WH>По сравнению с немерле? Нет!
WH>Метапрограммирование? Так в немерле оно есть.
WH>В чем профит?
WH>Ну хоть что-то?
WH>А если есть очевидные недостатки но не видно достоинств то зачем оно нужно?
WH>Ответь хотябы ты.
WH>На Мамута я уже не расчитываю.

Мамут вообще-то говорит достаточно правильные вещи, и то, что ты его аргументы просто не слышишь или не применяешь логику как следует, говорит о достаточно многом. Но таки попробую ответить чисто от себя.

Во-первых, о существующих средствах и текущих задачах (раз уж пытаемся на своём опыте что-то предполагать — углубим это). На самом деле я в существенной мере мечтаю о том, чтобы перевести существующие проект свича (про него я тут уже рассказывал) как минимум с Питона на что-то более адекватное. Когда этот проект начинался (2003-2004), ничего подходящего в принципе не было — если не вспоминать кошмарный Perl, тормозной Ruby, нишевой Lua и тому подобное. Альтернативная реализация была на C++ (т.наз. Vovida B2BUA) и она была кошмарной по множеству причин. Юзера были готовы нас съесть, и скорость прототипирования была в разы важнее остального, в том числе и скорости выполнения. В частности, некоторые места, где была чуть ли не кубическая зависимость от нагрузочных факторов, мы срезали только через пару лет. Теперь представь себе, что мы не в 2003, а в 2010, и я выбираю основу для реализации такого же проекта. Что ты мне можешь предложить? Nemerle не считается — ни Windows ни Mono не годятся по целому набору параметров. Я готов заранее поверить во все его положительные здесь свойства, но пока нет пригодной обстановки — это не более чем рассказ про инопланетян. Итак, извечный русский вопрос — "куда пойти, куда податься, кого найти, кому отдаться?" Мне нужно средство, которое:
* в основе императивное, или если функционально-декларативное, то самое распространённое и понятное из. потому что мне надо учить людей не языку, а предметной области — она слишком сложна, чтобы войти с ходу.
* хорошо параллелится, без GIL и тому подобных ограничений
* работает на Unix системах, причём максимально родным методом (без ретрансляции подложки, которая не даёт прямого доступа к принципиальным аспектам функционирования)
* вышло из стадии альф и бет, имеет как минимум один релиз с известными граблями
* допускает хотя бы на уровне отдельных совместимых блоков замену кода на ходу (причём не "выгрузкой домена приложения", а она должна быть полностью прозрачна для работающего кода (например, звонок не должен рваться)

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

Во-вторых, о специфике предметной области. Как я уже упоминал, работаем с SIP. Про него могу сказать, что я давно не видел где-то ещё такого ходячего кошмара. Все телефонистские средства ужасны, и все решения от крупных комитетов ужасны, но в VoIP эти два ужаса смешиваются. H.323 ужасен по-своему, SIP — по-своему, другие сигнализации — по-своему, но ужас ходит везде.; ( Для SIP это приводит к тому, что любая возня большая, чем определить направление форварда и закинуть туда, становится безумно дорогой, и это практически не зависит от применяемых средств программирования. Сравни, например, скорость SER и resiprocate на примерно одинаковых задачах: первый (неважно, какой из его нынешних клонов) превращён в жуткую молотилку за счёт оптимизаций вплоть до ассемблерных, но логика посложнее простой пересылки на нём превращается в ужас ночи. Вторая может всё, но скорость, как оказалось, не лучше моей жуткопитоновой B2BUA, хотя там в resiprocate в полный рост допустима параллелизация и другие плюшки.

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

Да, вас интересно послушать, полюбоваться на примеры. Но: "вы нам новый соус измышляете, а мы жрать,
жрать хотим!" ((c) Гранин). (Почитай эпизод в котельной в "Искателях", как раз хорошо показывает отношение к подобным измышлениям в башне из слоновой кости.) Ты можешь привести столь же эффективные примеры, как ты приводишь для Nemerle, для какого-то действительно практически распространённого языка и среды, удовлетворяющих описанным выше условиям? Если нет — все аргументы про то, что в статике контроль типов, мне нафиг не сдались без полного комплекса условий, в которых этот контроль мне даёт реальные результаты и сокращает затраты.

Но даже предположим, что такое средство нашлось. Теперь вопрос: достаточно ли существенны его преимущества, чтобы на него переходить? Получу ли я прирост производительности в 2, в 4 раза? Тут постоянно упоминаются цифры типа 10-30 раз. Я не могу получить те же цифры на своих задачах: настолько специфична проблемная область. Реально — может, 2 раза; более существенные цифры невероятны. В моих условиях этот переход себя не окупит. Я лучше потрачу значительно меньшие средства на распараллеливание работы, тем более что оно всё равно нужно (специфику некоторых пользователей ни один современный сервер не выдерживает), а софтовые затраты всё равно выше железных.

Вот и получается у нас разговор вида:
— Переходи на статику, она лучше.
— Чем лучше?
— Быстрее, надёжнее, умнее (сама себя проверяет).
— Быстрее — несущественно и сомнительно, надёжнее — в крайних случаях, умнее — мы всё равно должны проверять функционирование в целом, а не по отдельным кускам.
— Ты ничего не понимаешь.

Блин, да кто может понимать потребности, как не тот, кто собственно работает в целевой области? Со стороны никаким прожектором это всё не высветить.

Я с удовольствием читаю современные теоретизирования. Например, об автоматическом выводе типов в функциональных языках. О том, сколько можно вложить в тот же тип. О средствах описания кода так, чтобы это включало в себя возможность автоматической верификации компилятором. И тэ дэ и тэ пэ. А потом возвращаюсь в реальный мир, где каждые пять минут ~~молоко убегает~~ узел выпадает по MCE или происходит ещё какая-то Н.Е.Х. (сиречь Неведомая Шлёпаная Фигня), при которой надо продолжать работать...

WH>>>Если ты о том что нужно в протокол добавить поддержку расширения это ни разу не проблема.
N>>Ну расскажи, как ты это будешь делать.
WH>Ты действительно хочешь чтобы я тебе тут чиста ради флема спроектировал расширяемый протокол?
WH>Причем под что-то сферовакуумное?
WH>Это слишком большой объем работы.

Её не надо делать: в описанном примере за тебя её давно сделал Большой Комитет с большими отдавленными "Мадам Сижу", сиречь двуедиными сущностями с вертикальной улыбкой. Вопрос в том, как ты у себя будешь поддерживать данные этого протокола, насколько легко тебе протащить какие-то добавки через десяток уровней.

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

N>>>>подумай о некоторых других вопросах: например, ограничениях на вложение тегов по их типам,
WH>>>И в чем проблема?
N>>Ну и как ты это будешь решать?
WH>Что решать?
WH>Пример проблемы пожилуста.

Я заминаю эту тему, потому что мне облом объяснять тривиальные вещи. Видно, у тебя настолько другая проблемная область, что придётся начать ликбез с нуля, а мне этого не хочется.

WH>>>А что касается перегрузки операторов то мне и этого мало.
WH>>>Я сейчас работаю над парсером для немерле2 там можно будет вообще как угодно над синтаксисом издеваться.
WH>>>Что позволит сделать произвольный ДСЛ.
N>>Y A C C по новой, да?
WH>А что уже позволяет сделать так:
WH>

WH>SomeFunction() : ...
WH>{
WH>    using XMLDsl;//Тут мы расширяем грамматику XML литералами
WH>    def xml = <asd>$someVar</asd>;
WH>}//А тут эта грамматика отключается
WH>

Если эта твоя грамматика автоматически отключилась увидев символ '}', то "как угодно" над синтаксисом ты уже не можешь издеваться. Только в резко ограниченных пределах. Опознание применения грамматики у тебя оказывается тоже ограниченным — потому что def отнёсся к основной грамматике.

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

WH>Причем вместе с ДСЛ подключаются автокомплит, подсветка и навигация по коду.
WH>Так что як нервно курит в углу.

Увы, не курит. Но мне искренне приятно видеть такой энтузиазм. Я как-то в последнее время стал предельно циничен по отношению к доступным средствам, это меня самого удивляет.

N>>Мне в общем-то пофиг, как ты назовёшь аналог getopt в твоей среде. Вопрос в том, как ты будешь потом эти данные использовать. Глобальные данные класса — это хак ровно того же уровня, что и просто глобальные переменные.
WH>Ты имеешь в виду статические переменные класса?
WH>Если да то полностью согласен.
WH>Я уже давно пришол к выводу что их нужно запретить.
WH>Пользы нет, а вред существенный.

А как ты создашь доступный со всех точек кода единственный экземпляр объекта?
Будешь наворачивать синглтоны имени Александреску? Тогда не вижу разницы со статическими переменными класса.
Передавать такие глобальные знания всюду в функции? Дорого и неэкономично. Как я показывал, даже Erlang на такое не идёт — у него есть, например, регистрация процессов по имени и работа с фиксированными именами (init, application_controller и тому подобными).

WH>Кстати с запретом глобальных переменных нужно запрещать всякие CreateFile ибо они по сути маскируют глобальные переменные.
WH>Проблемы из-за них вполне конкретные.
WH>Например я не могу взять и запустить какой попало код. Ибо злобный хацкер сможет сотворить что попало.
WH>Чтобы с этим бороться мелкософт наворотил мега костыль по имени code access security который больше мешает чем помогает.

А какая альтернатива? Канализировать все внешние операции через твои заранее заданные средства? Уверен ли ты, что сможешь предоставить всё, что нужно произвольному средству?

WH>А всего то надо было при старте программы передавать в процесс сервис имен через который можно все что можно процессу.
WH>В таком случае можно будет выполнить что попало. Все что нужно сделать для того чтобы это что попало не сделало гадость это не давать ему сервис имен.
WH>Получаем http://en.wikipedia.org/wiki/Capability-based_security

Любая секьюрити есть неудобство. В данном случае — для программиста, который рисует среду исполнения и её ограничения. Любой неадекват в любую сторону что-то испортит.

Эта проблема глобальна и будет решаться столетиями, и нельзя про неё говорить "а всего-то"...

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

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

N>>По существу я достаточно сказал рядом.
WH>Что-то не заметно. И вот это сообщение какбы не заметил.

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

WH> А там у меня к тебе куча вопросов.

Уже ответил.

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

N>>"Последняя страница книги оказалась написана по-китайски" (tm). Что такое домен приложения? Догадка навскидку — это весь код в пределах какой-то логической группировки ("приложение"). Так?

AS>Нет.

Узнаю брата ~~Колю~~ программиста.

M>>Понятно, конечно, что компилятор/интерпретатор будет стараться выводить типы — это никто и не оспаривал

Но ВНЕЗАПНО оказалось, что вывод этих типов и всякий там JIT доступен не только для статически-типизированых языков

\

AVK>Опять языков? Извини, но ты зря обвиняешь других в размахивании флагом — ты сам это делаешь здесь куда больше остальных.

M>> И что скорость у них может быть не ниже

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

M>>Как там Wolfhound сказал, «статическая типизация — оптимизация и для человека и для компилятора».

AVK>Обрати внимание — типизация. Еще раз — не язык, а типизация.

Так как я косноязычен, перенаправлю на netch80: http://rsdn.ru/forum/philosophy/4006147.aspx

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

N>Это уж я не вспоминаю, какие варианты подхода нужно где-то применять — где-то нужен мьютекс вокруг доступа (как ты намекаешь), а где-то нужен вместо этого read-copy-update, а мьютекс будет просто запрещён. Затем затачивать себя на один, заведомо ограниченный, подход? Ладно Erlang, там общих данных практически нет, но это и сильное ограничение его возможностей. А на Go зачем?
Вот и пусть тогда авторы не говорят что Go безопасный. Ибо это не так.

N>Если у тебя "решатель" ограничен требованием писать только на Nemerle и только одним образом — да, верю.
Это уже ты придумал и споришь со своим воображением.

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

N>О, то есть таки финальный ответ ты делаешь именно по тесту? Если у тебя есть тест и ты его применяешь, значит, у тебя нет тотальной уверенности в контроле компилятором...
У меня есть общий функциональный тест.
Об этом я сказал еще много сообщений назад.
Но мои сообщения тут как я погляжу читать не принято.

N>Проект — да, непростой. Но конкретный пример — школьного уровня, увы. Такие изменения можно делать, не зная, что делает код в целом, и поручать студентам.
Мда... отрицание фактов это конечно сильный ход.
Эволюция твоих отрицаний:
1)Статика ничего не дает.
2)Я не понимаю ваш немерле.
3)Пример школьный.

И это вместо того чтобы признать простой факт: Статическая типизация помогает рефакторить.

N>Мамут вообще-то говорит достаточно правильные вещи, и то, что ты его аргументы просто не слышишь или не применяешь логику как следует, говорит о достаточно многом. Но таки попробую ответить чисто от себя.
У него аргумент ровно один: Лично ему. На лично его задачах. Не нужен быстрый язык.

Только это никак не отменяет тот факт что статика при одинаковых алгоритмах как минимум не медленней.

N>Nemerle не считается — ни Windows ни Mono не годятся по целому набору параметров.
Это объективное возражение против конкретной реализации конкретного статически типизированного языка.
Но не против статической типизации в целом.

N>* в основе императивное, или если функционально-декларативное, то самое распространённое и понятное из. потому что мне надо учить людей не языку, а предметной области — она слишком сложна, чтобы войти с ходу.
Сложность изучения нового языка профессионалом сильно преувеличина.
Вот например: http://www.rsdn.ru/forum/decl/3955117.1.aspx

N>* хорошо параллелится, без GIL и тому подобных ограничений
Этим славятся какраз всякие питоны.

N>* работает на Unix системах, причём максимально родным методом (без ретрансляции подложки, которая не даёт прямого доступа к принципиальным аспектам функционирования)
Тут нужно расшифровать.

N>* вышло из стадии альф и бет, имеет как минимум один релиз с известными граблями
Вот этого я вообще не понимаю.
Ярлыки ничего не значат.
На любой продукт. В любой момент. Можно повесить любой ярлык.
Вот только о реальном качестве это ничего не скажет.

N>* допускает хотя бы на уровне отдельных совместимых блоков замену кода на ходу (причём не "выгрузкой домена приложения", а она должна быть полностью прозрачна для работающего кода (например, звонок не должен рваться)
Для этого нужно только уметь загружать код в рантайме.
Для того чтобы старый код не копился в памяти нужна сборка мусора для кода. Хотя если у тебя 64х битный процесс томожно и без этого. Не нужный код просто осядет в свопе. А свопа много.
Ну и полный шик это возможность помечать некоторые функции заменяемыми. Но это не избежно приведет к тому что эти функци будет нельзя инлайнить и их вызов будет на один jump медленней.
Ничему этому статическая типизация не мешает.

N>Во-вторых, о специфике предметной области.
Я не могу это комментировать ибо я полный 0 в твоей предметной области.
Я тупо половину слов не понимаю.

N>И вот уже имея подобные результаты на руках — я смотрю на этот спор и вижу, что с одной стороны в нём преобладает (в лице тебя и VladD2) сторона, все результаты которого основаны на одном средстве, которое:
Ты похоже уже забыл что разговор идет не о немерле, а о профите динамики.
Про который ты опять ничего не сказал.

Так что заключаем что профита динамики нет?

N>Например, у меня данные ловит агрегатор, передаются они на шину, их перерабатывает и красит модуль логики узла, затем с ними работает модуль групповой логики, они попадают на ещё одну шину, там из них делают тревожное событие и его обрабатывают. Мне нужно провести по этой цепочке некоторые данные прозрачно от и до. Я не прошу тебя разбираться, "кто все эти люди", я прошу оценить, насколько будет сложным расширение всего этого по цепочке от и до. Для полноты картины сообщаю, что дело идёт на живых системах, которые можно апгрейдить только на ходу и по частям.
Повторяю еще раз.
Для проектирования решения внутри твоей предметной области у меня не хватает данных.
Загружать свою голову этими данными я не намерен ибо для меня они бесполезны.

N>Если эта твоя грамматика автоматически отключилась увидев символ '}', то "как угодно" над синтаксисом ты уже не можешь издеваться. Только в резко ограниченных пределах.
Нет. Грамматика отключилась дойдя до конца блока в котором ее подключили.

N>Опознание применения грамматики у тебя оказывается тоже ограниченным — потому что def отнёсся к основной грамматике.
В том то и кайф. Мы прямо внутри основного языка переключаемся на совершенно другой язык.
Компилятор видя что в коде пошла какаято байда переключается на грамматику для этой байды.
Распарсив байду он успокаивается и возвращается к исходной грамматике.
При этом байда может иметь полностью другую грамматику.

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

N>Увы, не курит. Но мне искренне приятно видеть такой энтузиазм. Я как-то в последнее время стал предельно циничен по отношению к доступным средствам, это меня самого удивляет.
Не разобрался но осуждаю.
Классная логика.

N>А как ты создашь доступный со всех точек кода единственный экземпляр объекта?
Зачем?
Это не нужно.

N>Передавать такие глобальные знания всюду в функции?
Именно так.

N>Дорого и неэкономично.

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

N>Как я показывал, даже Erlang на такое не идёт — у него есть, например, регистрация процессов по имени и работа с фиксированными именами (init, application_controller и тому подобными).
Демагогия: Аппеляция к авторитету.

N>А какая альтернатива? Канализировать все внешние операции через твои заранее заданные средства? Уверен ли ты, что сможешь предоставить всё, что нужно произвольному средству?
Конечно.
Более того это уже сделано например в снгулярити.
Кстати говоря это единственно место где нужно приведение типов в рантайме.
Ибо по другому просто не сделать.

N>Любая секьюрити есть неудобство.
Единственно не удобство это то что в функции открытия файла появится один обязательный параметер.

N>В данном случае — для программиста, который рисует среду исполнения и её ограничения.
Для разработчика среды исполнения эта модель проще в реализации чем колдунство с функциями аля CreateFile.
При наличии строгой типизации разумеется. Без нее эта модель просто работать не будет.

N>Любой неадекват в любую сторону что-то испортит.
Где не адекват и что испорчено?

N>Эта проблема глобальна и будет решаться столетиями, и нельзя про неё говорить "а всего-то"...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>>Это уж я не вспоминаю, какие варианты подхода нужно где-то применять — где-то нужен мьютекс вокруг доступа (как ты намекаешь), а где-то нужен вместо этого read-copy-update, а мьютекс будет просто запрещён. Затем затачивать себя на один, заведомо ограниченный, подход? Ладно Erlang, там общих данных практически нет, но это и сильное ограничение его возможностей. А на Go зачем?
WH>Вот и пусть тогда авторы не говорят что Go безопасный. Ибо это не так.

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

N>>Если у тебя "решатель" ограничен требованием писать только на Nemerle и только одним образом — да, верю.
WH>Это уже ты придумал и споришь со своим воображением.

А я просил привести другой пример пригодного и распространённого средства. Но ты этот вопрос пропускаешь.

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

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

N>>О, то есть таки финальный ответ ты делаешь именно по тесту? Если у тебя есть тест и ты его применяешь, значит, у тебя нет тотальной уверенности в контроле компилятором...
WH>У меня есть общий функциональный тест.
WH>Об этом я сказал еще много сообщений назад.
WH>Но мои сообщения тут как я погляжу читать не принято.

После той мути, которую ты развёл? Да, их читать сложно

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

N>>Проект — да, непростой. Но конкретный пример — школьного уровня, увы. Такие изменения можно делать, не зная, что делает код в целом, и поручать студентам.
WH>Мда... отрицание фактов это конечно сильный ход.
WH>Эволюция твоих отрицаний:
WH>1)Статика ничего не дает.
WH>2)Я не понимаю ваш немерле.
WH>3)Пример школьный.

WH>И это вместо того чтобы признать простой факт: Статическая типизация помогает рефакторить.

Я признаю этот факт и признавал его с самого начала. Ты не сможешь найти его отрицание у меня. Но ты из этого факта делаешь сразу вывод, что отсутствие такой типизации превращает ситуацию в неуправляемую — отсюда твои странные реплики про "если вы такие умные, почему до сих пор не захватили мир?" Фактически, ты боишься сойти со своего крошечного, защищённого статической типизацией островка — как же, смоют бурные волны

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

N>>Мамут вообще-то говорит достаточно правильные вещи, и то, что ты его аргументы просто не слышишь или не применяешь логику как следует, говорит о достаточно многом. Но таки попробую ответить чисто от себя.
WH>У него аргумент ровно один: Лично ему. На лично его задачах. Не нужен быстрый язык.

Нет, не только этот. Например, он тебе приводил оценки скорости работы эрланга, с которыми ты ничего не смог сделать.

WH>Только это никак не отменяет тот факт что статика при одинаковых алгоритмах как минимум не медленней.

Только это никак не придаёт данному факту смысл больше, чем его голое значение.

N>>Nemerle не считается — ни Windows ни Mono не годятся по целому набору параметров.
WH>Это объективное возражение против конкретной реализации конкретного статически типизированного языка.
WH>Но не против статической типизации в целом.

Безусловно. Я и не выдвигал его на всеобщее возражение.

N>>* в основе императивное, или если функционально-декларативное, то самое распространённое и понятное из. потому что мне надо учить людей не языку, а предметной области — она слишком сложна, чтобы войти с ходу.
WH>Сложность изучения нового языка профессионалом сильно преувеличина.
WH>Вот например: http://www.rsdn.ru/forum/decl/3955117.1.aspx

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

Кстати, употребление термина "профессионал" здесь немного сомнительно, если вспомнить, например, тезисы Выдрова. Но это оффтопик.

N>>* хорошо параллелится, без GIL и тому подобных ограничений
WH>Этим славятся какраз всякие питоны.

Чем именно славятся — ограничениями или их отсутствием?

N>>* работает на Unix системах, причём максимально родным методом (без ретрансляции подложки, которая не даёт прямого доступа к принципиальным аспектам функционирования)
WH>Тут нужно расшифровать.

Я рядом ругался на Mono, почитай.

N>>* вышло из стадии альф и бет, имеет как минимум один релиз с известными граблями
WH>Вот этого я вообще не понимаю.
WH>Ярлыки ничего не значат.
WH>На любой продукт. В любой момент. Можно повесить любой ярлык.
WH>Вот только о реальном качестве это ничего не скажет.

Обычно эти ярлыки таки соответствуют содержанию.

N>>* допускает хотя бы на уровне отдельных совместимых блоков замену кода на ходу (причём не "выгрузкой домена приложения", а она должна быть полностью прозрачна для работающего кода (например, звонок не должен рваться)
WH>Для этого нужно только уметь загружать код в рантайме.
WH>Для того чтобы старый код не копился в памяти нужна сборка мусора для кода. Хотя если у тебя 64х битный процесс томожно и без этого. Не нужный код просто сядет в свопе. А свопа много.

Ну и? Это такая фатальная проблема — сборка мусора для кода?

WH>Ну и полный шик это возможность помечать некоторые функции заменяемыми. Но это не избежно приведет к тому что эти функци будет нельзя инлайнить и их вызов будет на один jump медленней.
WH>Ничему этому статическая типизация не мешает.

Мало ли что не мешает. У нас уже контекст — не потенциальная возможность, а реальные образцы. К сожалению, доступный набор ограничен эрлангом и питоном, у остальных механизм непригоден.

N>>Во-вторых, о специфике предметной области.
WH>Я не могу это комментировать ибо я полный 0 в твоей предметной области.
WH>Я тупо половину слов не понимаю.

Ну ты понял, что сообщение проходит через полдесятка разных сущностей?

Или даже это проблема,

N>>И вот уже имея подобные результаты на руках — я смотрю на этот спор и вижу, что с одной стороны в нём преобладает (в лице тебя и VladD2) сторона, все результаты которого основаны на одном средстве, которое:
WH>Ты похоже уже забыл что разговор идет не о немерле, а о профите динамики.
WH>Про который ты опять ничего не сказал.
WH>Так что заключаем что профита динамики нет?

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

N>>Например, у меня данные ловит агрегатор, передаются они на шину, их перерабатывает и красит модуль логики узла, затем с ними работает модуль групповой логики, они попадают на ещё одну шину, там из них делают тревожное событие и его обрабатывают. Мне нужно провести по этой цепочке некоторые данные прозрачно от и до. Я не прошу тебя разбираться, "кто все эти люди", я прошу оценить, насколько будет сложным расширение всего этого по цепочке от и до. Для полноты картины сообщаю, что дело идёт на живых системах, которые можно апгрейдить только на ходу и по частям.
WH>Повторяю еще раз.
WH>Для проектирования решения внутри твоей предметной области у меня не хватает данных.
WH>Загружать свою голову этими данными я не намерен ибо для меня они бесполезны.

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

N>>Если эта твоя грамматика автоматически отключилась увидев символ '}', то "как угодно" над синтаксисом ты уже не можешь издеваться. Только в резко ограниченных пределах.
WH>Нет. Грамматика отключилась дойдя до конца блока в котором ее подключили.

Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?

N>>Опознание применения грамматики у тебя оказывается тоже ограниченным — потому что def отнёсся к основной грамматике.
WH>В том то и кайф. Мы прямо внутри основного языка переключаемся на совершенно другой язык.
WH>Компилятор видя что в коде пошла какаято байда переключается на грамматику для этой байды.
WH>Распарсив байду он успокаивается и возвращается к исходной грамматике.

Просто гениально... ответь plz — я могу внутрь вставить, например, код на Си?

N>>Увы, не курит. Но мне искренне приятно видеть такой энтузиазм. Я как-то в последнее время стал предельно циничен по отношению к доступным средствам, это меня самого удивляет.
WH>Не разобрался но осуждаю.
WH>Классная логика.

Ась? Ты начинаешь везде видеть только врагов. Я ему похвалу, а он в ответ отпор. Ну и ну...

N>>А как ты создашь доступный со всех точек кода единственный экземпляр объекта?
WH>Зачем?
WH>Это не нужно.
N>>Передавать такие глобальные знания всюду в функции?
WH>Именно так.
N>>Дорого и неэкономично.
WH>

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

У тебя слишком приятная предметная область. Завидую.

N>>Как я показывал, даже Erlang на такое не идёт — у него есть, например, регистрация процессов по имени и работа с фиксированными именами (init, application_controller и тому подобными).
WH>Демагогия: Аппеляция к авторитету.

Где?

N>>Любая секьюрити есть неудобство.
WH>Единственно не удобство это то что в функции открытия файла появится один обязательный параметер.

А если в него подсунуть что-то специально придуманное, но левое?

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

N>>>Если эта твоя грамматика автоматически отключилась увидев символ '}', то "как угодно" над синтаксисом ты уже не можешь издеваться. Только в резко ограниченных пределах.
WH>>Нет. Грамматика отключилась дойдя до конца блока в котором ее подключили.

N>Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?

Парсер подключенной грамматики скушал все что он сумел скушать, остальное ('}') оставил на откуп внешнему.

N>>>Опознание применения грамматики у тебя оказывается тоже ограниченным — потому что def отнёсся к основной грамматике.
WH>>В том то и кайф. Мы прямо внутри основного языка переключаемся на совершенно другой язык.
WH>>Компилятор видя что в коде пошла какаято байда переключается на грамматику для этой байды.
WH>>Распарсив байду он успокаивается и возвращается к исходной грамматике.

N>Просто гениально... ответь plz — я могу внутрь вставить, например, код на Си?

Можешь, если создашь и подключишь парсер Си.

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

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

N>А я просил привести другой пример пригодного и распространённого средства. Но ты этот вопрос пропускаешь.
Мы тут обсуждаем вопрос динамическая или статическая типизация, а не конкретные примеры.

N>Метод неверный. Верно сказать так: осталось определить, какие из этих соображений требуют ограничить множество выбора _только_ одним подмножеством (статически или динамически типизированные). Для тебя такое ограничение подразумевается по умолчанию, и если у кого-то такого умолчания нет, то ты не можешь удержаться, чтобы не развести флейм на полтысячи сообщений.
У меня логика простая. Есть два инструмента один из которых уступает второму по всем параметрам во всех ситуациях.
Зачем мне рассматривать заведомо плохой инструмен.
Ситуаций когда динамическая типизация лучше статической не продемонстрировано.
Ни одной!

N>После той мути, которую ты развёл?
Муть про "естественность" ограничений развел ты.

WH>>И это вместо того чтобы признать простой факт: Статическая типизация помогает рефакторить.
N>Я признаю этот факт и признавал его с самого начала. Ты не сможешь найти его отрицание у меня.
Замечательно.

N>Но ты из этого факта делаешь сразу вывод, что отсутствие такой типизации превращает ситуацию в неуправляемую
А как по другому найти хотябы несколько десятков мест хотябы в нескольких сотнях килобайт кода?
100% покрытие тестами это из областы фантастики.
Да и во что превратиться разработка если на каждое изменение гонять все тесты. Да еще и по нескольку раз?

N>Ещё раз: я не отрицаю факт, в данном случае, помощи многим аспектам управления кода со стороны статической типизации. Но я считаю, что ты с коллегами чрезвычайно переоцениваешь этот факт и недооцениваешь альтернативные подходы, верхоглядно и наивно полагая их плохо работающими.
Я всетки думаю что мои оценки адекватны.

N>Нет, не только этот. Например, он тебе приводил оценки скорости работы эрланга, с которыми ты ничего не смог сделать.
Он уже написал на ерланге альфабленд который работает хотябы со скоростью C#?
Можно на это посмотреть?

WH>>Только это никак не отменяет тот факт что статика при одинаковых алгоритмах как минимум не медленней.
N>Только это никак не придаёт данному факту смысл больше, чем его голое значение.
Это просто еще одно неоспоримое преимущество статики над динамикой.

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

N>Я думаю, что могу считать себя профессионалом. И я знаю, что сам освою что угодно, если потребуется. Я не могу требовать того же от всех своих сотрудников, увы. Хорошо тебе, если ты можешь подбирать только таких людей, которые выучат что угодно и прибавки не попросят

Извини меня но если человек не способен выучить OCaml за две недели то это тупая пробка от которой на любом языке вреда будет больше чем пользы. Я таких не раз видел. Увольнять сразу ибо 100% их кода всеравно уходит в мусор.

N>>>* хорошо параллелится, без GIL и тому подобных ограничений
WH>>Этим славятся какраз всякие питоны.
N>Чем именно славятся — ограничениями или их отсутствием?

gil python
Результатов: примерно 461 000

WH>>Тут нужно расшифровать.
N>Я рядом ругался на Mono, почитай.
Мне что всю философию перечитывать?

N>Обычно эти ярлыки таки соответствуют содержанию.
Ой не скажи.
Всеравно нужно смотреть.

N>Ну и? Это такая фатальная проблема — сборка мусора для кода?
Нет. Просто это нужно делать.
Мелкософты для .НЕТ не сделали. А в яве сделали.

N>Мало ли что не мешает. У нас уже контекст — не потенциальная возможность, а реальные образцы. К сожалению, доступный набор ограничен эрлангом и питоном, у остальных механизм непригоден.
Блин. Кручу верчу запутать хочу...
Разговор идет то вообще. То вдруг переключается на конкретные образци.

N>Ну ты понял, что сообщение проходит через полдесятка разных сущностей?

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

N>Я тебе привёл в своём описании аргументы в обе стороны. И за статику, и за динамику. Самое потрясающее, что ты пропустил оба комплекта аргументов. В этой ситуации я не знаю, есть ли смысл дальше обсуждать.
И меня телепатия не работает.
Давай по пунктам.
Я начну:
1)Статика быстрее динамики.
2)Статика ловит больше ошибок чем динамика.
3)Для статики можно сделать качественные IDE. Для динамики они фундаментально не возможны.
Продолжай.

N>А ты просьбу посреди абзаца заметил? Похоже, нет... ладно, и так картина понятна.
Заметил. Но

WH>>Повторяю еще раз.
WH>>Для проектирования решения внутри твоей предметной области у меня не хватает данных.
WH>>Загружать свою голову этими данными я не намерен ибо для меня они бесполезны.

N>Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?
Я так понимал ты имел в виду любую '}'?
Так вот не любую, а вполне конкретную.

N>Просто гениально... ответь plz — я могу внутрь вставить, например, код на Си?
Да.
Можно вставить абсолютно любой язык. С, SQL, ADA, Prolog, Brainfuck,... не важно.
Можно даже стиль комментариев изменить.
Когда я говорю произвольное изменение грамматики я говорю буквально.

N>Ась? Ты начинаешь везде видеть только врагов. Я ему похвалу, а он в ответ отпор. Ну и ну...
Что-то не похоже это на похвалу.
Особенно в сочетании с не пониманием о чем я вообще говорю.

WH>>

Если хоть чуть чуть проектировать выясняется что эти знания нужны очень не большому колличеству кода.
N>У тебя слишком приятная предметная область. Завидую.
Я работал с разными областями.
И у всех слой который общался с внешними ресурсами был почемуто очень маленьким.
Может быть мне повезло с задачами, а может быть дело в подходе к проектированию.

N>>>Как я показывал, даже Erlang на такое не идёт - у него есть, например, регистрация процессов по имени и работа с фиксированными именами (init, application_controller и тому подобными).
WH>>Демагогия: Аппеляция к авторитету.
N>Где?
Выделенное.
Идет отсылка к авторитету авторов ерланга.

N>А если в него подсунуть что-то специально придуманное, но левое?
Да сколько угодно.
Собственно http://en.wikipedia.org/wiki/Capability-based_security строится на том что невозможно подделать capability.
В безопасном языке нельзя подделать ссылку на объект. Причем это даже более сильная гарантия чем подписи или MAC'и которыми обычно защищают capability. Ибо криптографию хоть и сложно но можно поломать, а ссылку на объект подделать нельзя.
Таким образом ссылка на объект может выступать в роли capability.
И если у тебя этой ссылки нет то ты ничего не сделаешь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное

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

Совсем другое дело — реализация. В реализации чем больше ограничений, тем лучше. Потому что меньше вариантов. Вернись и прочитай еще раз. В самом идеальном для процесса кодирования случае, ограничения столь сильны, что вырождают весь сценарий до одной возможной ветки (полезной). А доказательством достоверного отсутствия других веток занимается как раз компилятор со статической типизацией.

Ведь что такое "тип"? Это способ разделения сущностей на сорта путем наделения их некими характеристиками (подробности зависят от конкретной системы типов). Типы существуют не забавы и этого спора ради, — это инструмент, который мы можем использовать для контроля корректности взаимодействия сущностей разных сортов, строя т.н. типизированные контракты. Причем, эти контракты будут проверяться автоматически. Т.е. в нашем распоряжении есть инструмент для избавления от таких явных проверок контрактов в рантайм, которые удастся описать с помощью системы типов, присутствующей в выбранном языке.

Не проверять контракты все-равно нельзя, это вопрос безопасности кода. И тут все кристально ясно — чем больше работы поручим компилятору, тем меньше будем долбить тупого кода ручками. По правде говоря, далеко не все контракты получается описать на том же C#. Один и самых популярных сценариев "not null" — все тупо долбят ручками, из-за недостаточно выразительной системы типов. Что характерно, всякие Решарперы прекрасно разбираются, где может придти null, а где заведомо нет, т.е. логически способ вывода этой характеристики типа существует, но не реализован в стандартном компиляторе. Это из темы зависимых типов.

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

N>Никаких возражений. Но это начинает работать только там, где человек намеренно загнал значение в определённые рамки — например, установил, что тут целое число от нуля до миллиона. А если не загнал?

Программист всегда вынужден принимать решение, искать компромисс, потому как компьютер — не волшебная палочка. Ели не уверен, бери какой-нить тип BigInt, его реализаций как собак нерезаных по и-нету. А если уверен, то конкретно в этом месте быстродействие может случиться на порядок выше, что до сих пор актуально.

WH>>Да и человеку будет легче. Вместо того чтобы судорожно соображать что там может придти можно посмотреть на тип функции. А если не посмотришь компилятор тебя носом ткнет.

N>"Что там может прийти" должно быть в документации.

Документацию, к сожалению, компилятор не читает, и помощь свою предложить не сможет. И во внутреннем коде никто толком комментарии/доки не пишет, проверено многими десятилетиями, т.е. это даже не обсуждается.

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

N>>О да, взял один частный случай намеренно кривого подхода и делаешь из этого глобальный вывод. Вообще-то любой язык программирования (а не хрен знает чего) опасный, в том смысле, что он тьюринг-полный.
WH>Я просто констатирую факт: Заявление о безопасности Go ложно.
WH>Больше ничего.

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

N>>А я просил привести другой пример пригодного и распространённого средства. Но ты этот вопрос пропускаешь.
WH>Мы тут обсуждаем вопрос динамическая или статическая типизация, а не конкретные примеры.

Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.

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

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

WH>Зачем мне рассматривать заведомо плохой инструмен.
WH>Ситуаций когда динамическая типизация лучше статической не продемонстрировано.
WH>Ни одной!

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

[skip большой кусок, в котором повторение всё тех же тезисов без малейших изменений]

N>>Нет, не только этот. Например, он тебе приводил оценки скорости работы эрланга, с которыми ты ничего не смог сделать.
WH>Он уже написал на ерланге альфабленд который работает хотябы со скоростью C#?

Нет, мне кажется. И ОС он тоже не написал. Уймись.

[опять скип по тем же причинам]

N>>Что "нет"? Кто и как у тебя определил конец блока и каким святым духом он это сделал?
WH>Я так понимал ты имел в виду любую '}'?
WH>Так вот не любую, а вполне конкретную.

То есть критерий — когда парсер не может дальше разбирать, что же это было?

N>>>>Как я показывал, даже Erlang на такое не идёт - у него есть, например, регистрация процессов по имени и работа с фиксированными именами (init, application_controller и тому подобными).
WH>>>Демагогия: Аппеляция к авторитету.
N>>Где?
WH>Выделенное.
WH>Идет отсылка к авторитету авторов ерланга.

Ничего подобного, идёт ссылка к конкретной реализации.

N>>А если в него подсунуть что-то специально придуманное, но левое?
WH>Да сколько угодно.
WH>Собственно http://en.wikipedia.org/wiki/Capability-based_security строится на том что невозможно подделать capability.
WH>В безопасном языке нельзя подделать ссылку на объект. Причем это даже более сильная гарантия чем подписи или MAC'и которыми обычно защищают capability. Ибо криптографию хоть и сложно но можно поломать, а ссылку на объект подделать нельзя.
WH>Таким образом ссылка на объект может выступать в роли capability.
WH>И если у тебя этой ссылки нет то ты ничего не сделаешь.

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

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

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

N>>Более того, всякая типизация есть _ограничение_, а ограничения в мышлении применяются только тогда, когда они не мешают, и до тех пор, пока они не мешают. Ограниченное

V>Ты путаешь стадии проектирования и реализации. И путаешь серьезно. В процессе проектирования, согласен, ограничения лишь мешают. Именно из-за этого прижились лишь параметрические инструменты для моделирования/проектирования.

Это не я путаю. Это, извини, жизнь путает. Ситуация, когда ты с самого начала на 100% чётко себе представляешь, что должно быть сделано, как и почему — это, конечно, идеальная ситуация, к ней надо стремиться, но в колоссальной доле случаев начинаешь с того, что делаешь фактически абы как — не потому, что не можешь нормально, а потому, что ещё никто не знает — ни заказчик, ни постановщик, ни архитектор... как оно должно быть.

Это всё ещё не имеет отношения к стилю типизации, но показывает причины части решений — например, описанного мной ранее варианта с прозрачной передачей набора заранее неизвестных атрибутов.

V>Ведь что такое "тип"? Это способ разделения сущностей на сорта путем наделения их некими характеристиками (подробности зависят от конкретной системы типов). Типы существуют не забавы и этого спора ради, — это инструмент, который мы можем использовать для контроля корректности взаимодействия сущностей разных сортов, строя т.н. типизированные контракты. Причем, эти контракты будут проверяться автоматически. Т.е. в нашем распоряжении есть инструмент для избавления от таких явных проверок контрактов в рантайм, которые удастся описать с помощью системы типов, присутствующей в выбранном языке.

V>Не проверять контракты все-равно нельзя, это вопрос безопасности кода. И тут все кристально ясно — чем больше работы поручим компилятору, тем меньше будем долбить тупого кода ручками. По правде говоря, далеко не все контракты получается описать на том же C#. Один и самых популярных сценариев "not null" — все тупо долбят ручками, из-за недостаточно выразительной системы типов. Что характерно, всякие Решарперы прекрасно разбираются, где может придти null, а где заведомо нет, т.е. логически способ вывода этой характеристики типа существует, но не реализован в стандартном компиляторе. Это из темы зависимых типов.

Ничего не имею против, и был бы очень рад, если бы доступные средства содержали всё это.

V>А вообще... спор странный. ИМХО, иметь под рукой некий инструмент всяко лучше, чем не иметь вообще.

Так по крайней мере с моей стороны спор не об этом. А о том, насколько всё описанное важно. WolfHound выдвигает эти критерии, а также скорость, на основные роли, я же не могу с этим согласиться — есть масса практически более важных вещей.

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

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

N>Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.
Ну я же говорю: Кручу верчу запутать хочу. То сравниваете все на все. То вдруг начинаете цеплятся к конкретным реализациям...

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

N>Нет, мне кажется. И ОС он тоже не написал. Уймись.
Ну конечно. Как только становится понятно что у динамики полный швах с производительностью так сразу уймись.

Короче слив засчитан.

N>То есть критерий — когда парсер не может дальше разбирать, что же это было?
Ты не поверишь но все парсеры так и работают.
Разбирают правило пока могут разобрать.
После чего передают управление тому правилу которое разбирали до этого.
Если вдруг выяснится что после верхнего правила остался лишний текст то сообщают об ошибке.

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

N>Ничего подобного, идёт ссылка к конкретной реализации.
К такой всей из себя авторитеной реализации...

N>Ясно. Очень громоздко,
Ну да. Один дополнительный аргумент в редко используемой функции это звездец как громоздко.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

N>>>О да, взял один частный случай намеренно кривого подхода и делаешь из этого глобальный вывод. Вообще-то любой язык программирования (а не хрен знает чего) опасный, в том смысле, что он тьюринг-полный.
WH>>Я просто констатирую факт: Заявление о безопасности Go ложно.
WH>>Больше ничего.

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

Я немножко понимаю, можно встряну?

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

Типобезопасность — это я еще могу понять. Но она не обеспечивает безопасность всей ИС, она снижает трудозатраты на минимизацию рисков, связанных с ошибками переполнения (целочисленного, буфферов, кучи и т.п.). Потокобезопасность — тоже понятно. Но она лишь снижает риски гонок и прочих concurence-уязвимостей. Безопасность полномочий кода (упомянутые CAS и CBS, например)? Ок, это здорово, но это лишь две закрытых угрозы из семи, причем только на одном уровне абстракции

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Не проверять контракты все-равно нельзя, это вопрос безопасности кода. И тут все кристально ясно — чем больше работы поручим компилятору, тем меньше будем долбить тупого кода ручками. По правде говоря, далеко не все контракты получается описать на том же C#. Один и самых популярных сценариев "not null" — все тупо долбят ручками, из-за недостаточно выразительной системы типов. Что характерно, всякие Решарперы прекрасно разбираются, где может придти null, а где заведомо нет, т.е. логически способ вывода этой характеристики типа существует, но не реализован в стандартном компиляторе. Это из темы зависимых типов.
Это из темы запрета null'а и использования option там где объекта может не быть.

А в отстальном +1

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

KV>Безопасность информационной системы вообще не зависит от используемого ЯП.
Мы говорим про safe. Ты говоришь про secure.
От того и непонимание.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

Да, можно. И что, это основание всё обложить мьютексами? Или ты кроме них механизмов синхронизации (или даже сериализации) не знаешь, по принципу "если это не написано в Коране, это ложно"?

N>>Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.
WH>Ну я же говорю: Кручу верчу запутать хочу. То сравниваете все на все. То вдруг начинаете цеплятся к конкретным реализациям...

У меня всегда в этом треде был интерес именно в конкретных запросах и к конкретным реализациям.

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

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

N>>Нет, мне кажется. И ОС он тоже не написал. Уймись.
WH>Ну конечно. Как только становится понятно что у динамики полный швах с производительностью так сразу уймись.
WH>Короче слив засчитан.

Твой — да, почти с самого начала ни одной новой мысли, всё долбление в одну точку.

N>>То есть критерий — когда парсер не может дальше разбирать, что же это было?
WH>Ты не поверишь но все парсеры так и работают.

Не поверю — потому что знаю парсеры, которые работают иначе, и знаю причины делать иначе.

WH>Таким образом если делать правильно никаких проблем с тем чтобы разобрать байду и вернуться к разбору основного языка нет.
WH>А там уже и закрывающая скобка без проблем найдется.
WH>Главный фокус состоит в том чтобы динамически менять набор правил в грамматике.

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

N>>и слабо понятно, где это настолько важно, чтобы программисты потерпели все неудобства.
WH>Везде.
WH>Это позволит похоронить вирусы на корню.

Я эти обещания читал сотни раз.

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

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

KV>>Безопасность информационной системы вообще не зависит от используемого ЯП.
WH>Мы говорим про safe. Ты говоришь про secure.
WH>От того и непонимание.

Черт, такая интересная дискуссия сорвалась

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

KV>>Безопасность информационной системы вообще не зависит от используемого ЯП.
WH>Мы говорим про safe. Ты говоришь про secure.
WH>От того и непонимание.

Перечитал еще раз. По-моему, netch80 говорит-таки о security, а не о safety, ибо:

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

N>>Посмотри внимательно на заголовок треда, на содержание первого письма. Мы не обсуждаем типизацию саму по себе, мы обсуждаем готовые "изделия" в виде языков со всеми их свойствами. Более того, изначально тред был посвящён применению именно _в вебе_. Если ты обсуждаешь что-то иное — динамическую или статическую типизацию в сферическом вакууме — то мне такая тематика просто неинтересна.
WH>Ну я же говорю: Кручу верчу запутать хочу. То сравниваете все на все. То вдруг начинаете цеплятся к конкретным реализациям...

Угу. Кто бы говорил. То «всегда» то «а вот в Немерле» здесь постоянно слышно именно от тебя.

N>>Нет, мне кажется. И ОС он тоже не написал. Уймись.
WH>Ну конечно. Как только становится понятно что у динамики полный швах с производительностью так сразу уймись.

WH>Короче слив засчитан.

Интересно, ты намеренно тупым притворяешься?

http://www.joeandmotorboat.com/2009/01/03/nginx-vs-yaws-vs-mochiweb-web-server-performance-deathmatch-part-2/

Все в порядке там с производительностью.

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

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

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

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

KV>>>Безопасность информационной системы вообще не зависит от используемого ЯП.
WH>>Мы говорим про safe. Ты говоришь про secure.
WH>>От того и непонимание.

KV>Перечитал еще раз. По-моему, netch80 говорит-таки о security, а не о safety, ибо:

KV>

KV>безопасность как понятие имеет смысл только при выставлении конкретных условий и ограничений, определения опасности и методов защиты от неё

Извини, это была всё-таки тема safety. Пардон за сбивание с толку, но базовые принципы применимы к обоим омонимам. Например, для C++ ты можешь обернуть доступ к объекту в мьютексы, но если кто-то полезет прямой модификацией памяти, никакая обёртка не поможет. И аналогичные ситуации и проблемы можно получить везде, хотя выглядеть будут существенно по-разному (например, для Erlang ты не залезешь в другой процесс, если он того не допустит, но можешь сбить с толку его взаимодействие с твоим процессом или организовать частичный DoS требованием ресурса). Более того, в этом аспекте security и safety сливаются в одно понятие — делать то, что можно (говоря по-бытовому), а различие между ними сокращается до вопроса источника возможной проблемы (внешний или внутренний).

WolfHound ругался на Go, утверждая, что его авторы явно врут про безопасность, хотя ничего для этого не делают. Я попытался объяснить, что такая безопасность, как он хочет, возможна, но чрезмерно ограничительна и расточительна; что есть много других методов, которые этим не страдают; наконец, что требовать безопасности от, например, доступа к глобальным переменным — вообще не имеет смысла для среды такого типа, как Go. Но меня, увы, просто не слышат.

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

WH>Это позволит похоронить вирусы на корню.

А чем вирус принципиально отличается, скажем, от драйвера?

V>Ведь что такое "тип"? Это способ разделения сущностей на сорта путем наделения их некими характеристиками (подробности зависят от конкретной системы типов). Типы существуют не забавы и этого спора ради, — это инструмент, который мы можем использовать для контроля корректности взаимодействия сущностей разных сортов, строя т.н. типизированные контракты. Причем, эти контракты будут проверяться автоматически. Т.е. в нашем распоряжении есть инструмент для избавления от таких явных проверок контрактов в рантайм, которые удастся описать с помощью системы типов, присутствующей в выбранном языке.

Я тут уже приводил пример. Есть такая лавка, JanRain. Они предлагают унифицированный логин через OpenID/MySpace/Twitter/Facebook и т.п. После логина пользователя они прислыают его профиль. Вот описание: https://rpxnow.com/docs#profile_data

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

Ну и как, скажите мне, поможет мне статика при работе с этим данными?

Да никак. Все выливается в итоге в if post.data contains field_1, if post.data contains field_2 и т.п.

Псевдокод


void process_request(Request req){

    Profile profile = null;

    if(req.contains("profile")){
    
        profile = new Profile(req);
    }

    set_session_profile(req, profile);
}


void set_session_profile(Request req, Profile profile){
    req.session.user.set_name(profile.get("formatted_name"));  // вылетели к чертям в рантайме
}

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

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

Чудес не бывает

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

M>Из 16 полей только 2 будут присутствовать всегда. Остальные — необязательные. Не говоря уже о том, что два из этих необязательных являются списком из других необязательных полей.

Достаточно создать сериализатор, понимающий тип option[T]:

[XmlElement("Profile")]
class Profile
{
  [XmlElement("A")]
  public RequiredField1 : string { get; set; }

  [XmlElement("B")]
  public RequiredField2 : int { get; set; }

  [XmlElement("X")]
  public OptionalField1 : option[string] { get; set; }

  [XmlElement("Y")]
  public OptionalField2 : option[int] { get; set; }
}

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

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

VD>>Так что как не крути это еще одна попытка выдать сказки за чудесную действительность.
VD>>Я уже устал повторять. Чудес не бывает. Скрипты дико медленны и могу использоваться только как клей для компонентов созданных на более быстрых средствах разрабоки. Компиляция скриптов конечно может несколько их ускорить, но в общем случае это ускорение не будет очень значительным в следствии динамической природы самих язков.

ВВ>Ты хочешь сказать, что если динамический язык компилируется, а не интерпретируется, то это не дает значительного ускорения?

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

Надо признать, что довольно шустро в динамике работают условные ветвления и циклы, фактически как в нейтиве, ибо ложь обычно представлена как null или как ссылка на некий заведомо известный атом #false, т.е., в зависимости от способа организации того самого промежуточного представления, можнонивелировать лишние затраты на эти популярные операции. Особенно циклы, если он поддержаны языком, а не реализованы на бестиповом while. Но вот с числовыми вычислениями — просто беда. Ну и не надо забывать про агрессивный инлайнинг что у того же С++, что у современных JIT.

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

ВВ>>Ты хочешь сказать, что если динамический язык компилируется, а не интерпретируется, то это не дает значительного ускорения?

V>Они и так все компилируются сначала во внутреннее представление.

Ну во-первых, не все. Если только "внутренним представлением" вы не называете AST. Потом — ну зачем придираться к словам? Понятно же, что я имею в виду.

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

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

M>>Из 16 полей только 2 будут присутствовать всегда. Остальные — необязательные. Не говоря уже о том, что два из этих необязательных являются списком из других необязательных полей.

H>Достаточно создать сериализатор, понимающий тип option[T]:

H>

H>[XmlElement("Profile")]
H>class Profile
H>{
H>  [XmlElement("A")]
H>  public RequiredField1 : string { get; set; }

H>  [XmlElement("B")]
H>  public RequiredField2 : int { get; set; }

H>  [XmlElement("X")]
H>  public OptionalField1 : option[string] { get; set; }

H>  [XmlElement("Y")]
H>  public OptionalField2 : option[int] { get; set; }
H>}
H>

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

А причем тут компилятор к рантайму?

Это во-первых. Во-вторых, точно так же можно сделать и в динамике

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

Возможности статики по гарантированию чего-либо сильно преувеличены в этом топике

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

M>А причем тут компилятор к рантайму?

При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?

M>

Это во-первых. Во-вторых, точно так же можно сделать и в динамике

С.м. выше. Как сделать в динамике, чтобы нельзя было написать Nothing().FooBar()?

M>

В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме.

В каком смысле побоку?

M> Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере

Во втором примере статическая типизация не используется.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

M>А причем тут компилятор к рантайму?

Потому что профиль наш строго типизирован и мы знаем какие поля могут принимать значение "нету".

M>Во-вторых, точно так же можно сделать и в динамике

Проверять на null?

M>В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме.

Каков программист — такова и программа.

M>Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере

Нам на этапе компиляции известны все поля, которые могут не содержать значение, таким образом мы объявляем их тип как option[T], где T — фактический тип поля. Правильно написанный десериализатор изготовит нам соответствующим образом проинициализированный объект.

Параметрический тип option[T] может принимать два значения: Some(t) и None(), где t — экземпляр типа T.
К фактическому значению некоторого поля мы можем добраться только тогда, когда это поле содержит значение Some(t), таким образом, каждый раз обращаясь к полю нам придется обрабатывать два случая: значение в поле есть (Some) и значения в нем нет (None). И то, что мы всегда в программе обрабатываем эти два случая проконтролирует компилятор.

M>>А причем тут компилятор к рантайму?

K>При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?

Ага. Это в теории. И, судя по Maybe, в хаскеле. Стоп. А откуда компилятор внезапно узнает, что там Maybe? Можно пример кода? Желательно, конечно не на Хаскеле, а на чем-то более приземленном, например на Java. Но на Хаскелле тоже сойдет.

M>>

Это во-первых. Во-вторых, точно так же можно сделать и в динамике
K>С.м. выше. Как сделать в динамике, чтобы нельзя было написать Nothing().FooBar()?

Точно так же как в статике

Потому что даже в статике компилятор (анализатор? неонка?) не уверен, будет там null или нет.

Ловкость рук и никакого мошенничества (использую уже готовые типы из программы, но суть ясна). Язык — Java. IDE — JetBrains IDEA

Ошибка есть:

Икомпилятор выдает

Ошибка нет:

Компилятор выдает compiled successfully.

Но это же статика! Как такое может быть?

M>>

В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме.
K>В каком смысле побоку?

В прямом. Компилятор не отловит этой ошибки. Или так — теоретически быть может в каком-то языке он ее отловит.

M>> Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере

K>Во втором примере статическая типизация не используется.

С чего это вдруг? Все типы указаны, компилятор молчит

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

M>>А причем тут компилятор к рантайму?

H>Потому что профиль наш строго типизирован и мы знаем какие поля могут принимать значение "нету".

M>>Во-вторых, точно так же можно сделать и в динамике

H>Проверять на null?

Оставляю эо как домашнее задание.

M>>В-третьих, в указанной мною ситуации это вообще побоку, потому что если profile не будет, то программа вылетит в рантайме.
H>Каков программист — такова и программа.

Это к вопросу не относится вообще никак. Имеем, что имеем. Тут мне рассказывают про чуда, а чуд как-то не получается.

M>>Ну и в четвертых наличие статической типизации почему-то никак не помогло мне во втором примере

H>Нам на этапе компиляции известны все поля, которые могут не содержать значение, таким образом мы объявляем их тип как option[T], где T — фактический тип поля. Правильно написанный десериализатор изготовит нам соответствующим образом проинициализированный объект.

H>Параметрический тип option[T] может принимать два значения: Some(t) и None(), где t — экземпляр типа T.
H>К фактическому значению некоторого поля мы можем добраться только тогда, когда это поле содержит значение Some(t), таким образом, каждый раз обращаясь к полю нам придется обрабатывать два случая: значение в поле есть (Some) и значения в нем нет (None). И то, что мы всегда в программе обрабатываем эти два случая проконтролирует компилятор.

В примере не доступ к полям с null. Там попытка вызвать метод у null.

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

M>С чего это вдруг? Все типы указаны, компилятор молчит

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

О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.

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

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

M>>С чего это вдруг? Все типы указаны, компилятор молчит

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

H>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.

Ну это совершенно не влияет на языки, которые работают на этих машинах.
В F#, например, есть not-nullable типы.

M>>С чего это вдруг? Все типы указаны, компилятор молчит

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

H>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.

В итоге, что имеем в сухом остатке?

Изначальное заявление: Нам нужна статика.

В процессе допытывания выясняется, последовательно:
— Нет, нам нужна статика с хорошей системой типов.
— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п.
— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п., и желательно чтобы это был или Haskell или Nemerle.

И вот только тогда мы, быть может, сможем показать на практике те чудеса, которые мы вам обещали под эгидой «статика круче всегда!»

В общем, это то, о чем говорил netch80, когда говорил о своих критериях тут: http://rsdn.ru/forum/philosophy/4006147.1.aspx (со слов «Во-первых, о существующих средствах и текущих задачах»). И то как раз то, из-за чего тут разведено столько флейма. Нам обещают чудеса статики, но на практике этих чудес или не видно или видно только с кучей ограничений (типа «системы типов JVM и CLR не поддерживают not-nullable ссылочных типов»)

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

H>>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.

G>Ну это совершенно не влияет на языки, которые работают на этих машинах.

Вообще-то влияет. Ка бы эта опция была — она была бы во всех языках на этих платформах, а сейчас же её достаточно проблематично реализовывать.

G>В F#, например, есть not-nullable типы.

Спс. Проясню этот вопрос.

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

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

H>>>О NotNull контрактах не так давно говорилось — системы типов JVM и CLR не поддерживают not-nullable ссылочных типов.

G>>Ну это совершенно не влияет на языки, которые работают на этих машинах.
H>Вообще-то влияет.
Вообще никак не влияет, это вопрос системы типов (компилятора, а не рантайма), компилятор может просто не предусматривать null значений. Или не допускать присваивания null для notnullable типов.

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

K>>При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?

M>Ага. Это в теории.

Это если сделать допущение, что сейчас 1958-ой год, но сейчас 2010.

M>И, судя по Maybe, в хаскеле.

Особенно судя по словам "вызвать метод объекта".

M>Стоп. А откуда компилятор внезапно узнает, что там Maybe? Можно пример кода? Желательно, конечно не на Хаскеле, а на чем-то более приземленном, например на Java.

Пример на C# (Maybe придется написать самому (8 строчек) или скачать готовую)

from profile in GetProfile()
from result in ProcessRequest(profile)
select result;

Значение этого выражения Just(результат реквеста), если все прошло нормально или Nothing()

ProcessRequest(GetProfile());

Не скомпилируется.
Чудес бывает.

M>Точно так же как в статике

Потому что даже в статике компилятор (анализатор? неонка?) не уверен, будет там null или нет.

Если у нас в языке есть null, то это означает, что то, имеем мы тип T или тип Maybe<T> определяется динамически. К статической типизации null никакого отношения не имеет.

K>>В каком смысле побоку?
M>В прямом. Компилятор не отловит этой ошибки. Или так — теоретически быть может в каком-то языке он ее отловит.

На практике отловит в целом ряде языков.

K>>Во втором примере статическая типизация не используется.
M>С чего это вдруг? Все типы указаны, компилятор молчит

Компилятор молчит, потому что программиcт заткнул ему рот явной декларацией отключения статической типизации. В коде она выделенна жирным шрифтом:

GremlinScriptEngine engine = (GremlinScriptEngine)f.getScriptEngine();

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

K>>>При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?

M>>Ага. Это в теории.

K>Это если сделать допущение, что сейчас 1958-ой год, но сейчас 2010.

Все поскипано. Ответ тут: http://rsdn.ru/forum/philosophy/4008594.aspx

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

G>Вообще никак не влияет, это вопрос системы типов (компилятора, а не рантайма), компилятор может просто не предусматривать null значений. Или не допускать присваивания null для notnullable типов.

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

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

M>Все поскипано.

Отличный подход к дискуссии, спасибо.

M>Ответ тут: http://rsdn.ru/forum/philosophy/4008594.aspx

>Изначальное заявление: Нам нужна статика.

Верно.

>В процессе допытывания выясняется, последовательно:
>— Нет, нам нужна статика с хорошей системой типов.

Не так. "Даже статика с посредственной системой типов — уже лучше чем динамика, но нам нужна статика с хорошей системой типов"

>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п.

Это было бы еще лучше, но почему "нет"? — с какой стати отказываться от предыдущих пунктов? Все логично — чем лучше система типов — тем лучше. Совершеннейший трюизм.

>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п., и желательно чтобы это был или >Haskell или Nemerle.

Зависимых типов нет ни в Haskell, ни в Nemerle.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

M>>Все поскипано.
K>Отличный подход к дискуссии, спасибо.

Рекомендую

M>>Ответ тут: http://rsdn.ru/forum/philosophy/4008594.aspx
>>Изначальное заявление: Нам нужна статика.
K>Верно.

>>В процессе допытывания выясняется, последовательно:
>>— Нет, нам нужна статика с хорошей системой типов.

K>Не так. "Даже статика с посредственной системой типов — уже лучше чем динамика, но нам нужна статика с хорошей системой типов"

>>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п.

K>Это было бы еще лучше, но почему "нет"? — с какой стати отказываться от предыдущих пунктов? Все логично — чем лучше система типов — тем лучше. Совершеннейший трюизм.

Я просто сократил текст. Читать как «нет, нам не просто А, но и с Б».

>>— Нет, нам нужна статика с системой типов, поддерживающей все, что угодно — constraints, dependent types, контракты и т.п., и желательно чтобы это был или >Haskell или Nemerle.

K>Зависимых типов нет ни в Haskell, ни в Nemerle.

Я просто показал общий вид дискуссии. И, повторюсь, на это уже ответил netch80 тут: http://rsdn.ru/forum/philosophy/4006147.1.aspx (начиная со слов «Во-первых, о существующих средствах и текущих задачах...»).

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

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

G>>Вообще никак не влияет, это вопрос системы типов (компилятора, а не рантайма), компилятор может просто не предусматривать null значений. Или не допускать присваивания null для notnullable типов.

H>А вопрос получения подобного типа извне? Очевидное решение с автоматической проверкой на null кажется мне несколько непроизводительным.
А в чем проблема? Отсутствие значение реализуется типом option.

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

K>>Отличный подход к дискуссии, спасибо.
M>Рекомендую

Боюсь испортить свою репутацию.

M>Я просто сократил текст. Читать как «нет, нам не просто А, но и с Б».

Ну а что такого-то? Если статику можно неограниченно улучшать — это повод обратиться к динамике, которая заведомо хуже? Это какая-то логика абсолютников из НИИЧАВО, которые отказывались что-либо делать, потому что процесс познания бесконечен.

M>Я просто показал общий вид дискуссии. И, повторюсь, на это уже ответил netch80 тут: http://rsdn.ru/forum/philosophy/4006147.1.aspx (начиная со слов «Во-первых, о существующих средствах и текущих задачах...»).

Он ответил, что не знает, какие есть стат. типизированные языки и не хочет ими пользоваться. Этому, конечно, трудно что-то противопоставить.

Какие-то комментарии по моему сообщению будут или "все поскипано" — это окончательный ответ?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

H>>А вопрос получения подобного типа извне? Очевидное решение с автоматической проверкой на null кажется мне несколько непроизводительным.

G>А в чем проблема? Отсутствие значение реализуется типом option.

Пусть в некотором языке мы имеем некую публичную функцию:

public F(x : X) : Y
{
...
}

Где X — non-nullable тип. Как мы можем гарантировать тот факт, что при вызове этой функции из языка, не умеющего обращаться с non-nullable типами, в параметр x не будет передан null?
Я вижу только автоматическое добавление проверок на null в таких публичных интерфейсах.

M>>Я просто сократил текст. Читать как «нет, нам не просто А, но и с Б».

K>Ну а что такого-то? Если статику можно неограниченно улучшать — это повод обратиться к динамике, которая заведомо хуже?

Снова эта сферовакуумная заведомость

K>Это какая-то логика абсолютников из НИИЧАВО, которые отказывались что-либо делать, потому что процесс познания бесконечен.

Нет. Ниже.

M>>Я просто показал общий вид дискуссии. И, повторюсь, на это уже ответил netch80 тут: http://rsdn.ru/forum/philosophy/4006147.1.aspx (начиная со слов «Во-первых, о существующих средствах и текущих задачах...»).

K>Он ответил, что не знает, какие есть стат. типизированные языки и не хочет ими пользоваться. Этому, конечно, трудно что-то противопоставить.

Вообще-то, он ответил ровно следующее:

Мне нужно средство, которое:
* в основе императивное, или если функционально-декларативное, то самое распространённое и понятное из. потому что мне надо учить людей не языку, а предметной области — она слишком сложна, чтобы войти с ходу.
* хорошо параллелится, без GIL и тому подобных ограничений
* работает на Unix системах, причём максимально родным методом (без ретрансляции подложки, которая не даёт прямого доступа к принципиальным аспектам функционирования)
* вышло из стадии альф и бет, имеет как минимум один релиз с известными граблями
* допускает хотя бы на уровне отдельных совместимых блоков замену кода на ходу (причём не "выгрузкой домена приложения", а она должна быть полностью прозрачна для работающего кода (например, звонок не должен рваться)

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

В итоге оказывается, что не в 1958-м году, а всего лишь в 2010-м таких языков и нет почти. Те, что реализуют чудеса и сказки, здесь описанные, обычно разрабатываются кучкой энтузиастов (и Nemerle и рекламируемый тут Ur). Те, что не реализуют... В общем, не реализуют они, вызывая естественное недоумение «а где все те бенефиты, что вы тут расписываете?».

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

K>Какие-то комментарии по моему сообщению будут или "все поскипано" — это окончательный ответ?

Ща понапишу

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

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

H>>>А вопрос получения подобного типа извне? Очевидное решение с автоматической проверкой на null кажется мне несколько непроизводительным.

G>>А в чем проблема? Отсутствие значение реализуется типом option.

H>Пусть в некотором языке мы имеем некую публичную функцию:
H>

H>public F(x : X) : Y
H>{
H>...
H>}
H>

H>Где X — non-nullable тип. Как мы можем гарантировать тот факт, что при вызове этой функции из языка, не умеющего обращаться с non-nullable типами, в параметр x не будет передан null?
Можно не экспортировать эту функцию из библиотеке на языке, который умеет обращаться с non-nullable.

K>>>При том, что компилятор не даст вызвать метод объекта, находящегося в Maybe, а если динамически типизированный язык не позволяет написать Nothing().FooBar(), то какой же он динамический?

M>>Ага. Это в теории.

K>Это если сделать допущение, что сейчас 1958-ой год, но сейчас 2010.

И? Пример языка из 2010-го года я привел

M>>Стоп. А откуда компилятор внезапно узнает, что там Maybe? Можно пример кода? Желательно, конечно не на Хаскеле, а на чем-то более приземленном, например на Java.

K>Пример на C# (Maybe придется написать самому (8 строчек) или скачать готовую)
K>

K>from profile in GetProfile()
K>from result in ProcessRequest(profile)
K>select result;
K>

K>Значение этого выражения Just(результат реквеста), если все прошло нормально или Nothing()
K>

K>ProcessRequest(GetProfile());
K>

K>Не скомпилируется.
K>Чудес бывает.

Можно с этого места поподробнее? Что Maybe и где оно тут и как используется?

M>>Точно так же как в статике

Потому что даже в статике компилятор (анализатор? неонка?) не уверен, будет там null или нет.

K>Если у нас в языке есть null, то это означает, что то, имеем мы тип T или тип Maybe<T> определяется динамически. К статической типизации null никакого отношения не имеет.

Всю жизнь считал Java и C# статичеси-типизированными. Видимо, увы. Придется заужать область поиска до... Хаскеля, анверное. Я прав? В общем, все согласно тут

K>>>В каком смысле побоку?
M>>В прямом. Компилятор не отловит этой ошибки. Или так — теоретически быть может в каком-то языке он ее отловит.
K>На практике отловит в целом ряде языков.

Ну да. ML-семейство. Haskell. Nemerle. Я прав? Только вот проблема. В течение всего этого топика постоянно говорится, что «статика то, статика сё». Тольо опять же ВНЕЗАПНО оказывается, что статика то и сё только в некоторых языках

Ах, нет. Все верно. Статический язык должен быть правильным, что бы это ни значило

И только тогда он будет, как минимум, не хуже динамики

Признаю, что Haskell и Nemerle ничем не хуже динамически типизированых языков (и все еще жду рвущий yaws или хотя бы mochiweb веб-сервер на nemerle)

K>>>Во втором примере статическая типизация не используется.
M>>С чего это вдруг? Все типы указаны, компилятор молчит

K>Компилятор молчит, потому что программиcт заткнул ему рот явной декларацией отключения статической типизации. В коде она выделенна жирным шрифтом:
K>

K>GremlinScriptEngine engine = (GremlinScriptEngine)f.getScriptEngine(); 
K>

Ах, вот оно что

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

M>И? Пример языка из 2010-го года я привел

Это Яву чтоли? Ну так это не спортивно, если от стат.типизированных выступает Ява, то в противоположном углу ринга, за динамику, может быть только PHP.

M>Можно с этого места поподробнее? Что Maybe и где оно тут и как используется?

Вот вы Maybe не видите, а она есть. GetProfile() возвращает Maybe<Profile>, а ProcessRequest принимет Profile и возвращает Maybe<FooBar>. Используется для того, чтобы недопустить написания второго варианта кода, который может упасть в рантайме.

M>Всю жизнь считал Java и C# статичеси-типизированными.

Они статически типизированны по-умолчанию, но проверки можно перенести в рантайм, сделать динамическими, как вы и сделали в своем коде на Яве. Если не пытаться всеми средствами избавить компилятор от контроля типов, а наоборот, перекладывать на него проверку всего, чего можно — ситуация сразу улучшится.

M>Ну да. ML-семейство. Haskell. Nemerle. Я прав?

Да. И почти во всех остальных стат типизированных языках. Единственное требование — в языке должен быть параметрический полиморфизм. Или и это слишком строгое требование?

M>Только вот проблема. В течение всего этого топика постоянно говорится, что «статика то, статика сё». Тольо опять же ВНЕЗАПНО оказывается, что статика то и сё только в некоторых языках

Замените "языки" на любой %класс_объектов%, а "некоторый язык" на %объект_соотв_класса% и ваша чудесная фраза останется верной!
Например: В течении всего топика шла речь о преимуществах самолетов перед дирижаблями и ВДРУГ выясняется, что не все самолеты одинаково полезны, тот же паровой самолет "Эол" никуда не годится. Ergo дирижабли лучше!

M>Ах, нет. Все верно. Статический язык должен быть правильным, что бы это ни значило

И только тогда он будет, как минимум, не хуже динамики

Более того, стат.типизацией нужно еще уметь пользоваться, а не прилагать все усилия для избавления компилятора от ненужного бремени. Вот ужас-то!

K>>Компилятор молчит, потому что программиcт заткнул ему рот явной декларацией отключения статической типизации. В коде она выделенна жирным шрифтом:
M>Ах, вот оно что

Ну попробуйте убрать (GremlinScriptEngine). Что написал компилятор?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

V>А чем вирус принципиально отличается, скажем, от драйвера?
Тем что драйвер не устанавливается через дыру в парсере JPEG.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>Интересно, ты намеренно тупым притворяешься?
M>http://www.joeandmotorboat.com/2009/01/03/nginx-vs-yaws-vs-mochiweb-web-server-performance-deathmatch-part-2/
M>Все в порядке там с производительностью.
А я думал ты умнее.
Измерять производительность языков программирования задачей чуть меньше чем на 100% состоящей из IO это сильно.
Кстати посмотри свою же ссылку. Там написано что nginx съел меньше процессора.
Так что если в твоем коде на ерланге заведется логика то...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

N>Да, можно. И что, это основание всё обложить мьютексами? Или ты кроме них механизмов синхронизации (или даже сериализации) не знаешь, по принципу "если это не написано в Коране, это ложно"?
Ты сейчас пытаешься обвинить меня в том чего я не говорил и на основе этого высосать из пальца обоснование моей не компетентности.
Все что я сказал что утверждение о том что Go безопасный ложно.
Больше ничего.

N>Нет, ты их постоянно творчески игнорируешь. Такая устойчивость заслуживает медали.
Ну так приведи простой список.
Каждое преимущество опиша несколькими словами.
Для статики я это делал не однократно. В ответ получал кучу философии в которой черт ногу сломит.

N>Твой — да, почти с самого начала ни одной новой мысли, всё долбление в одну точку.
Разумеется.
Ведь никто так и не смог опровергнуть мои изначальные мысли.
Более того ты в конце концов согласился с моим списком преимуществ статики.
Но так и не назвал преимуществ динамики.

N>Не поверю — потому что знаю парсеры, которые работают иначе, и знаю причины делать иначе.
Ссылку в студию.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

M>В общем, это то, о чем говорил netch80, когда говорил о своих критериях тут: http://rsdn.ru/forum/philosophy/4006147.1.aspx (со слов «Во-первых, о существующих средствах и текущих задачах»). И то как раз то, из-за чего тут разведено столько флейма. Нам обещают чудеса статики, но на практике этих чудес или не видно или видно только с кучей ограничений (типа «системы типов JVM и CLR не поддерживают not-nullable ссылочных типов»)

Так это ты же тут у нас агитируешь сравнивать всю статику с всей динамикой...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

M>>И? Пример языка из 2010-го года я привел

K>Это Яву чтоли? Ну так это не спортивно, если от стат.типизированных выступает Ява, то в противоположном углу ринга, за динамику, может быть только PHP.

Ну то же самое можно и в C# сделать

Особо других мейнстримных и не осталось

M>>Можно с этого места поподробнее? Что Maybe и где оно тут и как используется?

K>Вот вы Maybe не видите, а она есть. GetProfile() возвращает Maybe<Profile>, а ProcessRequest принимет Profile и возвращает Maybe<FooBar>. Используется для того, чтобы недопустить написания второго варианта кода, который может упасть в рантайме.

Ага. То есть в случае с C# все ранво перекладывается на плечи программиста. Чтобы не забыл реализовать Maybe, чтобы не забыл его вернуть и т.п. То есть чуда по любому нет

M>>Всю жизнь считал Java и C# статичеси-типизированными.

K>Они статически типизированны по-умолчанию, но проверки можно перенести в рантайм, сделать динамическими, как вы и сделали в своем коде на Яве. Если не пытаться всеми средствами избавить компилятор от контроля типов, а наоборот, перекладывать на него проверку всего, чего можно — ситуация сразу улучшится.

Зачем же всеми средствами

M>>Ну да. ML-семейство. Haskell. Nemerle. Я прав?

K>Да. И почти во всех остальных стат типизированных языках.

Почти во всех — это каких? Потому что я как бы эта, практик

Меня интересуют не Ur'ы/Nemerle, а sprb? которые хоть можно применить в проекте, не боясь гнева начальства

K>Единственное требование — в языке должен быть параметрический полиморфизм. Или и это слишком строгое требование?

Да нет, нормальное

M>>Только вот проблема. В течение всего этого топика постоянно говорится, что «статика то, статика сё». Тольо опять же ВНЕЗАПНО оказывается, что статика то и сё только в некоторых языках

K>Замените "языки" на любой %класс_объектов%, а "некоторый язык" на %объект_соотв_класса% и ваша чудесная фраза останется верной!
K>Например: В течении всего топика шла речь о преимуществах самолетов перед дирижаблями и ВДРУГ выясняется, что не все самолеты одинаково полезны, тот же паровой самолет "Эол" никуда не годится. Ergo дирижабли лучше!

Ну мы то прекрасно знаем, что аналогии всегда неверны

M>>Ах, нет. Все верно. Статический язык должен быть правильным, что бы это ни значило

И только тогда он будет, как минимум, не хуже динамики

K>Более того, стат.типизацией нужно еще уметь пользоваться, а не прилагать все усилия для избавления компилятора от ненужного бремени. Вот ужас-то!

Да ладно, все усилия. Что предлагает язык, то и использую

Никакими «всеми усилиями» тут и не пахнет

K>>>Компилятор молчит, потому что программиcт заткнул ему рот явной декларацией отключения статической типизации. В коде она выделенна жирным шрифтом:
M>>Ах, вот оно что

K>Ну попробуйте убрать (GremlinScriptEngine). Что написал компилятор?

Скажет incompatible types

M>>Интересно, ты намеренно тупым притворяешься?
M>>http://www.joeandmotorboat.com/2009/01/03/nginx-vs-yaws-vs-mochiweb-web-server-performance-deathmatch-part-2/
M>>Все в порядке там с производительностью.
WH>А я думал ты умнее.
WH>Измерять производительность языков программирования задачей чуть меньше чем на 100% состоящей из IO это сильно.
WH>Кстати посмотри свою же ссылку. Там написано что nginx съел меньше процессора.
WH>Так что если в твоем коде на ерланге заведется логика то...

Ну, и заводится. Можно не yaws/mochiweb взять, а какой-нибудь вообще ejabberd. netch80 тебе про коммуникационные протоколы рассказал

Нет. Пофиг. Главное завести шарманку «оно медленнее!»

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

M>Ну, и заводится. Можно не yaws/mochiweb взять, а какой-нибудь вообще ejabberd. netch80 тебе про коммуникационные протоколы рассказал

Ну так там тоже IO чуть меньше чем 100%

M>Нет. Пофиг. Главное завести шарманку «оно медленнее!»

Ну так оно медленней.
Если не веришь реши любую задачу которая ест процессор и не требует IO.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

M>>В общем, это то, о чем говорил netch80, когда говорил о своих критериях тут: http://rsdn.ru/forum/philosophy/4006147.1.aspx (со слов «Во-первых, о существующих средствах и текущих задачах»). И то как раз то, из-за чего тут разведено столько флейма. Нам обещают чудеса статики, но на практике этих чудес или не видно или видно только с кучей ограничений (типа «системы типов JVM и CLR не поддерживают not-nullable ссылочных типов»)

WH>Так это ты же тут у нас агитируешь сравнивать всю статику с всей динамикой...

Я???

http://rsdn.ru/forum/philosophy/3998623.1.aspx

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

http://rsdn.ru/forum/philosophy/3999552.1.aspx

Статика:
1)Проверка структуры декларативна.
2)Автокомплит, рефакторинг, навигация,...
3)Компилятор находит все опечатки и несоответствия типов. Хрен что забудешь.
4)Скорость работы высокая.

Динамика:
1)Проверки структуры императивны и размазаны по всей программе.
2)Поддержки IDE нет. Ибо структура объекта не извесна. И взять ее негде.
3)Компилятор молчит.
4)Тормоза.

Ну и т.п. Что характерно, из второго бенефиты статики видны только на неких «правильных» статических языках © ты же

За сферовакуумностью — это к тебе

M>>Ну, и заводится. Можно не yaws/mochiweb взять, а какой-нибудь вообще ejabberd. netch80 тебе про коммуникационные протоколы рассказал

WH>Ну так там тоже IO чуть меньше чем 100%

M>>Нет. Пофиг. Главное завести шарманку «оно медленнее!»

WH>Ну так оно медленней.
WH>Если не веришь реши любую задачу которая ест процессор и не требует IO.

Ага. То есь ВНЕЗАПНО исчезла сферовакуумность тезиса «оно медленнее». ВНЕЗАПНО надо находить и подбирать задачи

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

M>Ага. То есь ВНЕЗАПНО исчезла сферовакуумность тезиса «оно медленнее». ВНЕЗАПНО надо находить и подбирать задачи

Нет. Измерять скорость языка скоростью IO просто глупо.
Ибо будет измерена не скорость языка, а скорость IO.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Mamut, Вы писали:

M>Ага. То есть в случае с C# все ранво перекладывается на плечи программиста. Чтобы не забыл реализовать Maybe, чтобы не забыл его вернуть и т.п. То есть чуда по любому нет

Ага, и программу в добавок нужно самому писать. Где же чудо то?

Здравствуйте, WolfHound, Вы писали:

N>>Да, можно. И что, это основание всё обложить мьютексами? Или ты кроме них механизмов синхронизации (или даже сериализации) не знаешь, по принципу "если это не написано в Коране, это ложно"?
WH>Ты сейчас пытаешься обвинить меня в том чего я не говорил и на основе этого высосать из пальца обоснование моей не компетентности.
WH>Все что я сказал что утверждение о том что Go безопасный ложно.
WH>Больше ничего.

Я утверждаю, что это твоё утверждение "что Go безопасный ложно" некорректно без указания, как именно мы определяем безопасность. И если тебе так хочется — да, я нахожу основание твоей... мнэээ... недоработки — в том, что ты не понимаешь, что такое безопасность, но хаешь чужое.

N>>Нет, ты их постоянно творчески игнорируешь. Такая устойчивость заслуживает медали.
WH>Ну так приведи простой список.

Я не могу упростить реально сложные вещи до "простого списка".

WH>Ведь никто так и не смог опровергнуть мои изначальные мысли.
WH>Более того ты в конце концов согласился с моим списком преимуществ статики.

Да, согласился.

WH>Но так и не назвал преимуществ динамики.

Я назвал, ты не услышал. На чём и предлагаю закрыть этот спор.

Здравствуйте, netch80, Вы писали:

N>Я утверждаю, что это твоё утверждение "что Go безопасный ложно" некорректно без указания, как именно мы определяем безопасность. И если тебе так хочется — да, я нахожу основание твоей... мнэээ... недоработки — в том, что ты не понимаешь, что такое безопасность, но хаешь чужое.
Почему это я не понимаю?
Прекрасно понимаю.
Безопасный это когда по памяти проехаться нельзя.
А в Go можно.

N>Я не могу упростить реально сложные вещи до "простого списка".
Ну я то смог.
Просто.
Конкретно.
Без всяких философий и километровых описаний предметных областей.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вторая причина попросту невалидна. Нет никакого эксклюзивного требования у динамики хранить все только на куче, можно спокойно хранить примитивы на стеке.

Нельзя. Чтобы их хранить на куче, надо заведомо знать их типы, т.е. в момент генерации нативного кода (в момент сборки самого интерпретатора). Ну или попробуй найти хоть в одном интерпретаторе такое.

Здравствуйте, vdimas, Вы писали:

ВВ>>Вторая причина попросту невалидна. Нет никакого эксклюзивного требования у динамики хранить все только на куче, можно спокойно хранить примитивы на стеке.
V>Нельзя. Чтобы их хранить на куче, надо заведомо знать их типы, т.е. в момент генерации нативного кода (в момент сборки самого интерпретатора).

Знать тип необязательно. Надо знать *размер*. Почувствуйте разницу, как говорится.

А вообще говоря и размер-то даже компилятору знать не надо. Компилятору, который генерирует байт-код, вообще должно быть до фени, где и как эти объекты хранятся. Его задача — записать Push да Pop, и все. Что там будет происходить во время исполнения этого байт-кода зависит от архитектуры виртуальной машины. То, что это динамика вносит лишь единственную коррективу — вместе со значением нужно хранить дескриптор типа. И это все. Остальное — часть логики декодирования байт-кода. Скажем, первый байт — тип. По нему для всех примитивов однозначно определяется размер. Остальное — дело техники. Упаковывать значения на стек можно аналогичным образом.

V>Ну или попробуй найти хоть в одном интерпретаторе такое.

Ну вот в моем интерпретаторе такое. И что-то мне кажется я Америку не открыл. Правда, есть ограничение — на стеке размещаются объекты размером не более 4х байт. Но это опять же мое индивидуальное ограничение для упрощения и ускорения декодирования байт-кода. Жесткой необходимости в таком нет.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну вот в моем интерпретаторе такое. И что-то мне кажется я Америку не открыл.

Надо быстродействие замерять, а не Америку открывать. Для целых чисел, например, обычно заводят статический массив ссылок из уже заранее размещенных на стеке боксированных чисел. Т.к. эти объекты-значения иммутабельны, они общие для всех. И парсер поступает примерно так:

IntegerObj BoxIntegerObj(int value) {
    if(value>=-N && value<N)
        return boxCache[value+N];

    return new IntegerObj(value);
}

Т.е. выделения памяти в куче не происходит для наиболее популярного диапазона чисел.

Ну и через виртуальные ф-ии вычисления работают обычно быстрее, чем через проверки флагов, ибо в общем случае там более одной проверки этих флагов получается, что значительно повышает шансы современным процам ошибиться в предсказаниях ветвления. На виртуальных ф-иях работает без ветвления по известному еще десятки инструкций назад адресу, т.е. вся выборка происходит в нормальном "плановом" режиме без сбоя конвейера. В общем, арифметические действия в динамике лучше делать на двойной диспетчеризации, чем на флагах.

ВВ>Правда, есть ограничение — на стеке размещаются объекты размером не более 4х байт. Но это опять же мое индивидуальное ограничение для упрощения и ускорения декодирования байт-кода. Жесткой необходимости в таком нет.

Да есть... ты начни покрывать полностью все сценарии, и увидишь, как много в итоге будет ветвлений в динамике. Опять же, как разместить на стеке целое число для среднестатистического интерпретатора, если это число динамически, в процессе обычного приращения в цикле, может менять внутренний (реальный) тип от байта, до BigInt?

Здравствуйте, vdimas, Вы писали:

ВВ>>Ну вот в моем интерпретаторе такое. И что-то мне кажется я Америку не открыл.
V>Надо быстродействие замерять, а не Америку открывать. Для целых чисел, например, обычно заводят статический массив ссылок из уже заранее размещенных на стеке боксированных чисел. Т.к. эти объекты-значения иммутабельны, они общие для всех. И парсер поступает примерно так:

Какой парсер? Кто заводит массив из ссылок из боксированных чисел?
Таки да, в Джаве, к примеру, есть кэш Integer в определенном диапазоне для ускорения конвертации в них обычных примитивов, вот только какое это имеет отношение к обсуждаемому вопросу? И причем тут *парсер*?

V>Ну и через виртуальные ф-ии вычисления работают обычно быстрее, чем через проверки флагов, ибо в общем случае там более одной проверки этих флагов получается, что значительно повышает шансы современным процам ошибиться в предсказаниях ветвления. На виртуальных ф-иях работает без ветвления по известному еще десятки инструкций назад адресу, т.е. вся выборка происходит в нормальном "плановом" режиме без сбоя конвейера. В общем, арифметические действия в динамике лучше делать на двойной диспетчеризации, чем на флагах.

Это к чему сказано? Причем тут вообще проверка флагов?

ВВ>>Правда, есть ограничение — на стеке размещаются объекты размером не более 4х байт. Но это опять же мое индивидуальное ограничение для упрощения и ускорения декодирования байт-кода. Жесткой необходимости в таком нет.
V>Да есть... ты начни покрывать полностью все сценарии, и увидишь, как много в итоге будет ветвлений в динамике.

Сценарии покрыты полностью.

V>Опять же, как разместить на стеке целое число для среднестатистического интерпретатора, если это число динамически, в процессе обычного приращения в цикле, может менять внутренний (реальный) тип от байта, до BigInt?

Инкремент означает: Поднялись значение переменной на стек, сняли со стека, увеличили, подняли на стек, записали в переменную. Даже если у нее размер меняется — это абсолютно безразлично.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Какой парсер? Кто заводит массив из ссылок из боксированных чисел?
ВВ>Таки да, в Джаве, к примеру, есть кэш Integer в определенном диапазоне для ускорения конвертации в них обычных примитивов, вот только какое это имеет отношение к обсуждаемому вопросу? И причем тут *парсер*?

Ну мы же об интерпретаторе говорим, а там парсер должен для начала как-то текст программы перевести во внутреннее представление. Понятное дело, что такое боксирование происходит не только в процессе парсинга, но и после любых арифметических действий.

V>>Ну и через виртуальные ф-ии вычисления работают обычно быстрее, чем через проверки флагов, ибо в общем случае там более одной проверки этих флагов получается, что значительно повышает шансы современным процам ошибиться в предсказаниях ветвления. На виртуальных ф-иях работает без ветвления по известному еще десятки инструкций назад адресу, т.е. вся выборка происходит в нормальном "плановом" режиме без сбоя конвейера. В общем, арифметические действия в динамике лучше делать на двойной диспетчеризации, чем на флагах.

ВВ>Это к чему сказано? Причем тут вообще проверка флагов?

При том что ты, насколько я понял, хранишь описание типа рядом с данными. Вот я и предположил, как вся схема работает. Ты же размер числа должен проверять как-то? А это очередная лишняя проверка, съедающая все преимущества расположения данных на стеке. Напомню, что это преимущество заключается в отсутствии необходимости выделять память из кучи. В остальном же, память, адресуемая по указателю стека, работает не быстрее любой другой памяти. Ну там если не брать во внимание промахи/попадания кеша, которые одинаково хорошо работают и для упомянутого массива закешированных боксированных значений.

ВВ>Инкремент означает: Поднялись значение переменной на стек, сняли со стека, увеличили, подняли на стек, записали в переменную. Даже если у нее размер меняется — это абсолютно безразлично.

Так у тебя свой стек что-ли (эмулируемый)? Или допускается изменение указателя стека после вызова ф-ий как в Форте? Тогда, извини, но адрес возврата непонятно где искать, то бишь для возвратов нужен будет другой стек. По любому, один из стеков надо эмулировать, что мы уже проходили. В итоге, ты изменяешь указатель стека — раз, не на константное значение (в отличие от использования ссылочных типов), а на значение, доставаемое по относительному адресу — два, один из стеков эмулируешь — три. В упор не вижу бенефитов, только лишние такты процессора. Хуже всего, если ты эмулируешь стек возвратов как в классике Форта, ибо это съедает все преимущества современной предвыборки инструкций. То бишь, выгоднее эмулировать стек данных.

В общем, замерять надо сначала, прежде чем на какой-то схеме останавливаться. По результатам моих экспериментов пятилетней давности быстрее всего себя в динамике на большом колв-е числовых типов показали вычисления на "типизации" с помощью двойной диспетчеризации. Таблицы виртуальных ф-ий они ведь тоже при частом использовании неплохо на кеш ложатся.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Это не первоклассные функции. Потом, извините, что за фигня? На ООП писать нельзя потому что слишком высокий порог вхождения, в функциональном стиле можно? Там порога вхождения нет что ли? Вы считаете, что ФП для новичков понятнее, чем ООП?

Более плавный переход из процедурного стиля, наверно?

Можно вообще начать писать в процедурном стиле на любом ФЯ, осваивая лямбды постепенно.

Здравствуйте, vdimas, Вы писали:

ВВ>>Какой парсер? Кто заводит массив из ссылок из боксированных чисел?
ВВ>>Таки да, в Джаве, к примеру, есть кэш Integer в определенном диапазоне для ускорения конвертации в них обычных примитивов, вот только какое это имеет отношение к обсуждаемому вопросу? И причем тут *парсер*?
V>Ну мы же об интерпретаторе говорим, а там парсер должен для начала как-то текст программы перевести во внутреннее представление. Понятное дело, что такое боксирование происходит не только в процессе парсинга, но и после любых арифметических действий.

Боксирование со стороны парсера какая-то отдельная тема совсем. Во-первых, она касается только литералов. Во-вторых, его также можно избежать. Например, в общем случае, если у вас есть литерал для Int64, вы же не будете создавать отдельную инструкцию, которая имеет в качестве аргумента аж 8-ми байтовую структуру? Например, он будет подниматься на стек как два Int32, из которых уже будет собираться Int64. Аналогично, к примеру, в MSIL. Т.е. ни парсеру, ни компилятору этот Int64 вообще не нужен. И то, как они обходятся с примитивами, есть их личное интимное дело, никак не связанное с исполнением кода.

ВВ>>Это к чему сказано? Причем тут вообще проверка флагов?

V>При том что ты, насколько я понял, хранишь описание типа рядом с данными. Вот я и предположил, как вся схема работает. Ты же размер числа должен проверять как-то? А это очередная лишняя проверка, съедающая все преимущества расположения данных на стеке.

Проверка размер числа == проверка флажка типа. Последнюю надо делать в любом случае, независимо от того, как хранится структура. На производительность проверка флажка влияет очень слабо. Если отключить проверки (считать, что все типы данных — это Int32) и запустить какой-нибудь нагрузочный тест типа сортировки пузырьком на 1000 элементов массива из Int32, то разница между версией с проверками и версией без проверки настолько мала, что ее можно списать в погрешность вычисления.

V>Напомню, что это преимущество заключается в отсутствии необходимости выделять память из кучи. В остальном же, память, адресуемая по указателю стека, работает не быстрее любой другой памяти. Ну там если не брать во внимание промахи/попадания кеша, которые одинаково хорошо работают и для упомянутого массива закешированных боксированных значений.

Главное преимущества, что при исполнении кода вида "2 + 2" мы не будет создавать в куче три абсолютно бесполезных временных объекта. Эти объекты я создам на стеке. Все, больше преимуществ нет, есть лишь недостатки (например, копирование).

ВВ>>Инкремент означает: Поднялись значение переменной на стек, сняли со стека, увеличили, подняли на стек, записали в переменную. Даже если у нее размер меняется — это абсолютно безразлично.

V>Так у тебя свой стек что-ли (эмулируемый)? Или допускается изменение указателя стека после вызова ф-ий как в Форте? Тогда, извини, но адрес возврата непонятно где искать, то бишь для возвратов нужен будет другой стек. По любому, один из стеков надо эмулировать, что мы уже проходили. В итоге, ты изменяешь указатель стека — раз, не на константное значение (в отличие от использования ссылочных типов), а на значение, доставаемое по относительному адресу — два, один из стеков эмулируешь — три. В упор не вижу бенефитов, только лишние такты процессора. Хуже всего, если ты эмулируешь стек возвратов как в классике Форта, ибо это съедает все преимущества современной предвыборки инструкций. То бишь, выгоднее эмулировать стек данных.

У меня лично свой стек, но мы начали говорить "в общем". Питон, насколько я знаю, использует стек Си. Смысл "типов по значению" здесь не в том, что они именно хранятся на стеке, это в общем случае неверно даже для языков со статической типизицией, скажем, нет гарантии, что при исполнении кода вида "int x = 1" значение x будет храниться именно на стеке. Смысл в том, что некоторые операции над примитивами становятся дешевле.

V>В общем, замерять надо сначала, прежде чем на какой-то схеме останавливаться. По результатам моих экспериментов пятилетней давности быстрее всего себя в динамике на большом колв-е числовых типов показали вычисления на "типизации" с помощью двойной диспетчеризации. Таблицы виртуальных ф-ий они ведь тоже при частом использовании неплохо на кеш ложатся.

Я замерял. "Все в куче" — медленнее (ок. 10-15%) ну и память соответственно расходуется больше. Вариант с виртуальными функциями реализуем только в случае, если "все в куче". Опять же, я не видел большой разницы в производительности даже без проверок вообще, замерялось в т.ч. и на старой машине, сомневаюсь, что виртуальные функции тут неожиданно взлетят.

Здравствуйте, vdimas, Вы писали:

V>Более плавный переход из процедурного стиля, наверно?

V>Можно вообще начать писать в процедурном стиле на любом ФЯ, осваивая лямбды постепенно.

Я не понимаю, что мешает писать в процедурном стиле на дотнете. Меня вообще слегка заклинило в начале этой дискуссии, как раз ASP.NET-то максимально "scripty". Там даже в процедурном стиле можно не писать, а писать в макаронном. Никаких классов объявлять не нужно, лепите код в <% %> по аналогии с PHP — и все. А VB.NET, кстати, умеет и динамическую типизацию. Да и шарп сейчас тоже.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Проверка размер числа == проверка флажка типа. Последнюю надо делать в любом случае, независимо от того, как хранится структура. На производительность проверка флажка влияет очень слабо. Если отключить проверки (считать, что все типы данных — это Int32) и запустить какой-нибудь нагрузочный тест типа сортировки пузырьком на 1000 элементов массива из Int32, то разница между версией с проверками и версией без проверки настолько мала, что ее можно списать в погрешность вычисления.

Это ты или как-то неправильно меряешь, или у тебя всего пару числовых типов, или остальные затраты на исполнение каждого цикла интерпретатора столь велики, что одна проверка этого флага не заметна. Сравни на нативном варианте, там минимум вдвое разница.

ВВ>Главное преимущества, что при исполнении кода вида "2 + 2" мы не будет создавать в куче три абсолютно бесполезных временных объекта. Эти объекты я создам на стеке. Все, больше преимуществ нет, есть лишь недостатки (например, копирование).

Для случая 2+2 ни одного временного объекта создано не будет, по причине наличия того самого иммутабельного кеша.

ВВ>У меня лично свой стек, но мы начали говорить "в общем".

Ну так это стало понятно очень быстро...

ВВ>Питон, насколько я знаю, использует стек Си.

А теперь по русски,если не сложно.

ВВ>Смысл "типов по значению" здесь не в том, что они именно хранятся на стеке, это в общем случае неверно даже для языков со статической типизицией, скажем, нет гарантии, что при исполнении кода вида "int x = 1" значение x будет храниться именно на стеке. Смысл в том, что некоторые операции над примитивами становятся дешевле.

Ты прав, смысл в использовании аллокатора памяти стекового типа, который просто двигает текущую планку на нужное кол-во байт во время выделения/освобождения. К тому же, с гарантией доступа лишь из одного потока. И существуют устойчивые заблуждения насчет эффективности этого аллокатора в чистом виде. Я хочу сказать, что для этой разновидности аллокаторов эмулировать стек в том самом чистом виде — это удорожать операции, ибо такая эмуляция приводит к ограничению/требованию последовательного доступа к своим элементам, что на примере того же Форта или ассемблерных инструкций кривого x86 показывет, как много во время простых вычислений происходит дополнительных операций, связанных лишь с ротацией данных в стеке. Для настоящей дешевизны динамических операций надо "чистый" стековый аллокатор допиливать до паскалевской разновидности, тогда при аналогичных затратах на выделение/освобождение, мы не будем ограниченны навязанной упорядоченностью данных, как в случае стека. И да, условие гарантии однопоточности доступа к операциям выделения/освобождения должны прилагаться, как и для "настоящего" стека.

V>>В общем, замерять надо сначала, прежде чем на какой-то схеме останавливаться. По результатам моих экспериментов пятилетней давности быстрее всего себя в динамике на большом колв-е числовых типов показали вычисления на "типизации" с помощью двойной диспетчеризации. Таблицы виртуальных ф-ий они ведь тоже при частом использовании неплохо на кеш ложатся.

ВВ>Я замерял. "Все в куче" — медленнее (ок. 10-15%) ну и память соответственно расходуется больше. Вариант с виртуальными функциями реализуем только в случае, если "все в куче". Опять же, я не видел большой разницы в производительности даже без проверок вообще, замерялось в т.ч. и на старой машине, сомневаюсь, что виртуальные функции тут неожиданно взлетят.

Я не мерял насчет "кучи", т.е. выделение/освобождение не участвовало, замерял только вычисления в случае проверки флагов для 4-х числовых типов и через двойную диспетчеризацию. Для случая проверки фажков там в среднем 5 проверок надо для вывода типа результата, или же 2 вызова виртуальной ф-ии. Опять же, для вызова виртуальных ф-ий наличие объекта на стеке не нужно. Если же ты в качестве "подложки" использовал что-то вроде дотнета (закралось подозрение из-за твоего утверждения насчет кучи и виртуальных ф-ий), то там надо генерить сразу дотнетный байт-код, а не свой. То бишь, мы непонятно что обсуждали.

Здравствуйте, WolfHound, Вы писали:

WH>Что тесты? Они и близко не так эффективны как компилятор.
WH>Ибо компилятор гарантированно заглянет во все уголки кода.

Ты спросил что делать. "не так эффективны" — этим мы платим за гибкость.

Здравствуйте, vdimas, Вы писали:

V>Это ты или как-то неправильно меряешь, или у тебя всего пару числовых типов, или остальные затраты на исполнение каждого цикла интерпретатора столь велики, что одна проверка этого флага не заметна. Сравни на нативном варианте, там минимум вдвое разница.

Числовых типов не пару, но проверки идут в порядке, так сказать, частоты использования: int, float, long, double. Самыми медленными будут проверки для типов, которые создаются в куче, самыми быстрыми — для стековых. В итоге арифметика с int — это всего одна проверка.
И что есть нативный вариант и как мне с ним сравнивать? Вернее, насколько эти результаты будут показательны? Я одно могу сказать точно, если у нас в каких-то условиях вариант Х оказывается быстрее, чем У, то это не значит, что это воспроизведется и в других условиях.
Простейший вариант — сравнить скорость арифметики для double с и без проверок.

Сравнить — опять же несложно. Такой тест подойдет?

let ITER = 1000*1000;

for (i to ITER) {
  let d = .5d + i :> double; //конвертируем int в double
}

Запускаю на древнем целероне, поэтому цифры страшные:

С проверками: 0.875
Без проверок: 0.859

Double один из самых тяжелых типов при сложении, тяжелее только списки/массивы. Но "тяжелость" double еще объясняется и тем, что любая арифметика с ними — создание объектов на куче.

Скажешь высокие затраты на исполнение цикла? Да, согласен. Но в принципе это естественно, что они высокие. Это интерпретатор. Поэтому я и высказываю сомнение, что от "нативного" теста тут может быть хоть какой-то прок.

Да, "референсный" тест — такой код на JScript:

for (var i = 0; i < 1000*1000; i++) {
  var r = 10 + 20;
}

Выполняется за:

0.843

(А если 1000*1000 кэшировать в переменную, то медленнее

). Это я к тому, что тестовая машина реально медленная. Но здесь я интерпретатор установить не могу сейчас.

ВВ>>Главное преимущества, что при исполнении кода вида "2 + 2" мы не будет создавать в куче три абсолютно бесполезных временных объекта. Эти объекты я создам на стеке. Все, больше преимуществ нет, есть лишь недостатки (например, копирование).
V>Для случая 2+2 ни одного временного объекта создано не будет, по причине наличия того самого иммутабельного кеша.

Ну ради бога, 222+666. Важна суть. Иммутабельный кэш, как ты понимаешь, весьма ограниченного размера. В Джаве AFAIK там значения до 128.

ВВ>>Питон, насколько я знаю, использует стек Си.
V>А теперь по русски,если не сложно.

А что непонятно? Питон не эмулирует стек, использует стек языка, на котором написан.

ВВ>>Смысл "типов по значению" здесь не в том, что они именно хранятся на стеке, это в общем случае неверно даже для языков со статической типизицией, скажем, нет гарантии, что при исполнении кода вида "int x = 1" значение x будет храниться именно на стеке. Смысл в том, что некоторые операции над примитивами становятся дешевле.

V>Ты прав, смысл в использовании аллокатора памяти стекового типа, который просто двигает текущую планку на нужное кол-во байт во время выделения/освобождения. К тому же, с гарантией доступа лишь из одного потока. И существуют устойчивые заблуждения насчет эффективности этого аллокатора в чистом виде. Я хочу сказать, что для этой разновидности аллокаторов эмулировать стек в том самом чистом виде — это удорожать операции, ибо такая эмуляция приводит к ограничению/требованию последовательного доступа к своим элементам, что на примере того же Форта или ассемблерных инструкций кривого x86 показывет, как много во время простых вычислений происходит дополнительных операций, связанных лишь с ротацией данных в стеке. Для настоящей дешевизны динамических операций надо "чистый" стековый аллокатор допиливать до паскалевской разновидности, тогда при аналогичных затратах на выделение/освобождение, мы не будем ограниченны навязанной упорядоченностью данных, как в случае стека. И да, условие гарантии однопоточности доступа к операциям выделения/освобождения должны прилагаться, как и для "настоящего" стека.

Я уже что-то запутался. Можно поподробнее что есть "паскалевая" разновидность аллокатора?
А эмуляция стека хороша хотя бы безопасностью — если интерператор вылетит, то хосту не сорвет крышу.
По поводу многопоточностью тоже не все ясно — у каждого потока должен быть свой отдельный стек, как и в случае с "настоящим" стеком.

V>>>В общем, замерять надо сначала, прежде чем на какой-то схеме останавливаться. По результатам моих экспериментов пятилетней давности быстрее всего себя в динамике на большом колв-е числовых типов показали вычисления на "типизации" с помощью двойной диспетчеризации. Таблицы виртуальных ф-ий они ведь тоже при частом использовании неплохо на кеш ложатся.

ВВ>>Я замерял. "Все в куче" — медленнее (ок. 10-15%) ну и память соответственно расходуется больше. Вариант с виртуальными функциями реализуем только в случае, если "все в куче". Опять же, я не видел большой разницы в производительности даже без проверок вообще, замерялось в т.ч. и на старой машине, сомневаюсь, что виртуальные функции тут неожиданно взлетят.

V>Я не мерял насчет "кучи", т.е. выделение/освобождение не участвовало, замерял только вычисления в случае проверки флагов для 4-х числовых типов и через двойную диспетчеризацию. Для случая проверки фажков там в среднем 5 проверок надо для вывода типа результата, или же 2 вызова виртуальной ф-ии. Опять же, для вызова виртуальных ф-ий наличие объекта на стеке не нужно. Если же ты в качестве "подложки" использовал что-то вроде дотнета (закралось подозрение из-за твоего утверждения насчет кучи и виртуальных ф-ий), то там надо генерить сразу дотнетный байт-код, а не свой. То бишь, мы непонятно что обсуждали.

Мы обсуждали возможность/невозможность создание переменных на стеке в динамике. В общем случае — такая возможность есть. Разница со статикой в следующем:
— необходимость иметь дескриптор типа
— ограниченные возможности расчету стека компилятором (но они есть, если действовать по моей модели — либо значение до 4 байт размером, либо указатель), то все вообще очень просто.

Здравствуйте, Mamut, Вы писали:

M>Ну то же самое можно и в C# сделать

Дело не в том, что в C# можно сделать то же самое. Дело в том, что в C# можно сделать иначе. Да и в Яве можно сделать иначе.

M>Особо других мейнстримных и не осталось

А что, в мейнстриме есть динамические языки кроме PHP? Ну, разве что, можно, с некоторой натяжкой, Питон посчитать.

M>Ага. То есть в случае с C# все ранво перекладывается на плечи программиста. Чтобы не забыл реализовать Maybe, чтобы не забыл его вернуть и т.п. То есть чуда по любому нет

Реализация, разумеется, перекладывается на плечи программиста. С помощью статической типизации можно только напомнить о переложении на плечи и, в какой-то степени, это переложение форсировать.
Предположим, что у нас есть функция Foo, которая может вернуть что-то, например элемент из коллекции, если он в ней есть, или не вернуть ничего, например, если искомого элемента в коллекции нет. У программиста, который написал Foo проблема: дать гарантию того, что он всегда вернет результат он не может. Другой программист, использующий Foo в своем коде, должен проверить, вернула ли она что-то или нет. Как первый программист может делегировать эту ответственность второму? В случае динамической типизации только описать ситуацию в документации. В случае статической типизации программист-1 может использовать Maybe и компилятор напомнит программисту-2, что нужно проверить возвращаемый результат.
Как сделать так, чтобы компилятор напомнил программисту-1 о том, чтоб он не забыл вернуть Maybe? Для этого в стат языках есть другие чудеса. В C# такое чудо называется "интерфейс". Программист-3 может написать

public interface IBar<T>
{
    Maybe<T> Foo();
}

И теперь компилятор напомнит программисту-2, пишущему реализацию Foo, о том, что нужно вернуть Maybe.
Как тут поможет динамика?

M>Зачем же всеми средствами

Вот и я удивляюсь: зачем?

M>Почти во всех — это каких?

Мне перечислить все языки с параметрическим полиморфизмом? На самом деле, все это можно сделать в языках и без него, но решение получится слишком тяжеловесным, никто им пользоваться не будет.
Динамическая типизация потому и появилась, что на заре развития языков программирования полиморфный код мог быть только динамическим. И весь прогресс статической типизации — это возможность писать все более полиморфный код, который при этом статически проверяется.

M>Ну мы то прекрасно знаем, что аналогии всегда неверны

Аналогии могут быть верны или не верны. Это доказательство по-аналогии плохо. Но я тут ничего не доказываю, чтобы доказывать или опровергать — нужно сформулировать то, что требует доказательства или опровержения. А "статика то — статика се"- это не формулировка. Аналогию же, а точнее шаблон для постоения аналогичных по логике суждений, я привел в иллюстративных целях.

M>Что предлагает язык, то и использую.

Нет, никакими средствами для статического контроля вы не воспользовались — наоборот, воспользовались средствами для избегания статического контроля. Сначала перенесли все проверки в рантайм, получив динамически типизированную программу, а потом объявили, что это недостатки статики. Но ведь это недостатки динамики.

M>Скажет incompatible types

Правильно скажет. А вы говорили — компилятор молчит.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Для случая проверки фажков там в среднем 5 проверок надо для вывода типа результата, или же 2 вызова виртуальной ф-ии. Опять же, для вызова виртуальных ф-ий наличие объекта на стеке не нужно.

А слона-то я не увидел

У меня вывод типа результата осуществляется через специальную таблицу "соответствия типов". А потом уже идет проверка флажка, который вернулся из этой таблицы. Т.е. не тип проверяется. Выглядит это так:

private static int[,] opAffinity = 
{
 //ERR  UNI  INT  REA  BYT  CHR  LNG  DBL  STR  LST  ARR  TUP  REC  FUN  OBJ  LAZ  SEQ  MOD
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //ERR
 { ___, UNI, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //UNI
 { ___, ___, INT, REA, ___, ___, LNG, DBL, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //INT
 { ___, ___, REA, REA, ___, ___, ___, DBL, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //REA
 { ___, ___, ___, ___, BYT, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //BYT
 { ___, ___, ___, ___, ___, CHR, ___, ___, STR, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //CHR
 { ___, ___, LNG, ___, ___, ___, LNG, DBL, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //LNG
 { ___, ___, DBL, DBL, ___, ___, DBL, DBL, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //DBL
 { ___, ___, ___, ___, ___, STR, ___, ___, STR, ___, ___, ___, ___, ___, ___, ___, ___, ___ }, //STR
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, LST, ___, ___, ___, ___, ___, ___, ___, ___ }, //LST
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ARR, ___, ___, ___, ___, ___, ___, ___ }, //ARR
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, TUP, ___, ___, ___, ___, ___, ___ }, //TUP
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, REC, ___, ___, ___, ___, ___ }, //REC
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, FUN, ___, ___, ___, ___ }, //FUN
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, OBJ, ___, ___, ___ }, //OBJ
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, LAZ, ___, ___ }, //LAZ
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, SEQ, ___ }, //SEQ
 { ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, ___, MOD }, //MOD
};

Соответственно, нужно узнать вывести тип (да и проверить допустимость операции):

var aff = opAffinity[left.Type, right.Type];

if (aff.Type == INT) {
  ...
}
...

Т.е. для int делается всего одна проверка, а не 5.

Здравствуйте, lomeo, Вы писали:

L>Ты спросил что делать. "не так эффективны" — этим мы платим за гибкость.
Осталось понять в каком там месте гибкость.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, WolfHound, Вы писали:

V>>А чем вирус принципиально отличается, скажем, от драйвера?
WH>Тем что драйвер не устанавливается через дыру в парсере JPEG.

Подписанный драйвер может устанавливаться молча через любую существующую дыру (только если политику специально не подкрутишь).

Например, для win7 народ часто включает флажок, чтобы винда не дергала каждый раз, когда нужны админские права для некоего действия, а у пользователя эти права уже есть. То бишь, если включен популярный вот этот режим для юзверей из админской группы, то только проблемы с подписью сертификата могут помочь увидеть попытку установки левого драйвера. С другой стороны, обязательное требование подписи дров к win7 x64 делает невозможным использование ряда ранее полезных бесплатных утилит.

В общем, вопрос открыт и у меня пока нет мнения. Дело ведь не обязательно в дыре парсера JPEG.. например, руткиты сегодня зачастую втюхиваются в нагрузку к полезным бесплатным программам (не только в нагрузку ко всяким варезным keygen). Похоже, только высокая цена сертификатов да ужесточение преследования за распространение вирусов и шпионов могут хоть как-то повлиять, но оба способа — болезненная палка о двух концах.

Даже вот эти по-умолчанию всплывающие окна с требованием подтвержденпия на каждый чих в win7 — по-сути роспись в беспомощности. Средний юзер всё-равно особо не всматривается, т.к. не шарит, и давит "yes" по привычке.

Здравствуйте, Klapaucius, Вы писали:

K>А что, в мейнстриме есть динамические языки кроме PHP? Ну, разве что, можно, с некоторой натяжкой, Питон посчитать.

С некоторой натяжкой и руби можно посчитать.
Раньше были кучи бейсиков, потом VB и Smalltalk.

K>Как сделать так, чтобы компилятор напомнил программисту-1 о том, чтоб он не забыл вернуть Maybe? Для этого в стат языках есть другие чудеса. В C# такое чудо называется "интерфейс". Программист-3 может написать

Интерфейсы ничем динамике ни противоречат, вот в питон недавно ввели http://www.python.org/dev/peps/pep-3119/ с другой стороны в статике вполне живет безинтерфейсная структурная типизация (записи и объекты OCаml).

Здравствуйте, WolfHound, Вы писали:

WH>Осталось понять в каком там месте гибкость.

Тотальная полиморфность.
Упрощение и ускорение прототипирования за счет отказа от фиксированных типов данных.
Возможность горячей перезагрузки даже небольших кусков кода.
Гораздо большая гибкость в кодогенерации, возможность делать ее сразу в целевом языке или высокоуровневом AST
Более гибкое метапрограммирование (lisp) позволяющее писать код который пишет код который ...
Доступность блоков компилятора и интерпретатора в рантайме позволяющее делать управляемую кастомную интерпретацию.
Ну и конечно самомодифицирующийся код

Здравствуйте, Klapaucius, Вы писали:

С одной стороны Maybe удобен, с другой стороны, позволит протаскивать null достаточно далеко, чтобы потерять место, где он возник. ИМХО, чем раньше будет проверка результата, тем лучше.

Можно использовать некий хелпер NotNull:

public class NotNull<T> where T : class 
{
    T _value;

    private NotNull(T value) {
        if(value == null)
            throw new ArgumentNullException();

        _value = value;
    }

    public static implicit operator T(NotNull<T> notNullValue) {...}
    public static implicit operator NotNull<T>(value) {...}
}


public interface IBar<T>
{
    NotNull<T> Foo();
}

Одно неприятно: из-за дефолтного конструктора value-типов надежная реализация может быть лишь на ref-типах.

Здравствуйте, FR, Вы писали:

FR>Тотальная полиморфность.
Зачем?

FR>Упрощение и ускорение прототипирования за счет отказа от фиксированных типов данных.
В языках с выводом типов такой проблемы нет.
А учитывая что статическая типизация помогает рефакторить то кто кого уделает далеко не так однозначено как тебе кажется.

FR>Возможность горячей перезагрузки даже небольших кусков кода.
Ну это я и статику так скомпилировать могу.
Накладных расходов один jmp на вызов функции.

FR>Гораздо большая гибкость в кодогенерации, возможность делать ее сразу в целевом языке или высокоуровневом AST
Немерле.

FR>Более гибкое метапрограммирование (lisp) позволяющее писать код который пишет код который ...
Ты блин не поверишь...

FR>Доступность блоков компилятора и интерпретатора в рантайме позволяющее делать управляемую кастомную интерпретацию.
И снова немерле.

FR>Ну и конечно самомодифицирующийся код

Зачем?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Теперь — с точностью до наоборот. Предкомпиляция по-прежнему доступна. Но вот рекламируется теперь именно динамическая компиляция как тот же самый "тру" путь. И именно она является "моделью по умолчанию", которую поддерживает студия. Если она вообще еще поддерживает старый коде бехаинд с предкомпиляцией — в чем я сомневаюсь, если честно.

Во-первых, доступен по-прежнему. Во-вторых, логика теперь уходит со "скриптов" страниц в предкомпиленные либы. А оставшееся и компилить смысла особого не имеет, ибо компиляция — это был способ защиты кода. Защитить разметку-то не получится по-любому.

Здравствуйте, WolfHound, Вы писали:

FR>>Тотальная полиморфность.
WH>Зачем?

Например когда старый код должен работать с новыми данными.
В том же прототипировании.

FR>>Упрощение и ускорение прототипирования за счет отказа от фиксированных типов данных.
WH>В языках с выводом типов такой проблемы нет.

Есть, я сейчас одновременно пишу на динамике и очень жесткой статике, прототипирование в динамике заметно быстрее и удобней.
Притом питон менее выразительный язык чем OCaml.

WH>А учитывая что статическая типизация помогает рефакторить то кто кого уделает далеко не так однозначено как тебе кажется.

При прототипировании основной вид рефакторинга выкидывание неудачного кода.

FR>>Возможность горячей перезагрузки даже небольших кусков кода.
WH>Ну это я и статику так скомпилировать могу.
WH>Накладных расходов один jmp на вызов функции.

Наверно ты можешь и левой пяткой правое ухо чесать, но пока никто так в распространенных статических языках не делает можем
считать что этого нет.

FR>>Гораздо большая гибкость в кодогенерации, возможность делать ее сразу в целевом языке или высокоуровневом AST
WH>Немерле.

Не совсем, метапрограммирование не равно кодогенерации.
Хотя тут да Немерли вполне годен.

FR>>Более гибкое метапрограммирование (lisp) позволяющее писать код который пишет код который ...
WH>Ты блин не поверишь...

Немерле этого не позволяет, я же специально повторил несколько раз.

FR>>Доступность блоков компилятора и интерпретатора в рантайме позволяющее делать управляемую кастомную интерпретацию.
WH>И снова немерле.

Тоже нет, Немерли не умеет интерпретировать байт код и даже не умеет его инструментировать как некторые тулзы для явы,
это на нем конечно можно сделать, но фактически вручную написав полноценный интерпретатор.
Тот же питон из коробки позволяет инструментировать как байт код так и AST и делать, как такие примитивные вещи
http://code.activestate.com/recipes/286134-safe-expression-evaluation/ так и подобные этому
http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation

FR>>Ну и конечно самомодифицирующийся код

WH>Зачем?

Языки не позволяющие писать самомодифицирующийся код ущербны

Здравствуйте, vdimas, Вы писали:

ВВ>>Теперь — с точностью до наоборот. Предкомпиляция по-прежнему доступна. Но вот рекламируется теперь именно динамическая компиляция как тот же самый "тру" путь. И именно она является "моделью по умолчанию", которую поддерживает студия. Если она вообще еще поддерживает старый коде бехаинд с предкомпиляцией — в чем я сомневаюсь, если честно.
V>Во-первых, доступен по-прежнему. Во-вторых, логика теперь уходит со "скриптов" страниц в предкомпиленные либы. А оставшееся и компилить смысла особого не имеет, ибо компиляция — это был способ защиты кода. Защитить разметку-то не получится по-любому.

Защиты от кого?

Все ж на сервере лежит. К тому же компиляция в шитый код — это какая-то странная защита. Достал рефлектор, посмотрел.

Здравствуйте, FR, Вы писали:

FR>>>Более гибкое метапрограммирование (lisp) позволяющее писать код который пишет код который ...
WH>>Ты блин не поверишь...

FR>Немерле этого не позволяет, я же специально повторил несколько раз.

Покажи плз задачу где нужно писать код который пишет код (макрос высшего порядка)?

FR>>>Доступность блоков компилятора и интерпретатора в рантайме позволяющее делать управляемую кастомную интерпретацию.
WH>>И снова немерле.

FR>Тоже нет, Немерли не умеет интерпретировать байт код и даже не умеет его инструментировать как некторые тулзы для явы,
FR>это на нем конечно можно сделать, но фактически вручную написав полноценный интерпретатор.

Опять же, какие задачи решаются столь изощренным способом?

FR>Тот же питон из коробки позволяет инструментировать как байт код так и AST и делать, как такие примитивные вещи
FR>http://code.activestate.com/recipes/286134-safe-expression-evaluation/ так и подобные этому
FR>http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation

Актуальность подобных вещей в .NET мне видится несколько сомнительной...

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Защиты от кого?

Все ж на сервере лежит. К тому же компиляция в шитый код — это какая-то странная защита. Достал рефлектор, посмотрел.

Дык, от самого себя не защищают. Защищают коробочные или заказные продукты. И после хорошего обфускатора дешевле будет с 0-ля самому написать, чем пытаться восстанавливать.

Здравствуйте, VladD2, Вы писали:

L>>Да не, не стоит, ты уже достаточно продемонстрировал степень владения предметом.

VD>С удовольствием выслушаю развенчание моих слов.

Просто имелось ввиду, что для средних расчетов на Матлабе, время проца, затрачиваемое на собственно интерпретацию скрипта, обычно ничтожно мало. Все базовые операции с матрицами и куча прикладных, включая АПИ LAPACK, реализованы рантаймом в максимально оптимизированном виде, и скрипт тут является эдаким высокоуровневым клеем.

Даже способ задания циклов прямо провоцирует на использование векторных (то бишь пакетных, в сравнении с пошаговой итерацией) вычислений.

Банальный пример подсчет суммы ряда:
задается вектор индексов 1:N, затем применяется некая формула к этому вектору, получая за один вызов другой вектор, где каждый член — это i-тый элемент последовательности. А затем вызов sum() для элементов вектора. Итого, даже для N=мильон, в скрипте у нас всего 3 операции (если встроенные ф-ии вызывались).

Ну и, самое главное, конкурентов на сегодня матлабу нет и близко, учитывая все плагины к нему, как расчетные, так и моделирующие (Symulink), плагины для переноса вычислений на GPU (без какого-либо изменения уже работающего кода). В общем, ближайшие конкуренты отстают даже не на 10 и не на 20 лет, а навсегда. Поэтому ирония насчет калькулятора неуместна.

Обязательно прочти хотя бы первые несколько строк описания одного из скромных пакетов: http://www.mathworks.com/help/toolbox/polyspace/c_ug/brzsbhd-1.html#bsoy0ma-1

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, vdimas, Вы писали:

V>>Более плавный переход из процедурного стиля, наверно?

V>>Можно вообще начать писать в процедурном стиле на любом ФЯ, осваивая лямбды постепенно.

ВВ>Я не понимаю, что мешает писать в процедурном стиле на дотнете.

Объявление и вызов "свободной" процедуры переусложнены. Это нужен некий класс-контейнер, в нем не забыть написать public static. Затем вызвать процедуру через упоминание контейнера.. бр-р. Откуда программист "процедурного стиля" должен знать, что означает static? Крайне неудачный keyword.

ВВ>А VB.NET, кстати, умеет и динамическую типизацию.

Этот язык вообще недооценен. Покрывая по возможностям C#, имеет еще кучу сверху: аргументы по-молчанию, именованные аргументы, динамику в "человеческом" синтаксисе, мега-конструкцию with, совместимость делегатов с одинаковой сигнатурой (и даже совместимость делегатов с "похожей", т.е. приводимой сигнатурой), более удобная и естественная конверсия типов в строку и обратно, и т.д. и т.п. Все это впихивают и в C# в последних версиях, но в VB оно было всегда.

Отношение к языку, выходит, зависит не столько от набора фич, сколько от синтаксиса.

http://msdn.microsoft.com/en-us/library/bb531336.aspx
http://msdn.microsoft.com/en-us/library/bb531253.aspx

От самого истинного Basic там только название осталось. В остальном это мощный современный ЯП, который постоянно умудряется быть значительно впереди С#. А название этого языка портит ему карму.

Здравствуйте, vdimas, Вы писали:

V>Объявление и вызов "свободной" процедуры переусложнены. Это нужен некий класс-контейнер, в нем не забыть написать public static. Затем вызвать процедуру через упоминание контейнера.. бр-р. Откуда программист "процедурного стиля" должен знать, что означает static? Крайне неудачный keyword.

ASP.NET поддерживает программирование в ASP-стиле. Никаких классов можно вообще не писать. Даже методы можно не писать.

Здравствуйте, FR, Вы писали:

FR>Например когда старый код должен работать с новыми данными.
FR>В том же прототипировании.
Если код должен работать с разными типами то есть генерики.
Если просто с другим типом то вывод типов наше все.
В чем проблема то?

FR>Есть, я сейчас одновременно пишу на динамике и очень жесткой статике, прототипирование в динамике заметно быстрее и удобней.
FR>Притом питон менее выразительный язык чем OCaml.
Уж не знаю что ты там такое прототипируешь но я сейчас сам пишу то что никто раньше не писал.
http://code.google.com/p/nemerle/source/browse/#svn/nemerle/trunk/snippets/peg-parser
Одно сплошное прототипирование.

WH>>А учитывая что статическая типизация помогает рефакторить то кто кого уделает далеко не так однозначено как тебе кажется.
FR>При прототипировании основной вид рефакторинга выкидывание неудачного кода.
У тебя.

FR>Наверно ты можешь и левой пяткой правое ухо чесать, но пока никто так в распространенных статических языках не делает можем считать что этого нет.
VC++ умеет edit&continue
Так что есть.

FR>Не совсем, метапрограммирование не равно кодогенерации.
Угу. Метапрограммирование гораздо лучше чем возьня с текстом.

FR>Немерле этого не позволяет, я же специально повторил несколько раз.
Я могу при разработке макроса использовать макросы.
Я могу в генерируемом коде использовать макросы.
Я могу макросом сгенерировать макрос. Хотя не понятно зачем это может быть нужно.

FR>Тоже нет, Немерли не умеет интерпретировать байт код и даже не умеет его инструментировать как некторые тулзы для явы, это на нем конечно можно сделать, но фактически вручную написав полноценный интерпретатор.
Инструментирование байткода это для лузеров которые не могут трансформировать АСТ.

FR>Тот же питон из коробки позволяет инструментировать как байт код так и AST и делать, как такие примитивные вещи
FR>http://code.activestate.com/recipes/286134-safe-expression-evaluation/
Не проблема ни разу.

FR>http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation
В статически типизированном языке это не нужно.

FR>>>Ну и конечно самомодифицирующийся код

WH>>Зачем?

FR>Языки не позволяющие писать самомодифицирующийся код ущербны

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, vdimas, Вы писали:

L>>>Да не, не стоит, ты уже достаточно продемонстрировал степень владения предметом.

VD>>С удовольствием выслушаю развенчание моих слов.

V>Просто имелось ввиду, что для средних расчетов на Матлабе, время проца, затрачиваемое на собственно интерпретацию скрипта, обычно ничтожно мало. Все базовые операции с матрицами и куча прикладных, включая АПИ LAPACK, реализованы рантаймом в максимально оптимизированном виде, и скрипт тут является эдаким высокоуровневым клеем.

V>Даже способ задания циклов прямо провоцирует на использование векторных (то бишь пакетных, в сравнении с пошаговой итерацией) вычислений.

V>Банальный пример подсчет суммы ряда:
V>задается вектор индексов 1:N, затем применяется некая формула к этому вектору.... Поэтому ирония насчет калькулятора неуместна.

Да более чем уместна. Во-первых не всегда обойтись встроенными функциями, а не встроенные будут вызываться для каждой ячейки. Во-вторых, не все вычисления связанны с огромными массивами. В третьих, использование оптимизированных библиотек (в том числе перекладывающих вычисление на GPU) никто не запрещает в любом языке. Дон Реба, как раз и писал о том, что он так и поступает.

V>Обязательно прочти хотя бы первые несколько строк описания одного из скромных пакетов: http://www.mathworks.com/help/toolbox/polyspace/c_ug/brzsbhd-1.html#bsoy0ma-1

И что я тут могу увидеть что как-то влияло бы на мои слова?

Вот Москаль (один из создателей Немерла) сейчас работает над VCC (верифицируемым компилятором С) который пишется в основном на F# (т.е. управляемом коде) и занимается проверкой корректности многопоточных С-программ. VCC использовался при разработке виртуализации в винде, например, то есть реально используется на практике.

И что мы этим доказали? Разве что то, что одни и те же задачи можно решать разными средствами.

Здравствуйте, VladD2, Вы писали:

VD>Да более чем уместна. Во-первых не всегда обойтись встроенными функциями, а не встроенные будут вызываться для каждой ячейки.

Что характерно, если своя ф-ия представляет из себя просто арифметическое выражение (формулу), работает ну очень быстро.

VD>Во-вторых, не все вычисления связанны с огромными массивами.

А где данных немного, там эффективность и обсуждать незачем.

Здравствуйте, hardcase, Вы писали:

FR>>Немерле этого не позволяет, я же специально повторил несколько раз.

H>Покажи плз задачу где нужно писать код который пишет код (макрос высшего порядка)?

Я вообще с трудом могу показать задачу где вообще необходимы макросы (исключая языки с примитивным синтаксисом типа лиспа и форта),
даже более того считаю что синтаксического препроцессора типа Camlp4
для статических языков и метаклассов для динамических более чем достаточно для метапрограммирования в высокоуровневых
языках.

FR>>Тоже нет, Немерли не умеет интерпретировать байт код и даже не умеет его инструментировать как некторые тулзы для явы,
FR>>это на нем конечно можно сделать, но фактически вручную написав полноценный интерпретатор.

H>Опять же, какие задачи решаются столь изощренным способом?

Это ничем не изощреннее чем макросы немерли.
Задачи такие же редкие как и для макросов. Примеры же ниже есть.

FR>>Тот же питон из коробки позволяет инструментировать как байт код так и AST и делать, как такие примитивные вещи
FR>>http://code.activestate.com/recipes/286134-safe-expression-evaluation/ так и подобные этому
FR>>http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation

H>Актуальность подобных вещей в .NET мне видится несколько сомнительной...

Возможно, но в NET кодогенерация вполне используется.

Здравствуйте, WolfHound, Вы писали:

FR>>Например когда старый код должен работать с новыми данными.
FR>>В том же прототипировании.
WH>Если код должен работать с разными типами то есть генерики.
WH>Если просто с другим типом то вывод типов наше все.
WH>В чем проблема то?

Проблема в перекомпиляции.

WH>Уж не знаю что ты там такое прототипируешь но я сейчас сам пишу то что никто раньше не писал.
WH>http://code.google.com/p/nemerle/source/browse/#svn/nemerle/trunk/snippets/peg-parser
WH>Одно сплошное прототипирование.

У меня сомнения в том что ты придумал PEG парсер.

FR>>При прототипировании основной вид рефакторинга выкидывание неудачного кода.
WH>У тебя.

Не только.

FR>>Наверно ты можешь и левой пяткой правое ухо чесать, но пока никто так в распространенных статических языках не делает можем считать что этого нет.
WH>VC++ умеет edit&continue
WH>Так что есть.

Не используется в продакшане.

FR>>Немерле этого не позволяет, я же специально повторил несколько раз.
WH>Я могу при разработке макроса использовать макросы.
WH>Я могу в генерируемом коде использовать макросы.
WH>Я могу макросом сгенерировать макрос. Хотя не понятно зачем это может быть нужно.

Фигня ваш немерли

FR>>Тоже нет, Немерли не умеет интерпретировать байт код и даже не умеет его инструментировать как некторые тулзы для явы, это на нем конечно можно сделать, но фактически вручную написав полноценный интерпретатор.
WH>Инструментирование байткода это для лузеров которые не могут трансформировать АСТ.

Мягкое с теплым не надо сравнивать.

FR>>Тот же питон из коробки позволяет инструментировать как байт код так и AST и делать, как такие примитивные вещи
FR>>http://code.activestate.com/recipes/286134-safe-expression-evaluation/
WH>Не проблема ни разу.

Не было бы у вас готового было бы проблемой.

FR>>http://codespeak.net/pypy/dist/pypy/doc/theory.html#abstract-interpretation
WH>В статически типизированном языке это не нужно.

Жаль в ms об этом не знают http://www.google.ru/search?hl=ru&newwindow=1&client=opera&rls=ru&q=abstract+interpretation+site%3Amicrosoft.com&aq=f&aqi=&aql=&oq=&gs_rfai= и всунули эту гадость даже в реализацию своих Code Contracts

Здравствуйте, VladD2, Вы писали:

VD>Да более чем уместна. Во-первых не всегда обойтись встроенными функциями, а не встроенные будут вызываться для каждой ячейки.

Не будут. Вся прелесть Матлаба заключена в его названии — "Матричная лаборатория". В 99% случаев все операции над матрицами делаются в одну строку без циклов.

VD>Во-вторых, не все вычисления связанны с огромными массивами.

Практически все. Сейчас такой период развития вычислительной техники, который позволяет строить громоздкие математические модели реальных процессов. Скажем, классификация пикселя изображения в видеопотоке: он относится к переднему плану или часть фона. Раньше использовалась простая статистическая модель — нормальное распределение яркости пикселя. Сейчас же создают смесь нормальных распределений для каждого цветового канала пикселя. Или скрытые марковские модели используют. Итого даже для маленьких разрешений 352х288 объёмы данных возрастают с 200 тысяч элементов до 2 миллионов. То есть модели сложность практически не изменилась, а объёмы данных — эти самые матрицы растут или в размерах, или в количествах.
И так во многих областях. У меня есть знакомые занимающиеся речью, статистикой смертности и другими математическими проблемами. Переходят на Матлаб и радуются ускорению.

VD>В третьих, использование оптимизированных библиотек (в том числе перекладывающих вычисление на GPU) никто не запрещает в любом языке. Дон Реба, как раз и писал о том, что он так и поступает.

На Матлабе можно автоматически распараллелить как на кластер, так и на GPU без трудозатрат пользователя пакета. Вообще говоря, только монстры типа адобовского фотошопа или 3D Max могут сравниться по качеству обеспечения пользователя таким халявным быстродействием.
Можно так сделать в других языках? Не во всех. Где-нибудь так сделано? Покажите!

Здравствуйте, FR, Вы писали:

FR>Проблема в перекомпиляции.
Перекомпиляция это не проблема.

FR>У меня сомнения в том что ты придумал PEG парсер.
Дьявол как всегда в деталях.
Я делаю не просто PEG парсер, а парсер который может менять грамматику во время разбора.
При этом нужно не забывать о таких мелочах как сообщения об ошибках, востановление после ошибки с генерацией хоть какогото AST (нужно для интелисенса) и такой мелочи как скорость достаточная для того чтобы перепарсить весь фаил после каждого нажатия на кнопку.
И еще много разных мелочей.

WH>>VC++ умеет edit&continue
WH>>Так что есть.
FR>Не используется в продакшане.
Тем не менее доказывает тот факт что для статики жто возможно.

WH>>Инструментирование байткода это для лузеров которые не могут трансформировать АСТ.
FR>Мягкое с теплым не надо сравнивать.
Да я и не сравниваю.
Нахрена вообще нужно байткод инструментировать?

WH>>Не проблема ни разу.
FR>Не было бы у вас готового было бы проблемой.
Если бы да кабы...

FR>Жаль в ms об этом не знают http://www.google.ru/search?hl=ru&newwindow=1&client=opera&rls=ru&q=abstract+interpretation+site%3Amicrosoft.com&aq=f&aqi=&aql=&oq=&gs_rfai= и всунули эту гадость даже в реализацию своих Code Contracts
Ну да.
Code Contracts это костыль для тех кто не в состоянии сделать нормальную систему типов.
Они намного слабее чем type refinements и при этом не дают никаких гарантий.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Только что Джо Армстронг подкинул дровишек в erlang-questions:

Date: Mon, 8 Nov 2010 11:16:40 +0100
From: Joe Armstrong <erlang@gmail.com>
Subject: Re: [erlang-questions] Re: Conceptual questions on key-value databases for RDBMs users

I agree — I'd go further. For most of what I want to do the weaker the type the better — even dynamic types are too structured. A lot of what I want can be done with unstructured text and full-text indexing (which has even less structure that a weak type)

I find that in all the applications I've programmed so far I want the following (In priority order)

0) Easy of setup
I'm lazy — but I don't want to struggle through hour long sessions of Googling for bug-fixes to get stuff working.
1) Key — Value lookup/retrieval
What I put in I can get out — the key is simple the Value can be very complex
2) Full text searches
I want to search strings for free text
3) Encapsulation
I like all the database in a single file — so I can send it in a message move it around etc.
4) Replication
I want stuff to be stored forever
5) Scalability
I want it to scale

[чисто эрланговые заморочки поскипаны]

Кто не заметил ключевых слов — even dynamic types are too structured.

Здравствуйте, Mamut, Вы писали:

M>>>Скачал IDEA для Java. В пяти попытках рефакторинга она мне предложила такой же ломающий рефакторинг. И это — на статистически типизированом языке, в котором это должно быть раз плюнуть, не?
WH>>Сколько пользовался ReSharper'ом ни разу такого небыло.

M>Ага. Так оказывается не весь рефакторинг и не везде работает. А только некий определенный и только на некотором определенном языке. Ну сказочник ты, честное слово.

Оффоп.

Приведи описание одной или двух из этих пяти попыток. Наличие исходника-примера очень приветствуется.

M>>>>Скачал IDEA для Java. В пяти попытках рефакторинга она мне предложила такой же ломающий рефакторинг. И это — на статистически типизированом языке, в котором это должно быть раз плюнуть, не?
WH>>>Сколько пользовался ReSharper'ом ни разу такого небыло.

M>>Ага. Так оказывается не весь рефакторинг и не везде работает. А только некий определенный и только на некотором определенном языке. Ну сказочник ты, честное слово.

NGG>Оффоп.

NGG>Приведи описание одной или двух из этих пяти попыток. Наличие исходника-примера очень приветствуется.

Увы, к моменту описания попыток рефакторинг уже был две недели как совершен. Но как только вернусь на Java, постараюсь еще раз воспроизвести.

Здравствуйте, Mamut, Вы писали:

M>Увы, к моменту описания попыток рефакторинг уже был две недели как совершен. Но как только вернусь на Java, постараюсь еще раз воспроизвести.

Буду признателен

Здравствуйте, FR, Вы писали:

K>>А что, в мейнстриме есть динамические языки кроме PHP? Ну, разве что, можно, с некоторой натяжкой, Питон посчитать.

FR>С некоторой натяжкой и руби можно посчитать.

С такой натяжкой можно посчитать любой. Я еще понимаю — перл.

FR>Раньше были кучи бейсиков, потом VB

Ничего не знаю о существовании динамических бейсиков. Будучи школьником, писал на ZX, Корвет(то же, что и GW) и Quick, точно знаю, что в Turbo была система типов идентичная паскалеской — так специально было сделано. Студентом что-то там автоматизировал в офисе на VBA, все это было просто смертельно статическим, ну если комовский вариант в Visual считать динамикой — так и C++ с Delphi тогда динамические. Для того, чтоб добавить в статический язык динамические фичи одного варианта мало — нужен какой-то аналог ExpandoObject с соотвествующей порцией сахара, как в четвертом шарпе.

FR>Smalltalk.

К сожалению, единственный динамический язык промышленного качества (ну, кроме Эрланга) так в мейнстрим и не попал. Хотя, может, и к счастью.

FR>Интерфейсы ничем динамике ни противоречат,

Проверка интерфейсов в компайл-тайм противоречит кардинально. Потому, что это по определению статика. А если проверка в рантайме — то такой интерфейс просто синтаксический сахар для ассерта и описаных мной выше чудес не обеспечивает.

FR>другой стороны в статике вполне живет безинтерфейсная структурная типизация

В статике и структурная типизация все вышеописаные чудеса обеспечит. Дело то не в интерфейсе, как частном случае контракта, а в проверке контрактов в компайл-тайм.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>С такой натяжкой можно посчитать любой. Я еще понимаю — перл.

Ну перл уже пошел коболовской дорожкой хотя да он почти был в мейнстриме.

FR>>Раньше были кучи бейсиков, потом VB

K>Ничего не знаю о существовании динамических бейсиков. Будучи школьником, писал на ZX, Корвет(то же, что и GW) и Quick, точно знаю, что в Turbo была система типов идентичная паскалеской — так специально было сделано. Студентом что-то там автоматизировал в офисе на VBA, все это было просто смертельно статическим, ну если комовский вариант в Visual считать динамикой — так и C++ с Delphi тогда динамические. Для того, чтоб добавить в статический язык динамические фичи одного варианта мало — нужен какой-то аналог ExpandoObject с соотвествующей порцией сахара, как в четвертом шарпе.

То есть динамические чисто процедурные языки по твоему вообще не могут существовать?

FR>>Smalltalk.

K>К сожалению, единственный динамический язык промышленного качества (ну, кроме Эрланга) так в мейнстрим и не попал. Хотя, может, и к счастью.

Но был весьма близок.
Ну и множество реализаций лиспа тоже вполне "промышленного" уровня. Да и питон судя по спонсорам http://python.org/psf/ и долговременной поддержке
версий http://python.org/download/releases/ также на этом уровне.

FR>>Интерфейсы ничем динамике ни противоречат,

K>Проверка интерфейсов в компайл-тайм противоречит кардинально. Потому, что это по определению статика. А если проверка в рантайме — то такой интерфейс просто синтаксический сахар для ассерта и описаных мной выше чудес не обеспечивает.

"не чудес" вполне достаточно.

FR>>другой стороны в статике вполне живет безинтерфейсная структурная типизация

K>В статике и структурная типизация все вышеописаные чудеса обеспечит. Дело то не в интерфейсе, как частном случае контракта, а в проверке контрактов в компайл-тайм.

Да это хорошо, но далеко не панацея, все-равно без рантайма никак.

Здравствуйте, FR, Вы писали:

FR>То есть динамические чисто процедурные языки по твоему вообще не могут существовать?

Visual Basic не является чисто процедурным языком. Но вообще, вопрос интересный. Динамические процедурные языки, конечно, возможны. Тут главное не в процедурности а в полиморфизме. Динамика это всего-навсего полиморфность по всем аргументам с проверками в рантайме и без какого-то развитого набора средств для ограничения этого полиморфизма. А вот мономорфный язык вроде старого бейсика в принципе не может быть динамическим. Вернее можно, конечно, сделать реализацию, проверяющую типы в рантайме, но написать корректно исполняющуюся программу, у которой нельзя было бы все типы проверить в компайл-тайм в принципе невозможно.

FR>"не чудес" вполне достаточно.

Мне не достаточно.

FR>Да это хорошо, но далеко не панацея, все-равно без рантайма никак.

В тех системах типов, что есть в более-мнее распространенных языках, да, никак.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

FR>>То есть динамические чисто процедурные языки по твоему вообще не могут существовать?

K>Visual Basic не является чисто процедурным языком. Но вообще, вопрос интересный. Динамические процедурные языки, конечно, возможны. Тут главное не в процедурности а в полиморфизме. Динамика это всего-навсего полиморфность по всем аргументам с проверками в рантайме и без какого-то развитого набора средств для ограничения этого полиморфизма. А вот мономорфный язык вроде старого бейсика в принципе не может быть динамическим. Вернее можно, конечно, сделать реализацию, проверяющую типы в рантайме, но написать корректно исполняющуюся программу, у которой нельзя было бы все типы проверить в компайл-тайм в принципе невозможно.

Да тут согласен.

FR>>Да это хорошо, но далеко не панацея, все-равно без рантайма никак.

K>В тех системах типов, что есть в более-мнее распространенных языках, да, никак.

С зависимыми типами тоже свои проблемы появляются, и ограничение тьюринг полноты и описания ограничений типа
с объемом сравнимым с самим кодом, что на практике означает просто перенос ошибок туда.

Здравствуйте, rsdn2010, Вы писали:

R>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?
1. Javascript преимущественно используется для клиентского программирования.
Исторически, он начинался как средство внесения небольшого оживления в HTML (Помните такую штуку — DHTML?). Для манипуляций DOM-моделью статически типизированный язык подходит не шибко хорошо. Всё равно у большинства DOM-объектов как такового "типа" нету; удобнее работать с ними как с "мешками" именованных свойств. Скажем, если попытаться прикрутить к ДОМу Паскаль, то получится что-то вроде поздних Delphi — там, где у объектов с IDispatch можно было после точки писать любую ерунду, и компилятор это проглатывал. Ну, то есть статичность типизации оказывалась мало где нужна.
Кто ж знал, что на этой ерунде будут писать почтовых клиентов и 3d-игры.
2. Я не уверен, что PHP, Python и Ruby такие уж динамические. Вот Perl, вроде бы, динамика. Опять же, история развития веба: сначала в нём лежали статические документы, потом стали придумывать динамику. Основная задача — генерация текстов. Процессинг текстов в традиционных статически типизированных языках типа C/C++ сделан, мягко говоря, не очень удобно. Поэтому писали на том, что подвернулось под руку.
3. Опять же, большинство традиционных "статических" языков очень требовательны к программисту. Запустить Хелло Ворлд на С++ это уже целая наука — помимо собственно языка, нужно ещё уметь кучу правил сборки, верно расставить инклюды, корректно описать int main(). Нужно сидеть, руками описывать типы для всего. Нужно декларировать тип каждой переменной и всё такое. Как показало развитие событий, вполне можно иметь статический язык с выводом типов, но это развитие произошло спустя много лет после взлёта веба. А в 90е годы всяко было проще написать программу без всех этих нудных unsigned int, потому что оно и так работает. А если не работает — ничего страшного, цикл исполнения — это одна страница. Сломалось — поправили. И, опять же, без 25минутной компиляции windows.h.

4. Стоит отметить, что сейчас статика в вебе распространена достаточно сильно: ASP.NET и Java используются весьма широко. Обе платформы предлагают вполне себе статику.

Здравствуйте, Гест, Вы писали:

Г>Здравствуйте, rsdn2010, Вы писали:

R>>почему в вебе распространены именно динамические языки программрования — PHP, Python, Ruby, Javascript?

Г>По историческим причинам, полагаю.

Г>Они же не «победили» статические альтернативы: сначала почти что только они и были. А взялись, по всей видимости, из Юникс-культуры скриптов.

Не победили, а дополнили. Победить они могут только в головах конкретных разработчиков, которые в зависимости от задачи используют то или иной язык.

	От:	rsdn2010
	Дата:	10.10.10 16:27
	Оценка:	1 (1)

От:	Гест	https://zverok.github.io
Дата:	10.10.10 17:02
Оценка:

	От:	iZEN
	Дата:	10.10.10 17:02
	Оценка:	+1 -1

От:	netch80	http://netch80.dreamwidth.org/
Дата:	10.10.10 18:45
Оценка:

От:	Skynin	skynin.blogspot.com
Дата:	10.10.10 18:50
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	10.10.10 19:06
Оценка:

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	11.10.10 07:02
Оценка:	+1

	От:	Воронков Василий
	Дата:	11.10.10 08:37
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	11.10.10 13:04
Оценка:	2 (2) +5

От:	Mamut	http://dmitriid.com
Дата:	12.10.10 07:09
Оценка:	+4

	От:	yoriсk.kiev.ua
	Дата:	12.10.10 11:42
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	12.10.10 16:56
Оценка:	+1

От:	IB	http://rsdn.ru
Дата:	12.10.10 16:59
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	13.10.10 11:40
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	14.10.10 20:22
Оценка:

	От:	WolfHound
	Дата:	15.10.10 07:26
	Оценка:	16 (2)

От:	DemAS	http://demas.me
Дата:	17.10.10 06:25
Оценка:

От:	Aen Sidhe	Просто блог
Дата:	18.10.10 15:18
Оценка:

От:	hardcase	http://nemerle.org
Дата:	21.10.10 11:22
Оценка:

	От:	Klapaucius
	Дата:	22.10.10 11:25
	Оценка:	1 (1) +2

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	27.10.10 06:18
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	15.12.10 15:14
Оценка:	6 (1) +2