Здравствуйте, TK, Вы писали:
TK>>>В случае с canvas в первую очередь важна скорость рендеринга — это делается браузером. G>>А в случае с WebGL ты тоже считаешь, что "это делается браузером"?
TK>Ну, мы же не будем опускаться до того, что рендеринг делается видео-картой?
Почему бы не "опуститься" до того, как в реальности обстоят вещи? При рендеринге canvas, так же как и OpenGL, тебе не надо layout выполнять как это делается для DOM. И "рендеринг" делается именно что видеокартой (пробросом вызовов сквозь API). И скорость рендеринга canvas ограничена в первую очередь скоростью выдачи примитивов, которая в свою очередь, в настоящее время ограничена JavaScript-ом.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Угу, как будто мало других вещей, которые не могут быть разрулены кроме как административно, так мы еще и за компьютеры работу делать будем — для удобства
G>У тебя и в статически типизированном языке надо "разруливать" эту вещь административно. Точно также.
Да пока не приходилось , никто пока не догадался в .net поведение базовых типов из вне угробить
Здравствуйте, Gaperton, Вы писали:
G>Для JS она, разумеется, тоже есть, и наличествует, например, в Google Closure Compiler. И никаких фундаментальных проблем делать это для динамических языков не существует.
Те превращаем динамически типизированный язык в статически типизированный?
А не проще сразу нормальный статически типизированный язык взять?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Валяй, затипизируй в своем любимом Хиндли-Милнере от природы динамические DOM-деревья. Паржом.
Они не от природы динамически типизированные.
А от глупости их создателей.
G>И покажи, чем pattern-matching будет в работе с ними удобнее, чем типичные для JS, насквозь динамические селекторы вида $('.node').
Хочешь сказать что я не смогу типизировать селекторы?
Может ты покажешь задачу где нужна динамическая типизация?
А то я только одно применение знаю. Динамическая загрузка кода. Но и тут достаточно одной проверки при загрузке этого кода, а дальше опять статика пошла.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Почему бы не "опуститься" до того, как в реальности обстоят вещи? При рендеринге canvas, так же как и OpenGL, тебе не надо layout выполнять как это делается для DOM. И "рендеринг" делается именно что видеокартой (пробросом вызовов сквозь API). И скорость рендеринга canvas ограничена в первую очередь скоростью выдачи примитивов, которая в свою очередь, в настоящее время ограничена JavaScript-ом.
Не все так просто... Вызовы canvas можно немедленно транслировать в вызовы API, а можно их накапливать в буфере и рендерить в фоне, script может работать в одном процессе, а рендеринг в другом... Один canvas может отрисовываться поверх другого... Мест, где можно добавить зависимость от браузера полно.
Если же вернуться к начальному топику — практически у всех современных скриптовых языков (JS, AS, C# и т.п) есть JIT и тому подобная ерунда. т.е. в худшем случае, скорость генерации "примитивов" будет у всех примерно одинаковой. А вот для рендеринга/лейаута подобной сходимости пока не видно...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
G>>Почему бы не "опуститься" до того, как в реальности обстоят вещи? При рендеринге canvas, так же как и OpenGL, тебе не надо layout выполнять как это делается для DOM. И "рендеринг" делается именно что видеокартой (пробросом вызовов сквозь API). И скорость рендеринга canvas ограничена в первую очередь скоростью выдачи примитивов, которая в свою очередь, в настоящее время ограничена JavaScript-ом.
TK>Не все так просто... Вызовы canvas можно немедленно транслировать в вызовы API, а можно их накапливать в буфере и рендерить в фоне, script может работать в одном процессе, а рендеринг в другом... Один canvas может отрисовываться поверх другого... Мест, где можно добавить зависимость от браузера полно.
Это все частности и мелочи. Неважно.
TK>Если же вернуться к начальному топику — практически у всех современных скриптовых языков (JS, AS, C# и т.п) есть JIT и тому подобная ерунда. т.е. в худшем случае, скорость генерации "примитивов" будет у всех примерно одинаковой.
Для JS и C# она, естественно, не одинакова. JS медленнее, а еще несколько лет назад он был медленнее раз эдак в 100. Тебе именно об этом выше по ветке собеседник говорит. Он тебе какбэ намекает.
TK> А вот для рендеринга/лейаута подобной сходимости пока не видно...
Отрисовка контента canvas в точных координатах имеет очень мало общего с лейаутом страницы, при котором этих координат нет, и надо определить размеры и взаимное расположение элементов.
Здравствуйте, WolfHound, Вы писали:
G>>Валяй, затипизируй в своем любимом Хиндли-Милнере от природы динамические DOM-деревья. Паржом. WH>Они не от природы динамически типизированные. WH>А от глупости их создателей.
Ну так затипизируй, ты же считаешь себя умнее создателей веб-стандартов. А мы посмотрим, что у тебя получится.
G>>И покажи, чем pattern-matching будет в работе с ними удобнее, чем типичные для JS, насквозь динамические селекторы вида $('.node'). WH>Хочешь сказать что я не смогу типизировать селекторы?
Которые селектят динамический DOM? Для начала тебе придется затипизировать DOM (см. выше). Но я хочу сказать не это, а ровно то, что я сказал. Странно, что ты ищешь какой-то подтекст в простом вопросе.
Покажи, чем pattern-matching будет в работе с ними удобнее, чем типичные для JS, насквозь динамические селекторы вида $('.node'). Мне страшно любопытно.
WH>Может ты покажешь задачу где нужна динамическая типизация?
Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере.
WH>А то я только одно применение знаю. Динамическая загрузка кода. Но и тут достаточно одной проверки при загрузке этого кода, а дальше опять статика пошла.
Динамика выгодна тогда, когда у тебя данные от природы динамические. Это, например, сетевой обмен, и работа с слабоструктурированными данными, вроде DOM-деревьев.
Когда в задаче доминирует работа со слабоструктурированными данными, выгодна "динамическая" семантика по умолчанию, и опциональная статическая типизация.
Здравствуйте, WolfHound, Вы писали:
G>>Для JS она, разумеется, тоже есть, и наличествует, например, в Google Closure Compiler. И никаких фундаментальных проблем делать это для динамических языков не существует. WH>Те превращаем динамически типизированный язык в статически типизированный?
Не совсем так. Семантика все-таки динамическая, суть soft type system в том, что ты ограничиваешь множество возможных вариантов типов для каждого случая настолько сильно, насколько это нужно.
WH>А не проще сразу нормальный статически типизированный язык взять?
Да в общем, нет, не проще. С soft type system ты можешь очень гибко варьировать "строгость" проверок типов по месту. Хочешь — ничего не ограничил. Хочешь — по самое небалуйся утипизировал. Это удобно. Это в использовании удобнее, например, generic-ов.
Но по сути разница между статикой и динамикой этими штуками нивелируется, это да. Настолько, что спорить об этом не имеет смысла.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>>Угу, как будто мало других вещей, которые не могут быть разрулены кроме как административно, так мы еще и за компьютеры работу делать будем — для удобства
G>>У тебя и в статически типизированном языке надо "разруливать" эту вещь административно. Точно также.
ЕА>Да пока не приходилось , никто пока не догадался в .net поведение базовых типов из вне угробить
А это, меж тем, в последних редакциях C# сделать при желании можно.
Здравствуйте, Gaperton, Вы писали:
ЕА>>Да пока не приходилось , никто пока не догадался в .net поведение базовых типов из вне угробить G>А это, меж тем, в последних редакциях C# сделать при желании можно.
Эмм?
class A
{
public object GetTheAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything()
{
Thread.Sleep(TimeSpan.FromYears(7.5 * 1000 * 1000));
return 42;
}
}
class B
{
static void DoSomething(A a)
{
object something = a.GetTheAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything();
// Итак, как нам тут получить нечто, отличное от 42?
}
}
Здравствуйте, Gaperton, Вы писали:
TK>>Не все так просто... Вызовы canvas можно немедленно транслировать в вызовы API, а можно их накапливать в буфере и рендерить в фоне, script может работать в одном процессе, а рендеринг в другом... Один canvas может отрисовываться поверх другого... Мест, где можно добавить зависимость от браузера полно.
G>Это все частности и мелочи. Неважно.
Можно сравнить бенчмарки для FF 3.6 и FF 4.0: http://javierb.com.ar/2011/03/24/firefox4-benchmark/v8benchmark/ vs http://javierb.com.ar/2011/03/24/firefox4-benchmark/v8benchmark/ С одной стороны видно, что производительность JS выросла в 10раз что, дало 1FPS на отрисовку... Тогда как Chrome со сравнимым JS движком имеет в 2 раза больше FPS. Может все таки не в JS дело?
G>Для JS и C# она, естественно, не одинакова. JS медленнее, а еще несколько лет назад он был медленнее раз эдак в 100. Тебе именно об этом выше по ветке собеседник говорит. Он тебе какбэ намекает.
Собеседник выше говорит, что Google V8 невероятно быстр — для Веб-приложений такой скорости вполне достаточно.. А кто с ним спорит?
G>Отрисовка контента canvas в точных координатах имеет очень мало общего с лейаутом страницы, при котором этих координат нет, и надо определить размеры и взаимное расположение элементов.
Если отрисовка контента это такая ерунда то, почему оно так часто тормозит?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Gaperton, Вы писали:
G>Ну так затипизируй, ты же считаешь себя умнее создателей веб-стандартов. А мы посмотрим, что у тебя получится.
Я знаю, что я умнее.
G>Которые селектят динамический DOM? Для начала тебе придется затипизировать DOM (см. выше). Но я хочу сказать не это, а ровно то, что я сказал. Странно, что ты ищешь какой-то подтекст в простом вопросе.
Ошибка была совершена в тот момент, когда сделали динамическим ДОМ.
Пока ее не исправить все навороты будут только ухудшать положение.
G>Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере.
Ни для того ни для другого динамическая типизация не нужна.
Вот, например: http://www.impredicative.com/ur/demo/
Ничего не мешает сделать синтаксис более человечным и засунуть это в браузер.
Как видишь все статически типизировано.
И кода получается меньше чем на HTML+JS+CSS.
G>Динамика выгодна тогда, когда у тебя данные от природы динамические.
Такого не бывает. Никогда.
G>Это, например, сетевой обмен, и работа с слабоструктурированными данными, вроде DOM-деревьев.
И? На одном конце мы сериализуем типизированные данные и на другом десериализуем.
Типы проверяются только в момент загрузки.
Зачем тут динамика?
G>Когда в задаче доминирует работа со слабоструктурированными данными, выгодна "динамическая" семантика по умолчанию, и опциональная статическая типизация.
Таких задач не существует.
Есть решения созданные не от большого ума.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Но по сути разница между статикой и динамикой этими штуками нивелируется, это да. Настолько, что спорить об этом не имеет смысла.
Остается один очень существенный момент.
В случае с нормальной статикой я имею гарантии.
В случае с этой байдой ничего не гарантировано и как следствие все проблемы динамики остаются.
Например, стандартный паттерн рефакторинга кода на статически типизированном языке: поменять сигнатуру и пройтись по ошибкам компилятора.
Работать не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ошибка была совершена в тот момент, когда сделали динамическим ДОМ.
Не для холивара. Как можно добиться
1) Проверки DOM-а на этапе компиляции кода
2) Сохранив возможность произвольно изменять документ, не привлекая программистов
?
Единственный вариант, что я вижу — явно описывать используемые куски документа (необязательно прямо в в документе, достаточно аналога xsd). Но такой подход будет отвратительно уживаться с "живыми" документами, содержимое которых будет зависеть от внешних данных. Получается, что описание схемы сначала начнёт смешиваться с логикой, затем появятся проверки аля
if (reportData.Detailed) { reportDOM.DetailsSection ... }
и в конце-концов мы получим нечто среднее между ExpressionTree шарпа и VisualTree WPF: всё вроде бы и типизированно, но разбирать — удовольствие ниже среднего.
Здравствуйте, Sinix, Вы писали:
ЕА>>>Да пока не приходилось , никто пока не догадался в .net поведение базовых типов из вне угробить G>>А это, меж тем, в последних редакциях C# сделать при желании можно. S>Эмм?
Насколько я припоминаю, можно насовать "расширяющих методов" куда угодно. Точно так же, как надобавлять своих методов в прототипы базовых типов в JS. И точно так же, программист-рукосуй получит в команде за это по рукам, независимо от того, C# это или JS.
А вот сломать при этом поведение даже в JS надо еще постараться.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Gaperton, Вы писали:
G>>Но по сути разница между статикой и динамикой этими штуками нивелируется, это да. Настолько, что спорить об этом не имеет смысла. WH>Остается один очень существенный момент. WH>В случае с нормальной статикой я имею гарантии.
До тех пор, пока не пользуешься типом Object и "динамиками".
WH>В случае с этой байдой ничего не гарантировано и как следствие все проблемы динамики остаются.
В случае с этой "байдой" тебе точно так же, как и в статике, 100% гарантированно, что программа соответствует тайп-констрейнтам, которые ты указал.
WH>Например, стандартный паттерн рефакторинга кода на статически типизированном языке: поменять сигнатуру и пройтись по ошибкам компилятора. WH>Работать не будет.
Естественно будет. И работает. С чего б ему не работать-то?
Кроме того, стандартный паттерн рефакторинга в динамике другой. Поменять сигнатуру, и пройтись по ошибкам юнит-тестов. Это более надежный "паттерн рефакторинга".
Здравствуйте, Sinix, Вы писали:
S>Не для холивара. Как можно добиться S>1) Проверки DOM-а на этапе компиляции кода
А в чем проблема?
S>2) Сохранив возможность произвольно изменять документ, не привлекая программистов Такого не бывает.
S>Единственный вариант, что я вижу — явно описывать используемые куски документа (необязательно прямо в в документе, достаточно аналога xsd). Но такой подход будет отвратительно уживаться с "живыми" документами, содержимое которых будет зависеть от внешних данных. Получается, что описание схемы сначала начнёт смешиваться с логикой, затем появятся проверки аля Re[2]: Веб фрэймворк для Nemerle
Здравствуйте, Gaperton, Вы писали:
G>До тех пор, пока не пользуешься типом Object и "динамиками".
Я ими не пользуюсь.
G>В случае с этой "байдой" тебе точно так же, как и в статике, 100% гарантированно, что программа соответствует тайп-констрейнтам, которые ты указал.
Проблема в том, что их можно и не указать.
А если их указывать везде, то я уж лучше нормальный язык возьму.
G>Кроме того, стандартный паттерн рефакторинга в динамике другой. Поменять сигнатуру, и пройтись по ошибкам юнит-тестов. Это более надежный "паттерн рефакторинга".
1)Юнит тесты ошибки не ловят. Они могут поймать только регрессию.
2)Ты веришь в 100% покрытие? Ну-ну.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Насколько я припоминаю, можно насовать "расширяющих методов" куда угодно. Точно так же, как надобавлять своих методов в прототипы базовых типов в JS. И точно так же, программист-рукосуй получит в команде за это по рукам, независимо от того, C# это или JS.
Методы расширения это чистый сахар для вызова статических методов.
И если случится конфликт то будет ошибка компиляции.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
G>>Ну так затипизируй, ты же считаешь себя умнее создателей веб-стандартов. А мы посмотрим, что у тебя получится. WH>Я знаю, что я умнее.
Не совсем так. Ты уверен, что другие идиоты. Это не одно и то же.
G>>Которые селектят динамический DOM? Для начала тебе придется затипизировать DOM (см. выше). Но я хочу сказать не это, а ровно то, что я сказал. Странно, что ты ищешь какой-то подтекст в простом вопросе. WH>Ошибка была совершена в тот момент, когда сделали динамическим ДОМ. WH>Пока ее не исправить все навороты будут только ухудшать положение.
Правильно-ли я понял, что ты не можешь показать, как затипизировать DOM в Хиндли-Милнере?
Правильно-ли я понимаю, что вырезанный тобой мой вопрос, который я задал дважды (про то, чем pattern-matching лучше JS-ный селекторов), означает, что ты не в состоянии дать на него ответ?
G>>Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере. WH>Ни для того ни для другого динамическая типизация не нужна.
См. выше. Голословные утверждения надоели. Сколько не повторяй "халва", слаще во рту не станет.
WH>Вот, например: http://www.impredicative.com/ur/demo/ WH>Ничего не мешает сделать синтаксис более человечным и засунуть это в браузер. WH>Как видишь все статически типизировано. WH>И кода получается меньше чем на HTML+JS+CSS.
Не вижу здесь динамически обновляемых фрагментов DOM, анимации, и обработки событий, характерных для модели страницы браузера. "Засунуть" это в браузер можно, но получится редкостное убожество, ибо на модель браузера это ни разу не заточено.
Сгенерить аналогичный гуй внутри браузера, воспользовавшись современным JS фреймворком вроде ExtJS, будет куда проще. И кода получится меньше.
G>>Динамика выгодна тогда, когда у тебя данные от природы динамические. WH>Такого не бывает. Никогда.
Любое распределенное приложение (например, работающее с enterprise bus), имеет дело именно с от природы такими данными. Такая ситуация возникает при любом интеропе, где задействован тегированный формат передачи данных.
G>>Это, например, сетевой обмен, и работа с слабоструктурированными данными, вроде DOM-деревьев. WH>И? На одном конце мы сериализуем типизированные данные и на другом десериализуем. WH>Типы проверяются только в момент загрузки. WH>Зачем тут динамика?
Раздербанивая мой текст на абзацы, ты лишаешь себя возможности понять, что я хочу тебе сказать (а это, меж тем, очень простые вещи). Мне приходится повторять по двадцать раз одно и то же. Надоело.
G>>Когда в задаче доминирует работа со слабоструктурированными данными, выгодна "динамическая" семантика по умолчанию, и опциональная статическая типизация. WH>Таких задач не существует.
Ты не веришь в существование слабоструктурированных данных? Забавно.
WH>Есть решения созданные не от большого ума.
Заканчиваем тем, с чего начали. Тебе кажется, что вера в то, что вокруг идиоты, должна автоматически означать, что ты сам большого ума. Это очень забавно.
, никто пока не догадался в .net поведение базовых типов из вне угробить 
А мы посмотрим, что у тебя получится.
Это работа с отрисовкой веб-страницы и сетью в браузере.
Такого не бывает.