Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
На мой взгляд это совсем не так.

1) Сам по себе Html5 ничем особо не отличается от предыдущих версий, да есть теги новые разметки типа <header><footer> и.т.п. позволяющие чуть улучшить понимание структуры страницы поисковым роботам ( не уверен что это сильно скажется на поисковых качествах, т.к. все равно в этих тегах будет размещаться разного рода информация и будет требоваться семантический анализ, чтобы отделять мух от котлет. Например кто-то в footer размещает Copyright, кто-то ссылки мелким шрифтом на страницы, кто-то контактную информацию ).
Наиболее значимым введением которое преображает html5 снаружи и делает его отличимым от предыдущих версий можно назвать — <canvas> позволяющий рисовать 2D и 3D объекты в брозуере. Но каким образом нам предлагается этим всем управлять — через JavaScript.

2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
Таким образом разработка на Javascript обойдется очень дорого.

3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.

4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

Итого мое мнение что с приходом Html5 произойдет небольшое смещение реализации части user-интерфейса в javascript, например красивые меню, интерактивные каталоги, сайты визитки, все что не требует сложной логики, основная логика будет реализовываться по прежнему в сервисах на удобных типизированных и объектно-ориентированных языках. Сложные графические вещи типа мультов, игр будут по прежнему делаться на Flash, Silverlight, возможно найдутся энтузиасты которые напишут сложные демки на javascript, но это врятли будет частой практикой в коммерческих проектах.

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

A>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>На мой взгляд это совсем не так.

A>1) Сам по себе Html5 ничем особо не отличается от предыдущих версий, да есть теги новые разметки типа <header><footer> и.т.п. позволяющие чуть улучшить понимание структуры страницы поисковым роботам ( не уверен что это сильно скажется на поисковых качествах, т.к. все равно в этих тегах будет размещаться разного рода информация и будет требоваться семантический анализ, чтобы отделять мух от котлет. Например кто-то в footer размещает Copyright, кто-то ссылки мелким шрифтом на страницы, кто-то контактную информацию ).
A>Наиболее значимым введением которое преображает html5 снаружи и делает его отличимым от предыдущих версий можно назвать — <canvas> позволяющий рисовать 2D и 3D объекты в брозуере. Но каким образом нам предлагается этим всем управлять — через JavaScript.
HTML5 — это html+css+js. Это единый стандарт, описывающий много всего сразу.

A>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>Таким образом разработка на Javascript обойдется очень дорого.
По сравнению с другими динамическими языками — также. Кроме того существуют фреймворки, которые компилируют статически типизированный код в js.

A>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.

A>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

A>Итого мое мнение что с приходом Html5 произойдет небольшое смещение реализации части user-интерфейса в javascript, например красивые меню, интерактивные каталоги, сайты визитки, все что не требует сложной логики, основная логика будет реализовываться по прежнему в сервисах на удобных типизированных и объектно-ориентированных языках. Сложные графические вещи типа мультов, игр будут по прежнему делаться на Flash, Silverlight, возможно найдутся энтузиасты которые напишут сложные демки на javascript, но это врятли будет частой практикой в коммерческих проектах.

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

a> Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.

Не слушай наркоманов.

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

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

A>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>На мой взгляд это совсем не так.

A>>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>>Таким образом разработка на Javascript обойдется очень дорого.
G>По сравнению с другими динамическими языками — также. Кроме того существуют фреймворки, которые компилируют статически типизированный код в js.

В данном случае речь о сравнении с java,c#, убийцами которых некоторые называют html5, или actionscript используемый в flash, который отчасти динамичен, но в нем присутствуют нативные сущности для удобной работы с анимацией, в отличии от js.


A>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
G>Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.
css это рулится только отчасти, css можно повлиять на статичный размер/видимость объектов. Но мультиплатформа требует помимо размеров еще и интерактивность с пользователем держать на уровне , одно дело когда одна кнопка на девайсе, другое дело когда кнопок нет, но есть джойстик и т.п..
Также допустим анимация , что с того что в css размер объекта стал меньше, анимация на разном разрешении требует изменения ее логики, например на маленьком экране нужно 5 кадров сделать, на большом 20. не всегда можно пропорционально уменьшать объекты и использовать только относительные координаты.


A>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
G>Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

Про то и речь что в проектах где недопустимо все выкладывать в открытый код, будут по прежнему держать на сервере, что в свою очередь ничем не меняет существующий подход. Врятли кто-то серверный код будет делать на javascript, когда более удобную с точки зрения разработки/безопасности версию можно сделать на том же .net, java.

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

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

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

A>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>На мой взгляд это совсем не так.

A>>>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>>>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек , например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку. По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>>>Таким образом разработка на Javascript обойдется очень дорого.
G>>По сравнению с другими динамическими языками — также. Кроме того существуют фреймворки, которые компилируют статически типизированный код в js.

A>В данном случае речь о сравнении с java,c#, убийцами которых некоторые называют html5, или actionscript используемый в flash, который отчасти динамичен, но в нем присутствуют нативные сущности для удобной работы с анимацией, в отличии от js.

Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может. А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.


A>>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
G>>Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.
A>css это рулится только отчасти, css можно повлиять на статичный размер/видимость объектов. Но мультиплатформа требует помимо размеров еще и интерактивность с пользователем держать на уровне , одно дело когда одна кнопка на девайсе, другое дело когда кнопок нет, но есть джойстик и т.п..
A>Также допустим анимация , что с того что в css размер объекта стал меньше, анимация на разном разрешении требует изменения ее логики, например на маленьком экране нужно 5 кадров сделать, на большом 20. не всегда можно пропорционально уменьшать объекты и использовать только относительные координаты.

Это вопрос дизайниа. Давно устоявшийся подход — подсовывать разным клиентам разные представления.


A>>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
G>>Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

A>Про то и речь что в проектах где недопустимо все выкладывать в открытый код, будут по прежнему держать на сервере, что в свою очередь ничем не меняет существующий подход. Врятли кто-то серверный код будет делать на javascript, когда более удобную с точки зрения разработки/безопасности версию можно сделать на том же .net, java.
Именно, а ты что ожидал? Что придет html5 и сразу все на нем писать будут? Пока это только интерфейс (client-side) и ничего другого не предвидится.

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

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

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

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

A>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>На мой взгляд это совсем не так.


G>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
G>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?

Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas. А собственно все описание логики работы этого самого Canvas выносится в javascript.
Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет



A>>>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность, но не нужно забывать что помимо различных ОС еще требуется адаптация под железо, одно дело создать удобный интерфейс для десктопа с 102 клавишами и разрешением 1920х1080 , другое дело для телефона 320х240 или iPad с одной кнопкой и поддержкой multitouch. Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться. В результате трудоемкость разработки реального качественного кросплатформенного приложения будет не менее тяжеловесна чем сейчас.
G>>>Это вообще-то CSS рулится, а не JS. Кроме того пользователям можно подсовывать мобильный интерфейс приложений с помощью серверного кода.
A>>css это рулится только отчасти, css можно повлиять на статичный размер/видимость объектов. Но мультиплатформа требует помимо размеров еще и интерактивность с пользователем держать на уровне , одно дело когда одна кнопка на девайсе, другое дело когда кнопок нет, но есть джойстик и т.п..
A>>Также допустим анимация , что с того что в css размер объекта стал меньше, анимация на разном разрешении требует изменения ее логики, например на маленьком экране нужно 5 кадров сделать, на большом 20. не всегда можно пропорционально уменьшать объекты и использовать только относительные координаты.

G>Это вопрос дизайниа. Давно устоявшийся подход — подсовывать разным клиентам разные представления.
Не только дизайн ( Layout ), логика ввода-вывода зависит от особенностей устройства.



A>>>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.
G>>>Есть различные JS minifiers и packers, которые значительно усложняют реверс-инжинирирг кода. Кроме того KS может быть сгенерирован на сервере, что дает еще больше возможностей для обфускации. Опять-таки весть business critical код можно держать на сервере.

A>>Про то и речь что в проектах где недопустимо все выкладывать в открытый код, будут по прежнему держать на сервере, что в свою очередь ничем не меняет существующий подход. Врятли кто-то серверный код будет делать на javascript, когда более удобную с точки зрения разработки/безопасности версию можно сделать на том же .net, java.
G>Именно, а ты что ожидал? Что придет html5 и сразу все на нем писать будут? Пока это только интерфейс (client-side) и ничего другого не предвидится.
Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

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

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

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

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

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

A>>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>>На мой взгляд это совсем не так.


G>>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
A>Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
Так это твое утверждение. Обычно говорят о замене технологий web client side на HTML5.

G>>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

A>Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?
http://ru.wikipedia.org/wiki/Canvas_(HTML)
http://chrome.angrybirds.com/

A>Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
A>для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas.
Серьезные графические вещи во Flash и Silverlight также делаются кодом.

А собственно все описание логики работы этого самого Canvas выносится в javascript.
A>Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
A>Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет
Пример с линией неинтересен. Давай лучше спрайты и эффекты. Упс.. код и там и там...



A>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.

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

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

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

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

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

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

A>>>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>>>На мой взгляд это совсем не так.


G>>>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
A>>Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
G>Так это твое утверждение. Обычно говорят о замене технологий web client side на HTML5.

G>>>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

A>>Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?
G>http://ru.wikipedia.org/wiki/Canvas_(HTML)
И ? Приведен пример как на javascript рисуется эллипс. Что собственно никак не объясняет чем же javascript имеет преимущество перед c#,java,actionscript особенно в сложных приложениях.

G>http://chrome.angrybirds.com/
Это вообще шикарны пример, который в javascripte создает флеш объект и его подгружает.
Если отключить flash то не работает


A>>Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
A>>для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas.
G>Серьезные графические вещи во Flash и Silverlight также делаются кодом.
Да только мы возвращаемся к тому что я объяснял в 1м своем посте в п.2) Silverlight это код на .net , типизированный язык с ООП который намного удобнее для разработки такого рода вещей.


G>А собственно все описание логики работы этого самого Canvas выносится в javascript.
A>>Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
A>>Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет
G>Пример с линией неинтересен. Давай лучше спрайты и эффекты. Упс.. код и там и там...

Я к тому и вел что код надо писать, но код на c# и т.д. , особенно где требуется не только линию рисовать, а делать гибкую логику удобнее типизированные ООП языки.


A>>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

G>Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.
Скорее наоборот, у SL и Flash есть хорошее и важное преимущество — язык на котором графика описывается.
Поэтому Html5 будет использоваться только на уровне менюшек собственно где и сейчас js работает. Только будет чуть красивше.

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

g> A>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

g> Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.

Слабо верится. Либо у первых (Flash, SL) единственная исполняющая среда/платформа (а значит ноль проблем с совместимостью), либо у второго, по меньшей мере, 4 сильных игрока. Как уже сказали, вряд-ли HTML5 уйдет дальше украшательств страничек (которые начнут резать, как и flash-баннеры) и несложных игрушек

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

A>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

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

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

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

A>>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

KV>А можно чуть шире раскрыть связь между открытостью исходников и безопасностью? А то без пояснений, она, скажем так — неочевидна.

Проблема не только в открытости исходников, а еще в том что именно эти исходники исполняются в runtime и легко поддаются отладке, а также подмене.


1) допустим у вас есть некий алгоритм, а может целый движок или облако, который представляет сам по себе коммерческую ценность , когда он находится на server-side вы только передаете входные данные, получаете результат. В случае открытия исходников этого алгоримта ( например перенос на client-side в виде javascript ) его могут легко позаимствовать.

2) различные инъекции, например есть код валидации входных параметров на server-side, в случае когда он переезжает на client-side в java-script, то в приницпе можно вмешаться в работу javascript отладчиком и изменить значения параметров/переменных на невалидные приводящие к некоторой критичной ошибке.
Например сумма платежа ограничивается 15 000 рублей. Если такие проверки будут в javascript то их можно будет обойти и провести транзакцию на большую сумму. Или бизнес-логика , например что сначала нужно проверить валидность в одном сервисе, потом в другом. Если эта цепочка проверок будет в js , то опять же можно обойти.

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

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

При оценке рисков информационной безопасности распределенных систем (к классу которых относятся и веб-приложения) актуальные угрозы выявляются на основании данных о точках пересечения потоками данных границ доверия компонентов системы. Для веб-приложений одной из таких точек является TCP-порт железки на серверной стороне, непосредственно торчащей наружу, в интернет. В протоколе HTTP не предусмотрены средства обеспечения целостности и конфиденциальности передаваемых по нему данных...

KV>>А можно чуть шире раскрыть связь между открытостью исходников и безопасностью? А то без пояснений, она, скажем так — неочевидна.
A>Проблема не только в открытости исходников, а еще в том что именно эти исходники исполняются в runtime и легко поддаются отладке, а также подмене.

...т.о., в веб-приложениях, клиентская сторона целиком и полностью находится в недоверенной зоне, соответственно контрмера угрозе подмены данных ("Data tampering", в простонародье. Входит в модель угроз STRIDE) должна быть реализована внутри границы доверия, т.е. на сервере. Иными словами, совершенно не важно, что там на клиенте поддается отладке, а что нет. Сервер должен ожидать что буквально в каждом HTTP-запросе ему приходят данные, которым он не может доверять без дополнительных проверок. За границами доверия подмене подвержен сам клиент, целиком и полностью. И, в свете этого, детали его реализации с т.з. данной угрозы, не имеют значения.

A>1) допустим у вас есть некий алгоритм, а может целый движок или облако, который представляет сам по себе коммерческую ценность , когда он находится на server-side вы только передаете входные данные, получаете результат. В случае открытия исходников этого алгоримта ( например перенос на client-side в виде javascript ) его могут легко позаимствовать.

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

A>2) различные инъекции, например есть код валидации входных параметров на server-side, в случае когда он переезжает на client-side в java-script, то в приницпе можно вмешаться в работу javascript отладчиком и изменить значения параметров/переменных на невалидные приводящие к некоторой критичной ошибке.
A>Например сумма платежа ограничивается 15 000 рублей. Если такие проверки будут в javascript то их можно будет обойти и провести транзакцию на большую сумму. Или бизнес-логика , например что сначала нужно проверить валидность в одном сервисе, потом в другом. Если эта цепочка проверок будет в js , то опять же можно обойти.

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

A>3) Использование сервисов как внешних, так и своих, как правило сервисы требуют параметры для авторизации транзакции , тот же логин пароль, зачастую в открытом виде передается, в случае server-side это не проблема,

Передача пароля в открытом виде по HTTP-каналу всегда является проблемой, вне зависимости от случая client-side или server-side. И всегда является уязвимостью, причем весьма серьезной.

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

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

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

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

G>HTML5 — это html+css+js. Это единый стандарт, описывающий много всего сразу.

Ну нет конечно. html5 это собственно html + набор runtime features exposed to JS (local storage, web sockets, etc).
css вообще это работа отдельной WG. С HTML5 никак не связана.
js это вообще даже не W3C детище. W3 комитет к js не имеет никакого отношения вообще.

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

A>По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением.

Ну нет конечно. JS имеет две фундаментальные коллекции: array<any> и map<any,any>.

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

Безотносительно же безопасности, я считаю, что инструмент должен подбираться под задачу и условия, в которых она решается, а не наоборот. И говорить о том, что HTML5 однозначно и всегда кака, не способная заменить Flash и SL везде и во всем, не очень корректно. Например, на ios-based устройствах нет ни флеша не силверлайта, в отличии от. Проблема же полиморфизма в суровых условиях объектов на прототипах (кстати, а почему проблема-то?), может быть решена генерацией клиентских сценариев на стороне сервера под нужную железку, приславшуюю HTTP-запрос. Причем эта генерация может осуществляться на базе кода на вполне себе статически-типизированном языке. Именно этот подход планируется реализовать в Nemerle.WUI и именно он реализован в GWT, где народ пишет себе на Java и Python и даже не вникает, в общем случае, как именно этот код будет преобразован в клиентский js.

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

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

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

KV>При оценке рисков информационной безопасности распределенных систем (к классу которых относятся и веб-приложения) актуальные угрозы выявляются на основании данных о точках пересечения потоками данных границ доверия компонентов системы. Для веб-приложений одной из таких точек является TCP-порт железки на серверной стороне, непосредственно торчащей наружу, в интернет. В протоколе HTTP не предусмотрены средства обеспечения целостности и конфиденциальности передаваемых по нему данных...

KV>>>А можно чуть шире раскрыть связь между открытостью исходников и безопасностью? А то без пояснений, она, скажем так — неочевидна.
A>>Проблема не только в открытости исходников, а еще в том что именно эти исходники исполняются в runtime и легко поддаются отладке, а также подмене.

KV>...т.о., в веб-приложениях, клиентская сторона целиком и полностью находится в недоверенной зоне, соответственно контрмера угрозе подмены данных ("Data tampering", в простонародье. Входит в модель угроз STRIDE) должна быть реализована внутри границы доверия, т.е. на сервере. Иными словами, совершенно не важно, что там на клиенте поддается отладке, а что нет. Сервер должен ожидать что буквально в каждом HTTP-запросе ему приходят данные, которым он не может доверять без дополнительных проверок. За границами доверия подмене подвержен сам клиент, целиком и полностью. И, в свете этого, детали его реализации с т.з. данной угрозы, не имеют значения.

A>>1) допустим у вас есть некий алгоритм, а может целый движок или облако, который представляет сам по себе коммерческую ценность , когда он находится на server-side вы только передаете входные данные, получаете результат. В случае открытия исходников этого алгоримта ( например перенос на client-side в виде javascript ) его могут легко позаимствовать.

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

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

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


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

Если спуститься на землю, то ИБ вводится с целью сокращения убытков компании и целью является недопущение утраты/копирования/изменения данных которые могут привести к убыткам.
При этом нужно учитывать следующее
1) целесообразность, да с точки зрения теории вынос кода на клиента в недоверенную зону особо не отличается что на javascript, что на flash/silverlight, но на практике стоимость взлома javascript и бинарников отличается, поэтому с точки зрения коммерции иногда не допустимо размещать код в javascript, но допускается в бинарном виде.
Например клиент-банк приложение отдается клиенту, но вот исходники этого клиент-банка вам врятли отдадут или предложат клиент-банк в виде javascript, хотя как продукт они коммерческой ценности не имеют, т.к. заточены на конкретный банк и использоваться могут только с этим банком, даже было бы банку
выгодно если ошибки могли исправлять сами клиенты, но это не допустимо именно из-за риска что стоимость взлома и подмены клиента в таком виде существенно снижается.

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

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

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

KV>Безотносительно же безопасности, я считаю, что инструмент должен подбираться под задачу и условия, в которых она решается, а не наоборот. И говорить о том, что HTML5 однозначно и всегда кака, не способная заменить Flash и SL везде и во всем, не очень корректно.

Да собственно никто и не говорит что HTML5 не найдет своего применения, конечно когда нужно нарисовать "летающие снежинки", показать видео или прожужжать чтонибудь ( это условно сложность задачи ) то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.
Поэтому как я уже писал в начальном посте HTML5 войдет в жизнь но не так кардинально как об этом некоторые переживают.

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

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

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

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

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

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

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

A>>>>>>>Есть такое мнение что html5 — убийца Silverlight, Flash и даже .NET Framework.
A>>>>>>>На мой взгляд это совсем не так.


G>>>>Бессмысленное сравнение. JS нету и не будет в серверной части, в энтерпрайзах или еще где. Даже node.js до сих пор не то что взлететь, даже от земли оторваться не может.
A>>>Ну я собственно о том же, задача данного поста не сравнить JS c java/c#, а показать что утверждение что html5 заменит нам все и вся — в корне не верно.
G>>Так это твое утверждение. Обычно говорят о замене технологий web client side на HTML5.

G>>>>А что касается клиентского веба, то там да HTML5 зарулит Flash и Sliverlight, но отнюдь не из за js, а скорее вопреки ему.

A>>>Можно на примере каким образом HTML5 зарулит разработку анимации и интерактивного интерфейса на том же Flash или Silverlight ?
G>>http://ru.wikipedia.org/wiki/Canvas_(HTML)
A>И ? Приведен пример как на javascript рисуется эллипс.
3 минуты в гугле и... http://www.html5canvastutorials.com/advanced/html5-canvas-ovals/

A>Что собственно никак не объясняет чем же javascript имеет преимущество перед c#,java,actionscript особенно в сложных приложениях.
Да никакого не имеет кроме поддержки со стороны производителей браузеров.

G>>http://chrome.angrybirds.com/
A>Это вообще шикарны пример, который в javascripte создает флеш объект и его подгружает.
А developertools говорит что там canvas. Я ему как-то больше доверяю

A>Если отключить flash то не работает
flash там для звуков, это пока "больное место" html5 и js вообще.

A>>>Начнем с того что в html5 нет тегов для разработки интерактивного интерфейса, все как и раньше делается за счет javascript , только в html5
A>>>для изменения визуального за счет модификации DOM, предлагается также модификация Canvas. Собственно серьезные графические вещи сопоставимые с Flash и Silverlight можно делать только через Canvas.
G>>Серьезные графические вещи во Flash и Silverlight также делаются кодом.
A>Да только мы возвращаемся к тому что я объяснял в 1м своем посте в п.2) Silverlight это код на .net , типизированный язык с ООП который намного удобнее для разработки такого рода вещей.
Угу, только для него нужен silverlight plugin, который например на мобильных устройствах отсутствует, как и flash в большинстве своем.


G>>А собственно все описание логики работы этого самого Canvas выносится в javascript.
A>>>Например как мне на Canvas нарисовать линию ? Нужно в javascript вызвать метод типа lineTo(1,1) , а как собственно можно на эту линию повлиять из css — никак. Собственно css остается в своей сегодняшней роли — влияние на представление только на DOM модель.
A>>>Например на том же Canvas нарисовали 2 кнопки, нужно как-то менять положение этих кнопок, опять же нужно менять javascript, разрабатывать отдельный код для данного случая css тут не поможет
G>>Пример с линией неинтересен. Давай лучше спрайты и эффекты. Упс.. код и там и там...
A>Я к тому и вел что код надо писать, но код на c# и т.д. , особенно где требуется не только линию рисовать, а делать гибкую логику удобнее типизированные ООП языки.
См выше.


A>>>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

G>>Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.
A>Скорее наоборот, у SL и Flash есть хорошее и важное преимущество — язык на котором графика описывается.
Это какой? сложную спрайтовую или 3d графику с анимацией в любом случае надо кодом делать. В случае SL еще понятно, там C# типизированный, хоть какое-то преимущество, а flash вообще сосет. html5 и сразу все везде работает, в том числе на мобильных устройствах (по крайней мере к этому все идет).

A>Поэтому Html5 будет использоваться только на уровне менюшек собственно где и сейчас js работает. Только будет чуть красивше.
Угу, и на уровне игрушек типа angrybirds. Только упс... это сейчас самая популярная игра.

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

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

g>> A>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.

g>> Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.

H>Слабо верится. Либо у первых (Flash, SL) единственная исполняющая среда/платформа (а значит ноль проблем с совместимостью), либо у второго, по меньшей мере, 4 сильных игрока. Как уже сказали, вряд-ли HTML5 уйдет дальше украшательств страничек (которые начнут резать, как и flash-баннеры) и несложных игрушек

Она "единственная" только для PC. А сейчас набирает обороты мобильный веб, куда пока ни один, ни второй не влез.

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

A>Если спуститься на землю, то ИБ вводится с целью сокращения убытков компании

Ну зачем сразу так пессимистично-то? Бывает, что и просто для предотвращения еще не понесенных убытков

A>и целью является недопущение утраты/копирования/изменения данных которые могут привести к убыткам.

Не совсем так. Зачастую случается, что мы имеем 100% гарантию того, что данные будут утрачены/скопированы/изменены. И в этом случае, ИБ вводится для того, чтобы минимизировать ущерб, который понесет корпорация в результате успешной атаки.

A>При этом нужно учитывать следующее
A>1) целесообразность, да с точки зрения теории вынос кода на клиента в недоверенную зону особо не отличается что на javascript, что на flash/silverlight, но на практике стоимость взлома javascript и бинарников отличается, поэтому с точки зрения коммерции иногда не допустимо размещать код в javascript, но допускается в бинарном виде.

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

Для атак на сторону клиента, доступ к его исходникам и возможность реверсинга, в большинстве случаев, также не является определяющим фактором. Например, чтобы обнаружить и проэксплуатировать DOM-based XSS, совершенно необязательно иметь доступ к исходнику javascript, в котором допущена данная уязвимость. Если пройтись по любой из существующих классификаций угроз веб-приложений, и рассмотреть клиентские угрозы, то независимость их существования от технологии реализации client-side станет очевидной. Готов обсудить примеры конкретных угроз, для которых это не так.

A>Например клиент-банк приложение отдается клиенту, но вот исходники этого клиент-банка вам врятли отдадут

Так мы о веб-приложениях в частности или о клиент-серверах в общем? Я — о веб-приложениях.

A>или предложат клиент-банк в виде javascript,

https://click.alfabank.ru и это — один из наиболее защищенных и грамотно реализованных клиент-банков из известных мне.

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

Да за счет чего она снижается-то? Как я уже сказал, она обусловлена исключительно, я подчеркиваю, исключительно особенностями используемого в веб-приложениях протокола. Мне не нужно знать устройство клиента, чтобы отреверсить контракт серверной стороны и успешно попытаться отправить на нее malformed-данные. Если же между клиентом и сервером появляется криптография, то для ее грамотной реализации, ее устойчивость не должна зависеть от обладания атакующим какими-либо знаниями о клиентской стороне. Иначе мы получаем security-by-obscurity, которая, как известно, заканчивается весьма печально и security'ей не является по определению.

A>Также как оставив открытую дверь в машине вероятность того что кто-то в нее залезет намного выше, чем если дверь будет закрыта, не смотря на то что разбить стекло не намного тяжелее чем открыть дверь за ручку.

Попытка проведения аналогий для теории информации с реальным миром и его объектами — одно из наиболее распространенных заблуждений. Скажите, какова вероятность того, что злоумышленник вместо угона машины сделает себе ее копию и увезет с собой? А какова вероятность того, что машина бесследно исчезнет прямо у вас на глазах? А того, что вы сядете в бмв, а приехав на место назначения выйдите из запорожца? А того, что кто-то попросит вас дать ему машину на пару часов, вы ему 100% ее дадите, потому что не можете иначе по физическим законам этого мира, а он задавит на ней десяток человек и обвинят в этом вас, т.к. он будет все отрицать? А того, что вашу машину примут за машину террориста №1 и на этом основании посадят в кутузку?

Я только что перечислил все угрозы по STRIDE, если что. Похоже на случаи из реального мира? По-моему не очень

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

A>Если размышлять по теории ИБ то защитить машину не возможно, кроме как удаления ее на бесконечное расстояние,

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

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

И именно поэтому, обеспечение ИБ сводится почти к классическому: "конфиденциально, доступно, целостно — выбери любые два".

Но какое это имеет отношение к javascript?

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

A>Да собственно никто и не говорит что HTML5 не найдет своего применения, конечно когда нужно нарисовать "летающие снежинки", показать видео или прожужжать чтонибудь ( это условно сложность задачи )

Забавно, но именно это говорили в свое время про javascript, пока на нем линуксы и думы не начали запускать

A> то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.

Я не знаю, для кого это ад, но писать UI на http://knockoutjs.com/ — одно удовольствие, флеш там и рядом не стоял. А ведь это даже и не html5...

A>Поэтому как я уже писал в начальном посте HTML5 войдет в жизнь но не так кардинально как об этом некоторые переживают.

Это Google, что-ли? Да пусть переживает, что с того? Среда, в которой развиваются веб-приложения весьма агрессивна. Эдайкий эволюционный рай. И даже Google не сможет протащить туда и удерживать на плаву что-то, что не впишется в эту окружающую среду (wave тому пример). Если html5 выживет, то это здорово, значит мы имеем еще одну технологию, которую можем выбрать. Возможность выбора — это всегда здорово. Если нет, то не он первый, не он последний.

Но, к слову сказать, flash-плеер на javascript+html5 я видел. Весьмо достойно работал. Движка js и рендерилки html5 на flash почему-то до сих пор нет. К чему бы это?

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

g> H>Слабо верится. Либо у первых (Flash, SL) единственная исполняющая среда/платформа (а значит ноль проблем с совместимостью), либо у второго, по меньшей мере, 4 сильных игрока. Как уже сказали, вряд-ли HTML5 уйдет дальше украшательств страничек (которые начнут резать, как и flash-баннеры) и несложных игрушек

g> Она "единственная" только для PC. А сейчас набирает обороты мобильный веб, куда пока ни один, ни второй не влез.

Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.

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

A>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек, например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку.

Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.
Удобство разработки же — дело привычки. Насколько я понимаю, вам более привычны .NET/Java — я же их терпеть не могу, и предпочту им динамические JavaScript или Ruby. К тому же, насколько могу судить, флэшевский ActionScript не сильно отличается от JS.

Касаемо контроля за количеством передаваемых параметров — так он делается элементарно:

function foo(a, b) {
  if (arguments.length < foo.length) {
    throw new Error('Too few arguments.');
  }
  console.log(a, b);
}

foo('foo', 'bar'); // foo bar
foo('foo'); // Error: Too few arguments

A>По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>Таким образом разработка на Javascript обойдется очень дорого.

Очень субъективные утверждения. У подхода "любой объект = хэш-таблица" и у прототипного наследования есть много преимуществ — методы в объекты и классы можно добавлять динамически (в том числе и в объекты вроде String, Number, Array, и т.д.). Прототипное наследование же, к примеру, позволяет запросто построить "классическую" модель ООП, включая приватные, защищенные, и абстрактные методы, примеси (которые mixin), и многое другое.

A>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность [...] Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться.

С чего бы они будут плохо укладываться?
JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде.

A>4) Вопрос открытости исходников и безопасности, тут все думаю и так понятно без пояснений, не всем такой вариант подойдет в принципе.

Да, это проблема. С другой стороны — из Flash точно также можно при желании достать код, и если там нет обфускации — то и получить почти в первозданном виде.
К тому же, Google почему-то не боится "открывать" исходники очень многих своих проектов, как то: Google Docs, Google Mail, Google Maps, и так далее. Весь их JS-код доступен — читайте на здоровье. Если получится.

A>Итого мое мнение что с приходом Html5 произойдет небольшое смещение реализации части user-интерфейса в javascript, например красивые меню, интерактивные каталоги, сайты визитки, все что не требует сложной логики, основная логика будет реализовываться по прежнему в сервисах на удобных типизированных и объектно-ориентированных языках.

Нет, это не так.
Во-первых, HTML5 и предлагаемая им парадигма разработки уже пришли — посмотрите на сервисы Гугла. Google Maps — похож ли он на сайт-визитку?
Совсем нет, а ведь это и есть HTML5.
Во-вторых, никто не заставляет писать все на JS — сервер-сайд будет актуален еще очень долгое время. HTML5 пока что лишь удобное средство для создания UI, которое постепенно будет занимать нишу Rich UI (Flex, Silverlight), небольших игр (Flash), и десктопных приложений (.NET, C++, etc.). Если сомневаетесь насчет смещения десктопных приложений — почитайте про Chrome OS.

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

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

A>>2) Javascript это конечно хорошо, на нем конечно можно делать достаточно сложные вещи, вопрос цены.
A>>Отсутствие в этом языке строгой типизации и наличие прочих динамических фишек, например нет контроля за количеством передаваемых параметров, все это приводит в результате к увеличению трудозатрат на отладку.

N>Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.
N>Удобство разработки же — дело привычки. Насколько я понимаю, вам более привычны .NET/Java — я же их терпеть не могу, и предпочту им динамические JavaScript или Ruby. К тому же, насколько могу судить, флэшевский ActionScript не сильно отличается от JS.

N>Касаемо контроля за количеством передаваемых параметров — так он делается элементарно:

N>

N>function foo(a, b) {
N>  if (arguments.length < foo.length) {
N>    throw new Error('Too few arguments.');
N>  }
N>  console.log(a, b);
N>}

N>foo('foo', 'bar'); // foo bar
N>foo('foo'); // Error: Too few arguments
N>

так это и есть увеличение трудозатрат — напиши в каждом методе проверку на количество параметров, напиши проверку на тип параметров, не забудь написать юнит тест на КАЖДОЕ использование этого метода — мы же не хотим чтобы о неправильном количестве переданных параметров узнал конечный пользователь вместо программиста, не забываем затраты на поддержание этого зоопарка в актуальном состоянии (сравни количество действий при добавлении параметра с типизацией и без: в первом случае надо только добавить параметр и пройти по ошибкам компилятора, во втором еще исправить проверки и в ручную найти все обращения)

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


A>>По сути объекты в javascript все имеют один тип Dictionary<string,object> , который заполняется именем поля и значением. Это в целом существенно ухудшает читабельность кода что достаточно существенно замедляет и поддержку и разработку.
A>>Таким образом разработка на Javascript обойдется очень дорого.

N>Очень субъективные утверждения. У подхода "любой объект = хэш-таблица" и у прототипного наследования есть много преимуществ — методы в объекты и классы можно добавлять динамически (в том числе и в объекты вроде String, Number, Array, и т.д.). Прототипное наследование же, к примеру, позволяет запросто построить "классическую" модель ООП, включая приватные, защищенные, и абстрактные методы, примеси (которые mixin), и многое другое.

A>>3) Преимущества ради чего кто-то кинется писать GUI проекты под html5 это кроссплатформенность [...] Что опять сводится к разработке некой общей части с использованием стандартных объектно-ориентированных приемов, тот же полиморфизм, которые в javascript будут очень плохо укладываться.

N>С чего бы они будут плохо укладываться?
N>JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
N>И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде.

как сделать internal protected override член класса? сколько кода тебе на это потребуется? (не забываем, что а нарушении контракта должен узнать программист, а не пользователь)

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

A>> то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.

KV>Я не знаю, для кого это ад, но писать UI на http://knockoutjs.com/ — одно удовольствие, флеш там и рядом не стоял. А ведь это даже и не html5...

а есть real-life примеры использования этого чуда? все что у них на сайте на уровне HelloWorld

Здравствуйте, Евгений Акиньшин, Вы писали:

N>>Касаемо контроля за количеством передаваемых параметров — так он делается элементарно

ЕА>так это и есть увеличение трудозатрат — напиши в каждом методе проверку на количество параметров, напиши проверку на тип параметров

А зачем в каждом методе-то писать одинаковый код?
Для этой цели можно код вынести в обертку, с которой проверка на количество и тип параметров будет выглядеть примерно так:

var Foo = new Class({
  bar : strictArgs([Number, Array], function (foo, bar) {
    console.log([foo, bar]);
  })
});

За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

ЕА> не забудь написать юнит тест на КАЖДОЕ использование этого метода — мы же не хотим чтобы о неправильном количестве переданных параметров узнал конечный пользователь вместо программиста, не забываем затраты на поддержание этого зоопарка в актуальном состоянии (сравни количество действий при добавлении параметра с типизацией и без: в первом случае надо только добавить параметр и пройти по ошибкам компилятора, во втором еще исправить проверки и в ручную найти все обращения)

Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно. А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.

ЕА>ну и выполнятся эти проверки будут в рантайме, что еще сильнее просадет производительность

Да, на проверке типов теряется примерно 20-30% скорости при вызове метода.
В абсолютном значении для нетяжелых вычислений разница небольшая — 2-4 мс.

ЕА>в нарушение всех законов физики, неумолимо приближающуюся к gcc

Каюсь, про приближение к gcc, конечно, преувеличил. И я не уточнил — приближается к gcc производительность в определенных задачах, за счет JIT компиляции.
Но в то же время на данный момент V8 объективно один из лучших по скорости интерпретаторов для скриптовых языков, оставляя Python, Ruby, и PHP далеко позади.

N>>JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
N>>И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде.

ЕА>как сделать internal protected override член класса? сколько кода тебе на это потребуется? (не забываем, что а нарушении контракта должен узнать программист, а не пользователь)

Пожалуйста:

var Foo = new atom.Class({
  bar : atom.Class.protectedMethod(function(msg) {
    console.log(msg);
  }),
  foo : function(msg) {
        this.bar(msg);
  }
});

var Bar = new atom.Class({
  Extends : Foo,
  bar : atom.Class.protectedMethod(function(msg) {
    console.log('Hello, ' + msg + '!');
  })
});

var a = new Foo();
var b = new Bar();

a.bar('world'); // Error: The method «bar» is protected.
b.bar('world'); // -/ /-

a.foo('world'); // Hello
b.foo('world'); // Hello, world!

Теперь у меня встречный вопрос — как средствами самого языка в Java добавить mixin'ы?

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

n> Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.

Конечно, если движки точить на определенные сценарии... Только ведь такие тесты нифига не показывают

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

n>> Лично я не вижу никаких проблем с JavaScript'ом. Скорость работы интерпретируемых движком V8 скриптов уже неумолимо приближается к скорости программ, скомпилированных gcc.

H>Конечно, если движки точить на определенные сценарии... Только ведь такие тесты нифига не показывают

Согласен, приукрасил.
Полагаю, gcc он догоняет за счет JIT оптимизации, которая хорошо ложиться на определенный круг задач. В любом случае, Google V8 невероятно быстр — для Веб-приложений такой скорости вполне достаточно. А ведь его еще периодически улучшают.

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

N>За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

а какого размера проекты писали? Просто у меня даже задачи средней сложности это хотя бы человек 5-ть над кодом в течении хотя бы лет 5-ти работали и это команда хотя бы разок полностью поменялась. В типизированных языках новым людям приходится работать с контрактами


пока проект маленькийи работаешь один и все с памяти держишь — на динамике оно может и быстрее пишется


ЕА>> не забудь написать юнит тест на КАЖДОЕ использование этого метода — мы же не хотим чтобы о неправильном количестве переданных параметров узнал конечный пользователь вместо программиста, не забываем затраты на поддержание этого зоопарка в актуальном состоянии (сравни количество действий при добавлении параметра с типизацией и без: в первом случае надо только добавить параметр и пройти по ошибкам компилятора, во втором еще исправить проверки и в ручную найти все обращения)

N>Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно. А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.

ЕА>>ну и выполнятся эти проверки будут в рантайме, что еще сильнее просадет производительность

N>Да, на проверке типов теряется примерно 20-30% скорости при вызове метода.
N>В абсолютном значении для нетяжелых вычислений разница небольшая — 2-4 мс.

30%(!) — и это только проверки, а еще оверхед для поиска метода по имени итд. итп. Надо совсем никуда не спешить чтобы с этим мириться.

N>Пожалуйста:

N>

N>var Foo = new atom.Class({
N>  bar : atom.Class.protectedMethod(function(msg) {
N>    console.log(msg);
N>  }),
N>  foo : function(msg) {
N>        this.bar(msg);
N>  }
N>});

N>var Bar = new atom.Class({
N>  Extends : Foo,
N>  bar : atom.Class.protectedMethod(function(msg) {
N>    console.log('Hello, ' + msg + '!');
N>  })
N>});

N>var a = new Foo();
N>var b = new Bar();

N>a.bar('world'); // Error: The method «bar» is protected.
N>b.bar('world'); // -/ /-

N>a.foo('world'); // Hello
N>b.foo('world'); // Hello, world!
N>

что protected вижу, а где internal override?
ну опять же единственный способ убедиться, что везде вызвается коректно, написать тесты с 100% покрытием

N>Теперь у меня встречный вопрос — как средствами самого языка в Java добавить mixin'ы?

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

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

N>Полагаю, gcc он догоняет за счет JIT оптимизации, которая хорошо ложиться на определенный круг задач. В любом случае, Google V8 невероятно быстр — для Веб-приложений такой скорости вполне достаточно. А ведь его еще периодически улучшают.

Для веб приложений/UI важно с какой скоростью можно манипулировать DOM моделью. Если рендеринг тормозной то и никакой JIT в JS его не спасет.

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

G>Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.


Ха! Если бы всегда побеждала та технологий, у которой есть преимущества...

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

N>Но в то же время на данный момент V8 объективно один из лучших по скорости интерпретаторов для скриптовых языков, оставляя ... и PHP далеко позади.

О да! Достойный конкурент

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

G>>>http://chrome.angrybirds.com/
A>>Это вообще шикарны пример, который в javascripte создает флеш объект и его подгружает.
G>А developertools говорит что там canvas. Я ему как-то больше доверяю

A>>Если отключить flash то не работает
G>flash там для звуков, это пока "больное место" html5 и js вообще.

Вот оно что! А то у меня без звука ибо FlashBlock. А так да, работает.

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

TK>Для веб приложений/UI важно с какой скоростью можно манипулировать DOM моделью. Если рендеринг тормозной то и никакой JIT в JS его не спасет.

У вас устаревшие данные. JavaScript уже давно шагнул вперед за DOM — поглядите, например, Angry Birds или Linux в браузере — DOM-модель там упоминается разве только в ключе document.getElementById('canvas'). И это не говоря уже о серверном NodeJS, который тоже использует Google V8 — и в котором DOM нет вообще.

Здравствуйте, Евгений Акиньшин, Вы писали:

N>>За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

ЕА>а какого размера проекты писали? Просто у меня даже задачи средней сложности это хотя бы человек 5-ть над кодом в течении хотя бы лет 5-ти работали и это команда хотя бы разок полностью поменялась. В типизированных языках новым людям приходится работать с контрактами

ЕА>пока проект маленькийи работаешь один и все с памяти держишь — на динамике оно может и быстрее пишется

Работал над проектами небольшого размера. Насколько могу судить — для Яваскрипта пока что не очень много таких проектов, чтобы "5 человек в течение 5 лет".

Кстати, совсем забыл — для тех, кому необходимо наличие "protected internal override" и проверки типов существует Google Web Toolkit — он напрямую транслирует код из Java в JavaScript.
Хоть это и костыли, но вполне рабочие и используемые тем же Google'ом.

ЕА>>>ну и выполнятся эти проверки будут в рантайме, что еще сильнее просадет производительность

N>>Да, на проверке типов теряется примерно 20-30% скорости при вызове метода.
N>>В абсолютном значении для нетяжелых вычислений разница небольшая — 2-4 мс.

ЕА>30%(!) — и это только проверки, а еще оверхед для поиска метода по имени итд. итп. Надо совсем никуда не спешить чтобы с этим мириться.

Поэтому по моему скромному мнению стоит использовать проверку типов только там, где это действительно нужно.

ЕА>что protected вижу, а где internal override?

Простите, не знаю, что именно должен делать internal override — но наверняка сэмулировать можно и его. Только тащить всю объектную систему из .NET в JavaScript как минимум странно — настолько же странно, как эмулировать в .NET объектную систему JavaScript, с прототипным наследованием и т.д. А в Python'е по сути нет даже protected и private — и ничего, живут ведь как-то, и не жалуются — такая философия языка.

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

ЕА>ну опять же единственный способ убедиться, что везде вызвается коректно, написать тесты с 100% покрытием

Тесты — да, они ж в любом случае лишними не будут.

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

N>Здравствуйте, Евгений Акиньшин, Вы писали:

N>>>За время программирования на JS лично мне такой проверки не понадобилось почти ни разу.

ЕА>>а какого размера проекты писали? Просто у меня даже задачи средней сложности это хотя бы человек 5-ть над кодом в течении хотя бы лет 5-ти работали и это команда хотя бы разок полностью поменялась. В типизированных языках новым людям приходится работать с контрактами

ЕА>>пока проект маленькийи работаешь один и все с памяти держишь — на динамике оно может и быстрее пишется

N>Работал над проектами небольшого размера. Насколько могу судить — для Яваскрипта пока что не очень много таких проектов, чтобы "5 человек в течение 5 лет".

может поэтому и не много

N>Кстати, совсем забыл — для тех, кому необходимо наличие "protected internal override" и проверки типов существует Google Web Toolkit — он напрямую транслирует код из Java в JavaScript.
N>Хоть это и костыли, но вполне рабочие и используемые тем же Google'ом.

т.е. таки пишем на типизированном языке?

ЕА>>что protected вижу, а где internal override?

N>Простите, не знаю, что именно должен делать internal override — но наверняка сэмулировать можно и его. Только тащить всю объектную систему из .NET в JavaScript как минимум странно — настолько же странно, как эмулировать в .NET объектную систему JavaScript, с прототипным наследованием и т.д. А в Python'е по сути нет даже protected и private — и ничего, живут ведь как-то, и не жалуются — такая философия языка.

N>На мой взгляд для начала стоит разобраться и принять эту самую философию языка, а не тащить привычки с другого. Как говорится, программист на Фортране на любом языке сможет написать программу на Фортране.

я собственно спорил только с утверждением:

N>JS — объектно-ориентированный язык — не побоюсь сказать, даже более объектно-ориентированный, чем та же Java.
N>И все возможности по инкапсуляции, полиморфизму, и наследованию там присутствуют — просто в непривычном виде

а получилось возможности присутствуют не все, полноценно сэмулировать их нельзя
quod erat demonstrandum

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

N>У вас устаревшие данные. JavaScript уже давно шагнул вперед за DOM — поглядите, например, Angry Birds или Linux в браузере — DOM-модель там упоминается разве только в ключе document.getElementById('canvas').

В случае с canvas в первую очередь важна скорость рендеринга — это делается браузером.
Linux в браузере — это технодемо практического использования у нее никакого. Даже если скорость JavaScript будет сравнима со скоростью native кода (возможно, что на каких-то участках она сравнима уже и сейчас), но это не отменят того факта, что в браузере этот язык так и останется скриптом.

N>И это не говоря уже о серверном NodeJS, который тоже использует Google V8 — и в котором DOM нет вообще.

Понятно, что JavaScript как язык можно запихнуть в любую область. Какое это значение имеет в контексте HTML5, Silverlight, Flash?

Здравствуйте, Евгений Акиньшин, Вы писали:

N>>Кстати, совсем забыл — для тех, кому необходимо наличие "protected internal override" и проверки типов существует Google Web Toolkit — он напрямую транслирует код из Java в JavaScript.
N>>Хоть это и костыли, но вполне рабочие и используемые тем же Google'ом.

ЕА>т.е. таки пишем на типизированном языке?

Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык.

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

N>Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно.
Назови хоть один минус статической типизации.

N>А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.
Зачем добавлять метода в рантайм?
Где ты видел pattern matching в жибаскрипте?

N>Каюсь, про приближение к gcc, конечно, преувеличил. И я не уточнил — приближается к gcc производительность в определенных задачах, за счет JIT компиляции.
Она приближается _только_ там где код фактически статически типизированный.

N>Теперь у меня встречный вопрос — как средствами самого языка в Java добавить mixin'ы?
Они есть в скале из коробки. А скала компилируется все в ту же JVM.
В немерле их можно на раз два прикрутить макросами.

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

YKU>Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык.

Так и на голых Java и C# не особо пишут что-то большое. Для большого нужны мощные отлаженные библиотеки, которых под JS может не быть. Тут на помощь и приходят трансляторы.

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

N>>Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно.
WH>Назови хоть один минус статической типизации.

Чрезмерные ограничения.

N>>А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.
WH>Зачем добавлять метода в рантайм?

Для удобства.

WH>Где ты видел pattern matching в жибаскрипте?

Регулярные выражения.

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

YKU>>Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык.
A>Так и на голых Java и C# не особо пишут что-то большое. Для большого нужны мощные отлаженные библиотеки

А библиотеки для них на чём пишутся и отлаживаются?

A>которых под JS может не быть.

Щаз.
Просто проще написать на чём-то удобном, там-же отладить и скрестив пальцы надеяться, что на js оно не изменит поведение чем писать то-же самое на js.

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

WH>>Назови хоть один минус статической типизации.
A>Чрезмерные ограничения.
Их нет.

WH>>Зачем добавлять метода в рантайм?
A>Для удобства.
А конкретно?

WH>>Где ты видел pattern matching в жибаскрипте?
A>Регулярные выражения.
В таком виде "pattern matching" везде есть.

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

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

YKU>>>Угу. На голом js что-то побольше "hello world" писать никому не хочется, вот и рождаются конвертеры с java/C#/.. на "замечательный недооценённый" язык.
A>>Так и на голых Java и C# не особо пишут что-то большое. Для большого нужны мощные отлаженные библиотеки
YKU>А библиотеки для них на чём пишутся и отлаживаются?

Зачем их писать и отлаживать второй раз?

A>>которых под JS может не быть.
YKU>Щаз. Просто проще написать на чём-то удобном, там-же отладить и скрестив пальцы надеяться, что на js оно не изменит поведение чем писать то-же самое на js.

Можно пример библиотеки специально написанной для последующей трансляции в JavaScript и использования именно в таком виде?

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

WH>>>Назови хоть один минус статической типизации.
A>>Чрезмерные ограничения.
WH>Их нет.

Их есть.

WH>>>Зачем добавлять метода в рантайм?
A>>Для удобства.
WH>А конкретно?

Например, решили мы по каким-то причинам изменить поведение объекта.

WH>>>Где ты видел pattern matching в жибаскрипте?
A>>Регулярные выражения.
WH>В таком виде "pattern matching" везде есть.

Ну вот, я ответил на твой вопрос.

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

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

WH>>>>Где ты видел pattern matching в жибаскрипте?
A>>>Регулярные выражения.
WH>>В таком виде "pattern matching" везде есть.

A>Ну вот, я ответил на твой вопрос.

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

В некотором достаточно кастрированном виде он будет в следующей версии JS (Harmony): http://wiki.ecmascript.org/doku.php?id=harmony:destructuring

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

A>Можно пример библиотеки специально написанной для последующей трансляции в JavaScript и использования именно в таком виде?

Это что, попытка уехать во флейм — "это библиотека, а это — нет" что-ли?

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

WH>>>>Назови хоть один минус статической типизации.
A>>>Чрезмерные ограничения.
WH>>Их нет.
A>Их есть.
Аргументации как обычно нет.

A>Например, решили мы по каким-то причинам изменить поведение объекта.
Это не задача. Это деталь реализации конкретного решения.
А если ты сформулируешь исходную задачу, то станет ясно что динамическая типизация для ее решения не нужна.

WH>>В таком виде "pattern matching" везде есть.
A>Ну вот, я ответил на твой вопрос.
Вот только толку от этого нихрена нет.
Ибо вот такой код ты не напишешь.
https://github.com/rsdn/nemerle/blob/master/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n

A>Вот есть Интернет, значимая (а возможно, и большая) часть которого, написана на динамических языках. Чем тебе не задача? Конечно, можно было б всё это написать и на статических языках. Но ведь не написали.
1)Миллион мух это не аргумент.
2)Ты сейчас общаешься на сайте где вся серверная часть написана на статически типизированном языке.

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

H>Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.

На WP7 флэш работает. Говорю как пользователь оного девайса.

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

WH>>>>>Назови хоть один минус статической типизации.
A>>>>Чрезмерные ограничения.
WH>>>Их нет.
A>>Их есть.
WH>Аргументации как обычно нет.

Я вижу.

A>>Например, решили мы по каким-то причинам изменить поведение объекта.
WH>Это не задача. Это деталь реализации конкретного решения.
WH>А если ты сформулируешь исходную задачу, то станет ясно что динамическая типизация для ее решения не нужна.

Да в общем-то и статическая тоже не нужна.

WH>>>В таком виде "pattern matching" везде есть.
A>>Ну вот, я ответил на твой вопрос.
WH>Вот только толку от этого нихрена нет. Ибо вот такой код ты не напишешь.
WH>https://github.com/rsdn/nemerle/blob/master/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n

Вот только толку от такого кода ни хрена нет.

A>>Вот есть Интернет, значимая (а возможно, и большая) часть которого, написана на динамических языках. Чем тебе не задача? Конечно, можно было б всё это написать и на статических языках. Но ведь не написали.
WH>1)Миллион мух это не аргумент.

Ещё какой аргумент. Потому что миллион мух — это практика, которая борет все ваши философствования.

WH>2)Ты сейчас общаешься на сайте где вся серверная часть написана на статически типизированном языке.

А одна муха аргумент? И перечитай, что я написал.

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

A>>Можно пример библиотеки специально написанной для последующей трансляции в JavaScript и использования именно в таком виде?
YKU>Это что, попытка уехать во флейм — "это библиотека, а это — нет" что-ли?

Нет.

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

M>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.

Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.

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

A>Я вижу.
Что ты видишь? Ты выдвинул утверждение вот и доказывай.

A>Да в общем-то и статическая тоже не нужна.
Она сокращает количество ошибок и увеличивает скорость работы по сравнению с динамической типизацией. Значит нужна.

WH>>https://github.com/rsdn/nemerle/blob/master/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
A>Вот только толку от такого кода ни хрена нет.
Напиши короче.

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

A>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle.
Такой pattern matching есть во всех языках семейства ML созданном в 1973 году.

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

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

A>>Я вижу.
WH>Что ты видишь? Ты выдвинул утверждение вот и доказывай.

Что доказать, что статическая типизация меня ограничивает? Клянусь! Теперь опровергай.

A>>Да в общем-то и статическая тоже не нужна.
WH>Она сокращает количество ошибок и увеличивает скорость работы по сравнению с динамической типизацией. Значит нужна.

Есть другие методы сокращения ошибок, скорость устраивает. Значит не нужна.

WH>>>https://github.com/rsdn/nemerle/blob/master/snippets/peg-parser/Nemerle.Peg.Macros/Optimizer/Optimizer.OptimizeRule.n
A>>Вот только толку от такого кода ни хрена нет.
WH>Напиши короче.

Зачем?

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

A>>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle.
WH>Такой pattern matching есть во всех языках семейства ML созданном в 1973 году.

Ну и что?

A>>Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
WH>А мне не нужно сопоставлять строки. Мне нужно сопоставлять деревья.

А мне нужно сопоставлять строки.

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

M> H>Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.

M> На WP7 флэш работает. Говорю как пользователь оного девайса.

О! Long live Flash!

M>>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.

A>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.

Этот паттерн матчинг точно так же реализован в Scala, Erlang'е, Haskell'е. И никакого отношения к регулярным выражениеям не имеет

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

M>>>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
A>>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
M>Этот паттерн матчинг точно так же реализован в Scala, Erlang'е, Haskell'е. И никакого отношения к регулярным выражениеям не имеет

Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?

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

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

H>>Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.

M>На WP7 флэш работает. Говорю как пользователь оного девайса.

В упор его там не наблюдаю (говорю как пользователь ). Но говорят что будет. http://www.wpcentral.com/adobe-name-drops-windows-phone-7-flash-10-1-support-when

M>>>>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
A>>>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
M>>Этот паттерн матчинг точно так же реализован в Scala, Erlang'е, Haskell'е. И никакого отношения к регулярным выражениеям не имеет

A>Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?


Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.

WH>>>Назови хоть один минус статической типизации.
A>>Чрезмерные ограничения.
WH>Их нет.

WH>>>Зачем добавлять метода в рантайм?
A>>Для удобства.
WH>А конкретно?

Так реализуется, грубо говоря, наследование в JS

Стандартный код из ExtJS — это

var new_object_based_on_an_existing_class = Ext.extend(SomeBaseObject, {
    runtime_param1: value1,
    runtime_param2: value2,
    runtime_param3: value3,
    runtime_param4: value4
});

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

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

A>>Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?
M>Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.

Вы можете подразумевать, что угодно под термином «pattern matching», но ваше представление о нём не будет соответствовать действительности, если не включает в себя регулярные выражения.

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

A>>>Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?
M>>Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.

A>Вы можете подразумевать, что угодно под термином «pattern matching», но ваше представление о нём не будет соответствовать действительности, если не включает в себя регулярные выражения.

В Немерле, Хаскеле, Скале, Эрланге есть и решулярные выражения и сопоставление с образцом. То сопоставление, о котором говорим с Wolfhound'ом в JS отсутсвует напрочь

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

Так делать — идиотизм.

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

M>>>Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.
A>>Вы можете подразумевать, что угодно под термином «pattern matching», но ваше представление о нём не будет соответствовать действительности, если не включает в себя регулярные выражения.
M>В Немерле, Хаскеле, Скале, Эрланге есть и решулярные выражения и сопоставление с образцом. То сопоставление, о котором говорим с Wolfhound'ом в JS отсутсвует напрочь

Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.

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

Я это к тому, что сопоставление деревьев и сопоставление последовательностей эквивалентны.

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



N>>>А вот мне с точки зрения любителя функциональных и динамических языков непонятно, как можно жить без возможности pattern matching'а и добавления методов в рантайме.
WH>>Зачем добавлять метода в рантайм?

A>Для удобства.

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

M>>>>Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.
A>>>Вы можете подразумевать, что угодно под термином «pattern matching», но ваше представление о нём не будет соответствовать действительности, если не включает в себя регулярные выражения.
M>>В Немерле, Хаскеле, Скале, Эрланге есть и решулярные выражения и сопоставление с образцом. То сопоставление, о котором говорим с Wolfhound'ом в JS отсутсвует напрочь

A>Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.

Еще раз. Решулярные выражения — это сопоставление с образцом только по тексту. В общем, бурешь в руки http://en.wikipedia.org/wiki/Pattern_matching и выписываешь весь паттерн матчинг, который в JS отсутсвует. Весь этот списко и будет то, что подразумевал Wolfhound


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

A>Я это к тому, что сопоставление деревьев и сопоставление последовательностей эквивалентны.

Даже близко не эквивалентны

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

A>>Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.
M>Еще раз. Решулярные выражения — это сопоставление с образцом только по тексту. В общем, бурешь в руки http://en.wikipedia.org/wiki/Pattern_matching и выписываешь весь паттерн матчинг, который в JS отсутсвует. Весь этот списко и будет то, что подразумевал Wolfhound

Я где-то утверждал, что в JavaScript реализованы все разновидности сопоставления с образцом?

A>>>>И ещё. Тут что, никто не в курсе, что деревья можно однозначно отображать в строки и обратно? И сопоставлять потом с помощью регулярных выражений.
M>>>Так делать — идиотизм.
A>>Я это к тому, что сопоставление деревьев и сопоставление последовательностей эквивалентны.
M>Даже близко не эквивалентны

Это почему же?

Здравствуйте, Евгений Акиньшин, Вы писали:

WH>>>Зачем добавлять метода в рантайм?
A>>Для удобства.
ЕА>Особенно удобно, если два разных программиста добавят к одному и тому же кламму два разных метода с одинаковым именем это офигительно удобно

Да, можно и так. Большая свобода подразумевает большую ответственность.

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

A>Здравствуйте, Евгений Акиньшин, Вы писали:

WH>>>>Зачем добавлять метода в рантайм?
A>>>Для удобства.
ЕА>>Особенно удобно, если два разных программиста добавят к одному и тому же кламму два разных метода с одинаковым именем это офигительно удобно

A>Да, можно и так. Большая свобода подразумевает большую ответственность.

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

A>>>Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.
M>>Еще раз. Решулярные выражения — это сопоставление с образцом только по тексту. В общем, бурешь в руки http://en.wikipedia.org/wiki/Pattern_matching и выписываешь весь паттерн матчинг, который в JS отсутсвует. Весь этот списко и будет то, что подразумевал Wolfhound

A>Я где-то утверждал, что в JavaScript реализованы все разновидности сопоставления с образцом?

Может восстановим контекст подветки, не? Повторю в пятый раз: patern matching в том виде, в котором его понимает Wolfhound и о котором он говорит, в JS ОТСУТСВУЕТ. Это так сложно понять?

A>>>>>И ещё. Тут что, никто не в курсе, что деревья можно однозначно отображать в строки и обратно? И сопоставлять потом с помощью регулярных выражений.
M>>>>Так делать — идиотизм.
A>>>Я это к тому, что сопоставление деревьев и сопоставление последовательностей эквивалентны.
M>>Даже близко не эквивалентны

A>Это почему же?

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

WH>>>>>Зачем добавлять метода в рантайм?
A>>>>Для удобства.
ЕА>>>Особенно удобно, если два разных программиста добавят к одному и тому же кламму два разных метода с одинаковым именем это офигительно удобно

A>>Да, можно и так. Большая свобода подразумевает большую ответственность.

ЕА>Чью ответственность? Вот работают у меня две команды, делают две никак не связанные задачи, как вы предлагаете организовывать процесс?

Так и организовывать. Как буд-то с нет други вещей, которые не могут быть разрулены кроме как административно

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

WH>>>>>>Зачем добавлять метода в рантайм?
A>>>>>Для удобства.
ЕА>>>>Особенно удобно, если два разных программиста добавят к одному и тому же кламму два разных метода с одинаковым именем это офигительно удобно

A>>>Да, можно и так. Большая свобода подразумевает большую ответственность.

ЕА>>Чью ответственность? Вот работают у меня две команды, делают две никак не связанные задачи, как вы предлагаете организовывать процесс?

M>Так и организовывать. Как буд-то с нет други вещей, которые не могут быть разрулены кроме как административно

Угу, как будто мало других вещей, которые не могут быть разрулены кроме как административно, так мы еще и за компьютеры работу делать будем — для удобства

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

A>>>>Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.
M>>>Еще раз. Решулярные выражения — это сопоставление с образцом только по тексту. В общем, бурешь в руки http://en.wikipedia.org/wiki/Pattern_matching и выписываешь весь паттерн матчинг, который в JS отсутсвует. Весь этот списко и будет то, что подразумевал Wolfhound
A>>Я где-то утверждал, что в JavaScript реализованы все разновидности сопоставления с образцом?
M>Может восстановим контекст подветки, не? Повторю в пятый раз: patern matching в том виде, в котором его понимает Wolfhound и о котором он говорит, в JS ОТСУТСВУЕТ. Это так сложно понять?

Я это отрицал? Кажется ты спорил сам с собой.

M>>>Даже близко не эквивалентны
A>>Это почему же?
M>Скажем так, если ты хочешь упаковывать структуру данных в строку, и бегать по ней регулярками? Пожалуйста. Я для того возьму внятные средства для разбора структур данных в виде полноценного сопоставления с образцом.

Как это опровергает эквивалентность?

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

A>Как это опровергает эквивалентность?

В таком разрезе все полные по Тьюрингу языки эквивалентны.

A>>>>>Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.
M>>>>Еще раз. Решулярные выражения — это сопоставление с образцом только по тексту. В общем, бурешь в руки http://en.wikipedia.org/wiki/Pattern_matching и выписываешь весь паттерн матчинг, который в JS отсутсвует. Весь этот списко и будет то, что подразумевал Wolfhound
A>>>Я где-то утверждал, что в JavaScript реализованы все разновидности сопоставления с образцом?
M>>Может восстановим контекст подветки, не? Повторю в пятый раз: patern matching в том виде, в котором его понимает Wolfhound и о котором он говорит, в JS ОТСУТСВУЕТ. Это так сложно понять?

A>Я это отрицал? Кажется ты спорил сам с собой.

Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle.

вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?

Так вот, последний раз (уже устал) patern matching в том виде, в котором его понимает Wolfhound и о котором он говорит, в JS ОТСУТСВУЕТ. А ты зациклился на регулярных выражениях.

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


M>>>>Даже близко не эквивалентны
A>>>Это почему же?
M>>Скажем так, если ты хочешь упаковывать структуру данных в строку, и бегать по ней регулярками? Пожалуйста. Я для того возьму внятные средства для разбора структур данных в виде полноценного сопоставления с образцом.

A>Как это опровергает эквивалентность?

A>>Я это к тому, что сопоставление деревьев и сопоставление последовательностей эквивалентны.

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

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

M>>>Может восстановим контекст подветки, не? Повторю в пятый раз: patern matching в том виде, в котором его понимает Wolfhound и о котором он говорит, в JS ОТСУТСВУЕТ. Это так сложно понять?
A>>Я это отрицал? Кажется ты спорил сам с собой.
M>Регулярные выражения не являются полноценным аналогом сопоставления с образцом. В лучшем случае они являются весьма малой частью этого понятия.

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

M>>>>>Даже близко не эквивалентны
A>>>>Это почему же?
M>>>Скажем так, если ты хочешь упаковывать структуру данных в строку, и бегать по ней регулярками? Пожалуйста. Я для того возьму внятные средства для разбора структур данных в виде полноценного сопоставления с образцом.
A>>Как это опровергает эквивалентность?
M>Ну давай ты напишешь аналог этого регулярными выражениями и мы поговорим об эквивалентности, ок?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

A>>Как это опровергает эквивалентность?
НС>В таком разрезе все полные по Тьюрингу языки эквивалентны.

Ну, так далеко заходить мы не будем.

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

M>Регулярные выражения не являются полноценным аналогом сопоставления с образцом. В лучшем случае они являются весьма малой частью этого понятия.

Зато PM'ом регулярки тоже удобнее разбирать например как тут http://martin.jambon.free.fr/micmatch.html

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

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

Все таки строки это очень узкая разновидность PM и приравнивать их к PM из ML подобных (включая и Хаскель) ФЯ или PM пролога будет неправильно.
Даже если смотреть исторически SNOBOL в котором появился впервые текстовый PM вполне ровесник Рефалу — ФЯ в котором одна из самых
мощных разновидностей PM.

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

A>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом.
FR>Все таки строки это очень узкая разновидность PM и приравнивать их к PM из ML подобных (включая и Хаскель) ФЯ или PM пролога будет неправильно.

Если заглянуть в начало дискуссии, то вопрос стоял такой: есть ли сопоставление с образцом в JavaScript? Ври всей своей «узости» регулярные выражения, на мой взгляд, позволяют ответить на этот вопрос положительно. Однако почему-то у некоторых участников эта мысль вызывает идиосинкразию.

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

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

A>Если заглянуть в начало дискуссии, то вопрос стоял такой: есть ли сопоставление с образцом в JavaScript? Ври всей своей «узости» регулярные выражения, на мой взгляд, позволяют ответить на этот вопрос положительно. Однако почему-то у некоторых участников эта мысль вызывает идиосинкразию.

Тут все просто разные вещи обозначены одним термином. Вообще даже ПМ из ФЯ ПМ из пролога и ПМ из рефала тоже весьма разные вещи.
Чтобы не было спора просто надо назвать все своими именами. Тогда вполне справедливо что ПМ из ФЯ в JavaScript нет.

A>Далее, я ни в коем случае не оспариваю мощности и удобства сопоставления деревьев в отдельных языках. Это однако не исключает того, что подобные вещи можно реализовать путём сравнения последовательностей, хоть и при более громоздкой записи.

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

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

FR>Чтобы не было спора просто надо назвать все своими именами. Тогда вполне справедливо что ПМ из ФЯ в JavaScript нет.

С этим не спорю. Однако подобный pattern matching достаточно легко реализуется имеющимися средствами языка. Например, библиотека match.js позволяет делать так:

var fact = match(
    [0,      function()  { return 1; }],
    [$('n'), function(r) { return r.n * fact(r.n - 1); }]
);

Не слишком красиво и чуть многословно, но всё ж.

Здравствуйте, Евгений Акиньшин, Вы писали:

KV>>Я не знаю, для кого это ад, но писать UI на http://knockoutjs.com/ — одно удовольствие, флеш там и рядом не стоял. А ведь это даже и не html5...
ЕА>а есть real-life примеры использования этого чуда? все что у них на сайте на уровне HelloWorld

Често говоря, real-life примерами я как-то не озадачивался. Мне вполне хватило того, что есть у них на сайте + содержимого пары статей отсюда: http://www.knockmeout.net/

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

WH>Зачем добавлять метода в рантайм?

Кстати, вот одно из применений: http://rsdn.ru/forum/flame.comp/4344821.1.aspx

Автор: anonymous
Дата: 15.07.11

M>>>>Может восстановим контекст подветки, не? Повторю в пятый раз: patern matching в том виде, в котором его понимает Wolfhound и о котором он говорит, в JS ОТСУТСВУЕТ. Это так сложно понять?
A>>>Я это отрицал? Кажется ты спорил сам с собой.
M>>Регулярные выражения не являются полноценным аналогом сопоставления с образцом. В лучшем случае они являются весьма малой частью этого понятия.

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

Мы не сужаем понятие, а расширяем его. По ссылке в википедию ты так и не удосужился пойти.


M>>>>>>Даже близко не эквивалентны
A>>>>>Это почему же?
M>>>>Скажем так, если ты хочешь упаковывать структуру данных в строку, и бегать по ней регулярками? Пожалуйста. Я для того возьму внятные средства для разбора структур данных в виде полноценного сопоставления с образцом.
A>>>Как это опровергает эквивалентность?
M>>Ну давай ты напишешь аналог этого регулярными выражениями и мы поговорим об эквивалентности, ок?

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


Тогда могу ответить только словами

В таком разрезе все полные по Тьюрингу языки эквивалентны.

A>>Если заглянуть в начало дискуссии, то вопрос стоял такой: есть ли сопоставление с образцом в JavaScript? Ври всей своей «узости» регулярные выражения, на мой взгляд, позволяют ответить на этот вопрос положительно. Однако почему-то у некоторых участников эта мысль вызывает идиосинкразию.

FR>Тут все просто разные вещи обозначены одним термином. Вообще даже ПМ из ФЯ ПМ из пролога и ПМ из рефала тоже весьма разные вещи.
FR>Чтобы не было спора просто надо назвать все своими именами. Тогда вполне справедливо что ПМ из ФЯ в JavaScript нет.


Это я говорил 5 или 6 раз. anonymous, что называется, уперся рогом.

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

A>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом.
M>Мы не сужаем понятие, а расширяем его.

Расширяете, выкидывая из понятия разновидность сопоставления — сопоставление с последовательностями?

M>>>>>>>Даже близко не эквивалентны
A>>>>>>Это почему же?
M>Тогда могу ответить только словами

В таком разрезе все полные по Тьюрингу языки эквивалентны.

То есть по существу нет возражений? Хорошо.

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

M>Это я говорил 5 или 6 раз. anonymous, что называется, уперся рогом.

Он не уперся. Это просто стандартный прием демагогии — перевести все на спор о терминах. Нормальных то аргументов нет.

A>>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом.
M>>Мы не сужаем понятие, а расширяем его.

A>Расширяете, выкидывая из понятия разновидность сопоставления — сопоставление с последовательностями?

Никто. Ничего. Не. Выкидывает.

По ссылке в википедии, ты видимо, так и не удосужился пройти. Увы.
В пятидесятый раз. Сопоставления с образцом, о котором говорит Wolfhound, в JS нет. RegExp'ы являются неизмеримо малой частью сопоставления с образцом. Если ты не

Автор: anonymous
Дата: 12.07.11

способен

Автор: anonymous
Дата: 13.07.11

это

Автор: anonymous
Дата: 13.07.11

понять

Автор: anonymous
Дата: 13.07.11

, то о чем вы вообще говорим?

И нет, мы не говорим про «то, что реализовано в Nemerle», как ты выразился. Мы говорим хотя бы про то, что написано по (одной!) ссылке, по которой ты так и не удосужился сходить.

И вообще, Шеридан, перелогинься.

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

A>>>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом.
M>>>Мы не сужаем понятие, а расширяем его.
A>>Расширяете, выкидывая из понятия разновидность сопоставления — сопоставление с последовательностями?
M>Никто. Ничего. Не. Выкидывает.

Но ты же утверждаешь, что в JavaScript нет сопоставления с образцом.

M>По ссылке в википедии, ты видимо, так и не удосужился пройти. Увы.

Почему я должен читать какие-то ссылки, если ты не читаешь мои сообщения?

M>В пятидесятый раз. Сопоставления с образцом, о котором говорит Wolfhound, в JS нет. RegExp'ы являются неизмеримо малой частью сопоставления с образцом. Если ты не

Автор: anonymous
Дата: 12.07.11

способен

Автор: anonymous
Дата: 13.07.11

это

Автор: anonymous
Дата: 13.07.11

понять

Автор: anonymous
Дата: 13.07.11

, то о чем вы вообще говорим?

На это я «в пятидесятый раз» могу заявить, что я этого и не отрицал.

M>И вообще, Шеридан, перелогинься.

Слабый аргумент.

A>>>>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом.
M>>>>Мы не сужаем понятие, а расширяем его.
A>>>Расширяете, выкидывая из понятия разновидность сопоставления — сопоставление с последовательностями?
M>>Никто. Ничего. Не. Выкидывает.

A>Но ты же утверждаешь, что в JavaScript нет сопоставления с образцом.

Где? Ссылку и точную цитату.


M>>По ссылке в википедии, ты видимо, так и не удосужился пройти. Увы.

A>Почему я должен читать какие-то ссылки, если ты не читаешь мои сообщения?

M>>В пятидесятый раз. Сопоставления с образцом, о котором говорит Wolfhound, в JS нет. RegExp'ы являются неизмеримо малой частью сопоставления с образцом. Если ты не

Автор: anonymous
Дата: 12.07.11

способен

Автор: anonymous
Дата: 13.07.11

это

Автор: anonymous
Дата: 13.07.11

понять

Автор: anonymous
Дата: 13.07.11

, то о чем вы вообще говорим?

A>На это я «в пятидесятый раз» могу заявить, что я этого и не отрицал.

Ты это упорно отрицал начиная отсюда: http://rsdn.ru/forum/flame.comp/4340581.1.aspx

Автор: anonymous
Дата: 13.07.11

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

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

A>>Но ты же утверждаешь, что в JavaScript нет сопоставления с образцом.
M>Где? Ссылку и точную цитату.

Ну как же? С самого начала: http://rsdn.ru/forum/flame.comp/4342368.1.aspx

Автор: Mamut
Дата: 14.07.11

, или лучше двумя сообщениями ниже.

— Есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?
— Нет.

A>>На это я «в пятидесятый раз» могу заявить, что я этого и не отрицал.
M>Ты это упорно отрицал начиная отсюда: http://rsdn.ru/forum/flame.comp/4340581.1.aspx

Автор: anonymous
Дата: 13.07.11

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

Ничего подобного. Похоже, ты спорил сам с собой. Бывает.

A>>>Но ты же утверждаешь, что в JavaScript нет сопоставления с образцом.
M>>Где? Ссылку и точную цитату.

A>Ну как же? С самого начала: http://rsdn.ru/forum/flame.comp/4342368.1.aspx

Автор: Mamut
Дата: 14.07.11

, или лучше двумя сообщениями ниже.
A>

A>— Есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?
A>— Нет.

Теперь возбмем другую цитату:

- В Немерле, Хаскеле, Скале, Эрланге есть и решулярные выражения и сопоставление с образцом. То сопоставление, о котором говорим с Wolfhound'ом в JS отсутсвует напрочь

— Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.

Это ли не звиздец?


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

Автор: WolfHound
Дата: 12.07.11

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

Тебя спросили (и потом пятьдесят раз уточняли): есть ли в JS сопоставление с образцом в таком же виде, в каком оно есть в Nemerle/Erlang'е/Scala/Haskell'е. «Дададададада там есть регулярные выражения!!!!одинодинодин»


A>>>На это я «в пятидесятый раз» могу заявить, что я этого и не отрицал.
M>>Ты это упорно отрицал начиная отсюда: http://rsdn.ru/forum/flame.comp/4340581.1.aspx

Автор: anonymous
Дата: 13.07.11

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

A>Ничего подобного. Похоже, ты спорил сам с собой. Бывает.

Ой да ну. Из цитаты выше:

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

Регулярные выражения есть всего лишь часть общего понятия «сопоставление с образцом». То есть {regexp < pattern matching, regexp ⊆ pattern matching }, а ты упорно настаиваешь на том, что regexp === pattern matching.

В JS есть регулярные выражения, но в JS нет сопоставления с образцом:
— в его общем понятии (есть только часть)
— в том виде, в котором его подразумевал WolfHound

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

M>Это ли не звиздец?

То есть всё таки нет в JavaScript сопоставления с образцом? (:

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

Автор: WolfHound
Дата: 12.07.11

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

Я этого не утверждал.

M>Тебя спросили (и потом пятьдесят раз уточняли): есть ли в JS сопоставление с образцом в таком же виде, в каком оно есть в Nemerle/Erlang'е/Scala/Haskell'е. «Дададададада там есть регулярные выражения!!!!одинодинодин»

Я этого не говорил.

A>>Ничего подобного. Похоже, ты спорил сам с собой. Бывает.
M>Ой да ну. Из цитаты выше:
M>

M>Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему.

Регулярные выражения — не сопоставление с образцом?

M>Регулярные выражения есть всего лишь часть общего понятия «сопоставление с образцом». То есть {regexp < pattern matching, regexp ⊆ pattern matching }, а ты упорно настаиваешь на том, что regexp === pattern matching.

Я на этом не настаивал.

M>В JS есть регулярные выражения, но в JS нет сопоставления с образцом:
M>- в его общем понятии (есть только часть)
M>- в том виде, в котором его подразумевал WolfHound

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

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

N>>Не вижу причин присобачивать к динамическому языку костыли в виде системы проверки типов. Тут всего лишь другой подход — у него есть свои плюсы и минусы — так же как и у статически типизированных языков. Если смотреть с точки зрения C#/Java-программиста — то да, без проверки типов жить невозможно.
WH>Назови хоть один минус статической типизации.

Да нет у нее минусов — не о том речь. Это всего лишь другой подход — тут вопрос типа "что лучше — автомобиль или мотоцикл?".
И у того, и у другого есть свои плюсы и свои минусы. Разные инструменты, разные задачи.

Про то я и хочу сказать — не понимаю, зачем приписывать некие "минусы" динамически типизированным языкам.

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

WH>Зачем добавлять метода в рантайм?

Monkey patch.

WH>Где ты видел pattern matching в жибаскрипте?

В данном случае это был просто пример — видел и применял в функциональном Erlang'е.

Я не использую Java/C#/C++/etc. — и не понимаю, для чего мне статическая типизация, когда есть динамическая.
Вы не используете JavaScript/Python/Ruby — и не понимаете, для чего вам динамическая типизация, когда есть статическая.

N>>Каюсь, про приближение к gcc, конечно, преувеличил. И я не уточнил — приближается к gcc производительность в определенных задачах, за счет JIT компиляции.
WH>Она приближается _только_ там где код фактически статически типизированный.

По-моему, в этом случае типизация совсем не причем. Lisp — один из наиболее динамичных языков, однако его реализация SBCL по скорости идет на равне с Java, а местами ее даже уделывает.

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

N>Про то я и хочу сказать — не понимаю, зачем приписывать некие "минусы" динамически типизированным языкам.
Да никто ничего не приписывает.
Тормозит? Да!
Ошибки ловит? Нет!
Полноценную навигацию и рефакторинг сделать можно? Нет!
Что дает? Ничего!

N>Monkey patch.
http://en.wikipedia.org/wiki/Monkey_patch#Pitfalls

N>Я не использую Java/C#/C++/etc. — и не понимаю, для чего мне статическая типизация, когда есть динамическая.
Для скорости, надежности, нормальной IDE,...

N>Вы не используете JavaScript/Python/Ruby — и не понимаете, для чего вам динамическая типизация, когда есть статическая.
Я давно проанализировал все эти языки и понял что от динамики одна головная боль и никакого толка.

N>По-моему, в этом случае типизация совсем не причем. Lisp — один из наиболее динамичных языков, однако его реализация SBCL по скорости идет на равне с Java, а местами ее даже уделывает.
Непонимание матчасти детектед.
Послушай, как мужики сделали V8 быстрым.
http://www.youtube.com/watch?v=FrufJFBSoQY
Первое что они сделали, это начали строить классы, чтобы к полям объекта можно было обращаться по индексу.
А сделать это можно только в тех случаях, когда код фактически статически типизирован.
Ибо если типы будут постоянно меняться эта магия только тормозов добавит.

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

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

N>>Про то я и хочу сказать — не понимаю, зачем приписывать некие "минусы" динамически типизированным языкам.
WH>Да никто ничего не приписывает.
WH>Тормозит? Да!
WH>Ошибки ловит? Нет!
WH>Полноценную навигацию и рефакторинг сделать можно? Нет!
WH>Что дает? Ничего!

+100

я для себя только один юз-кейс нашел — когда требуется ввод логики от конечного пользователя:
во-первых проще обработать все возможные ошибки, чем объяснить не-программистам что вместо (a + b) надо писать (a + (int)b)
во-вторых приходится делать всякие контекстно-зависмые подстановки: опять же например
sum(Order.Lines.Amount)
бизнес пользователю понятно, а Order.Lines.Sum(line => (double)line.Amount) уже не очень.

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

N>>Про то я и хочу сказать — не понимаю, зачем приписывать некие "минусы" динамически типизированным языкам.

WH>Да никто ничего не приписывает.

По-моему, спор "динамические VS статические языки" изначально обречен.
И те, и другие хороши — нет смысла доказывать, что молоток лучше топора.
Но все же попробую ответить на ваши аргументы:

WH>Тормозит? Да!

Нет.

WH>Ошибки ловит? Нет!

Да.
Тот же Erlang можно вполне назвать динамическим языком. Стоит ли напоминать о надежности правильно написанных на нем программ?

WH>Полноценную навигацию и рефакторинг сделать можно? Нет!

Да.
Рефакторинг и паттерны нужны преимущественно для статических языков.
Навигация — без проблем.

N>>Monkey patch.
WH>http://en.wikipedia.org/wiki/Monkey_patch#Pitfalls

Ну и что? Так я могу раз в десять больше способов отстрелить себе ногу в статически типизированном C++ найти.
Но это будет говорить лишь о том, что отстреливать себе ногу не нужно, а нужно писать код с умом и осторожностью.
Обратите внимание на первый же абзац: "carelessly written or poorly documented monkey patches can lead to problems".

N>>Я не использую Java/C#/C++/etc. — и не понимаю, для чего мне статическая типизация, когда есть динамическая.
WH>Для скорости, надежности, нормальной IDE,...

Нормальных, даже отличных IDE в достатке — JetBrains WebStorm/RubyMine/PyCharm, Eclipse, NetBeans.
Для меня же нормальная IDE это REPL + Vim или Emacs.
Про скорость и надежность выше.

N>>Вы не используете JavaScript/Python/Ruby — и не понимаете, для чего вам динамическая типизация, когда есть статическая.
WH>Я давно проанализировал все эти языки и понял что от динамики одна головная боль и никакого толка.

"Я давно проанализировал все эти языки и понял что от статики одна головная боль и никакого толка".
Так мы еще долго сможем спорить.

N>>По-моему, в этом случае типизация совсем не причем. Lisp — один из наиболее динамичных языков, однако его реализация SBCL по скорости идет на равне с Java, а местами ее даже уделывает.

WH>Непонимание матчасти детектед.

Не отрицаю.

WH>Послушай, как мужики сделали V8 быстрым.
WH>http://www.youtube.com/watch?v=FrufJFBSoQY

Послушаю, спасибо! На этот счет отвечу чуть позже.

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

WH>>Тормозит? Да!
N>Нет.
Голословные утверждения.
Если оно в некоторых случаях и сравнимо, то только тогда когда код фактически статически типизирован и компилятору удалось вывести типы.

WH>>Ошибки ловит? Нет!
N>Да.
И где там написано что лисп ловит ошибки?
Нигде.

N>Тот же Erlang можно вполне назвать динамическим языком. Стоит ли напоминать о надежности правильно написанных на нем программ?
ЛОЛ.
Программы на ерланге не надежны, они просто падают и быстренько перезапускаются, делая вид, что ничего не произошло.
И динамическая типизация для этого не нужна.

Она вообще ни для чего не нужна.
Мне так никто и не показал ни одного примера нахрена оно вообще нужно.

WH>>Полноценную навигацию и рефакторинг сделать можно? Нет!
N>Да.
Покажи хоть одну IDE которая не запутается в десятке строк кода.
Таких нет.

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

N>Навигация — без проблем.
Не видел.

N>Ну и что? Так я могу раз в десять больше способов отстрелить себе ногу в статически типизированном C++ найти.
С++ позволяет наплевать на типы.
Так что пример мимо тазика.

N>Но это будет говорить лишь о том, что отстреливать себе ногу не нужно, а нужно писать код с умом и осторожностью.
ЛОЛ. Так никто не делает.
Никто и никогда.

N>Обратите внимание на первый же абзац: "carelessly written or poorly documented monkey patches can lead to problems".
Это 100% кода.
Просто по тому, что люди не железные и постоянно ошибаются.

N>Нормальных, даже отличных IDE в достатке — JetBrains WebStorm/RubyMine/PyCharm, Eclipse, NetBeans.
Путаются в десятке строк кода.

N>Для меня же нормальная IDE это REPL + Vim или Emacs.
Те отсутсвие IDE.

WH>>Непонимание матчасти детектед.
N>Не отрицаю.
А что же тогда в спор влез, если не знаешь, о чем говоришь?

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>я для себя только один юз-кейс нашел — когда требуется ввод логики от конечного пользователя:
ЕА>во-первых проще обработать все возможные ошибки, чем объяснить не-программистам что вместо (a + b) надо писать (a + (int)b)
ЕА>во-вторых приходится делать всякие контекстно-зависмые подстановки: опять же например
ЕА>sum(Order.Lines.Amount)
ЕА>бизнес пользователю понятно, а Order.Lines.Sum(line => (double)line.Amount) уже не очень.
Это ДСЛ обыкновенный.
Причем тут динамическая типизация не ясно.

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

WH>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>я для себя только один юз-кейс нашел — когда требуется ввод логики от конечного пользователя:
ЕА>>во-первых проще обработать все возможные ошибки, чем объяснить не-программистам что вместо (a + b) надо писать (a + (int)b)
ЕА>>во-вторых приходится делать всякие контекстно-зависмые подстановки: опять же например
ЕА>>sum(Order.Lines.Amount)
ЕА>>бизнес пользователю понятно, а Order.Lines.Sum(line => (double)line.Amount) уже не очень.
WH>Это ДСЛ обыкновенный.
WH>Причем тут динамическая типизация не ясно.

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

Здравствуйте, Евгений Акиньшин, Вы писали:

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

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

WH>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>в dsl-х, предназначенных для редактирования енд-юзером приходится приводить типы автоматически за пользователей: если бизнес пользователю хочется складывать апельсины с яблоками, мы попытаемся использовать все возможные способы приведения, и ошибку выдадим, только если уж совсем ничего не получилось
WH>А динамическая типизация то зачем?

а как это сделать статически? например наша программа позволяет пользователю подключится к его данным и выполнить операции над его данными — например подсчитать sum(db.Oranges) + avеrage(db.Apples). Типы известны только в момент подключения к источнику, причем источники могут быть разные с разными тиипами. Т.е. на момент ввода выражений нам надо проверить синтаксис, но проверить совместимость типов мы не можем. Это не динамтическая типизация?

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>а как это сделать статически? например наша программа позволяет пользователю подключится к его данным и выполнить операции над его данными — например подсчитать sum(db.Oranges) + avеrage(db.Apples).
И что должно быть в этом случае?
ИМХО нужно говорить, что так делать нельзя.

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

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

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

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

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

WH>Да никто ничего не приписывает.
WH>Тормозит? Да!
WH>Ошибки ловит? Нет!
WH>Полноценную навигацию и рефакторинг сделать можно? Нет!
WH>Что дает? Ничего!

Плюс там ровно один — пологая learning curve. И именно это привлекает к динамике стада малообразованных программистов.

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

ЕА>>а как это сделать статически? например наша программа позволяет пользователю подключится к его данным и выполнить операции над его данными — например подсчитать sum(db.Oranges) + avеrage(db.Apples).
WH>И что должно быть в этом случае?
WH>ИМХО нужно говорить, что так делать нельзя.

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

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

ага, особенно если на входе строки

к слову сказать, мы-то как раз в большинстве случаев си-шарп для скриптов использовали, так саппортерам иногда приходится объяснять тете Клаве, что вместо a+b надо писать double.Parse(data["a"]) + double.Parse(data["b"])

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>а пользователи говорят что очень хочется и денег платят
Те им хочется считать бессмысленные данные?
Так это же GIGO.

WH>>Те одно выражение пользователь засовывает в разные источники?
WH>>В любом случае типы можно проверить в момент подключения к источнику, а не во время исполнения запроса.
ЕА>ага, особенно если на входе строки
Что за строки?
Что мешает типизировать источник данных?

ЕА>к слову сказать, мы-то как раз в большинстве случаев си-шарп для скриптов использовали, так саппортерам иногда приходится объяснять тете Клаве, что вместо a+b надо писать double.Parse(data["a"]) + double.Parse(data["b"])
То что вы используете непойми что ничего не говорит о том что статика плохая.
Ничто не мешает один раз типизировать источники и писать a+b.

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

WH>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>а пользователи говорят что очень хочется и денег платят
WH>Те им хочется считать бессмысленные данные?
WH>Так это же GIGO.

Это теперь называется "робастность" — небольшое количество мусора на входе не сильно портит конечный результат

WH>>>Те одно выражение пользователь засовывает в разные источники?
WH>>>В любом случае типы можно проверить в момент подключения к источнику, а не во время исполнения запроса.
ЕА>>ага, особенно если на входе строки
WH>Что за строки?
WH>Что мешает типизировать источник данных?

ЕА>>к слову сказать, мы-то как раз в большинстве случаев си-шарп для скриптов использовали, так саппортерам иногда приходится объяснять тете Клаве, что вместо a+b надо писать double.Parse(data["a"]) + double.Parse(data["b"])
WH>То что вы используете непойми что ничего не говорит о том что статика плохая.
WH>Ничто не мешает один раз типизировать источники и писать a+b.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Плюс там ровно один — пологая learning curve. И именно это привлекает к динамике стада малообразованных программистов.

Аха, Perl или Lisp тому пример. (: Прямо сел и начал ваять проекты на тысячи строк.

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

НС>>Плюс там ровно один — пологая learning curve. И именно это привлекает к динамике стада малообразованных программистов.

A>Аха, Perl

Перл — безусловно. Меня посещает дежа вю.

A> или Lisp тому пример.

Лисп — отдельный разговор.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Плюс там ровно один — пологая learning curve. И именно это привлекает к динамике стада малообразованных программистов.
A>>Аха, Perl
НС>Перл — безусловно. Меня посещает дежа вю.

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

A>> или Lisp тому пример.
НС>Лисп — отдельный разговор.

Это ещё почему? И сколько таких исключений?

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

НС>>>>Плюс там ровно один — пологая learning curve. И именно это привлекает к динамике стада малообразованных программистов.
A>>>Аха, Perl
НС>>Перл — безусловно. Меня посещает дежа вю.

A>Если тебе при изучении Perl так показалось, то ты не научился им пользоваться.

Попробуй подумать о том, что означает термин "пологая learning curve"

НС>>Лисп — отдельный разговор.

A>Это ещё почему?

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

A> И сколько таких исключений?

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