Здравствуйте, WolfHound, Вы писали:
G>>До тех пор, пока не пользуешься типом Object и "динамиками". WH>Я ими не пользуюсь.
Ну а интерфейсами, базовыми классами, и generic-ами тоже не пользуешься? Вот там, где ты воткнешь generic, в динамике я опущу спецификацию типа.
G>>В случае с этой "байдой" тебе точно так же, как и в статике, 100% гарантированно, что программа соответствует тайп-констрейнтам, которые ты указал. WH>Проблема в том, что их можно и не указать.
Можно и не указывать. В одном контексте это проблема, в другом — преимущество.
WH>А если их указывать везде, то я уж лучше нормальный язык возьму.
Верно. Если везде — то можно брать статически типизированный язык. Но бывает удобно их указывать не везде.
А что до твоего понятия "нормы" — то я всегда завидовал людям, у которых мир черно-белый без градаций, и двоичный, как единичка или нолик. У меня не так.
G>>Кроме того, стандартный паттерн рефакторинга в динамике другой. Поменять сигнатуру, и пройтись по ошибкам юнит-тестов. Это более надежный "паттерн рефакторинга". WH>1)Юнит тесты ошибки не ловят. Они могут поймать только регрессию.
Тебе кто эту невероятную глупость сказал?
WH>2)Ты веришь в 100% покрытие? Ну-ну.
Я вообще ни во что не верю, я инженер, а не священник. 100% покрытие по функциям я не только видел, но и регулярно делал. 100% покрытия по строкам кода тоже никаких проблем не представляет (если ты используешь let-it-crash с исключениями, а не шпигуешь код ручными проверками корректности на каждый чих). И его гарантированно достаточно для отлова ошибок типизации.
Здравствуйте, Gaperton, Вы писали:
G>Насколько я припоминаю, можно насовать "расширяющих методов" куда угодно.
Нет, при конфликте имён компилятор выберет метод, объявленный в самом объекте. Ув. WolfHound, говоря
И если случится конфликт то будет ошибка компиляции.
очевидно имел в виду не шарп.
static class AExtensions
{
public static void DoSomething(this A a, int b)
{
Console.WriteLine("Not fine at all!");
}
}
class A
{
public void DoSomething(object a)
{
Console.WriteLine("All fine!");
}
}
class Program
{
static void Main(string[] args)
{
new A().DoSomething(123);
Console.ReadKey();
}
}
G>А вот сломать при этом поведение даже в JS надо еще постараться.
Эмм...
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Gaperton, Вы писали:
TK>>>Не все так просто... Вызовы canvas можно немедленно транслировать в вызовы API, а можно их накапливать в буфере и рендерить в фоне, script может работать в одном процессе, а рендеринг в другом... Один canvas может отрисовываться поверх другого... Мест, где можно добавить зависимость от браузера полно.
G>>Это все частности и мелочи. Неважно.
TK>Можно сравнить бенчмарки для FF 3.6 и FF 4.0: TK>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 дело?
Ты дал две одинаковые ссылки. Кроме того, я не вижу ссылки, где есть тест на FPS.
В любом случае, фундаментальных проблем с производительностью отрисовки Canvas нет в любом случае, и то, что она в какой-то конкретной реализации сделана невероятно тормозным образом (что всегда можно сделать) — ничего не меняет.
G>>Для JS и C# она, естественно, не одинакова. JS медленнее, а еще несколько лет назад он был медленнее раз эдак в 100. Тебе именно об этом выше по ветке собеседник говорит. Он тебе какбэ намекает.
TK>Собеседник выше говорит, что Google V8 невероятно быстр — для Веб-приложений такой скорости вполне достаточно.. А кто с ним спорит?
Он тебе говорил, что производительность JS важна не только для манипуляции с DOM. Я же тебе говорю, что отрисовка canvas, так же как и WebGL, не имеет отношения к проблемам рендеринга DOM, это разные задачи.
G>>Отрисовка контента canvas в точных координатах имеет очень мало общего с лейаутом страницы, при котором этих координат нет, и надо определить размеры и взаимное расположение элементов.
TK>Если отрисовка контента это такая ерунда то, почему оно так часто тормозит?
Да разный это контент, понимаешь? Для элементов DOM при рендеринге надо определить размеры и взаимное расположение (т.е. определить координаты, и именно это тормозит, и именно этим браузер в основном и занят), а для Canvas этого делать не надо, там координаты элементов отрисовки наперед известны.
Здравствуйте, WolfHound, Вы писали:
S>>1) Проверки DOM-а на этапе компиляции кода WH>А в чем проблема?
В том, что документ может создаваться динамически и содержимое конкретного блока может зависеть от данных (например, разные шаблоны для "должников" и нормальных пользователей), часть данных может выгребаться из внешних источников — тот же rss — и так далее.
S>>2) Сохранив возможность произвольно изменять документ, не привлекая программистов WH> Такого не бывает.
Ок. Пошёл передавать ребятам, что мы делаем невозможное Если серьёзно — это элементарная фича для отчётов/WPF/форм word-а, да и html-странички нечасто вынуждают изменять поведение ради изменения UI.
S>>Но такой подход будет отвратительно уживаться с "живыми" документами, содержимое которых будет зависеть от внешних данных. WH>Re[2]: Веб фрэймворк для Nemerle
Именно про это я и говорил. Что, если мы генерим часть документа только по какому-то условию, а потом вынуждены с этой частью работать? И чем код выше принципиально отличается от старого доброго ASP.NET MVC с его типичной мешаниной из кода и HTML-я?
S>>Что упустил? WH>То, что изначально нужно проектировать с умом, а не делать как все.
Я ж просил не холиварить
Здравствуйте, Sinix, Вы писали:
S>В том, что документ может создаваться динамически и содержимое конкретного блока может зависеть от данных (например, разные шаблоны для "должников" и нормальных пользователей), часть данных может выгребаться из внешних источников — тот же rss — и так далее.
Все равно не понимаю где ты проблему нашёл.
S>Ок. Пошёл передавать ребятам, что мы делаем невозможное Если серьёзно — это элементарная фича для отчётов/WPF/форм word-а, да и html-странички нечасто вынуждают изменять поведение ради изменения UI.
Те отделения модели от представления?
А причем тут "не привлекая программистов"?
Или ты хочешь сказать что у тебя представление не программисты правят?
S>Именно про это я и говорил. Что, если мы генерим часть документа только по какому-то условию, а потом вынуждены с этой частью работать? И чем код выше принципиально отличается от старого доброго ASP.NET MVC с его типичной мешаниной из кода и HTML-я?
Читай внимательно.
Мы не работаем с документом.
Это просто не нужно.
Он сам перестраивается в тот момент когда меняется модель.
S>Я ж просил не холиварить
Я просто факты констатирую.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>А где здесь ломается "базовый тип"? Речь-то выше по ветке о них.
Ок, неправ
G>А так — да, можно делать. Тока это очень сложно сделать по ошибке, не зная, что делаешь. Практически невозможно.
+1
Здравствуйте, WolfHound, Вы писали:
WH>Все равно не понимаю где ты проблему нашёл.
В том, что схема DOM-а перестаёт быть статически верифицируемой. Поэтому мненя и заинтересовало ваше утверждение:
Ошибка была совершена в тот момент, когда сделали динамическим ДОМ.
Пока ее не исправить все навороты будут только ухудшать положение.
Как исправлять-то?
WH>А причем тут "не привлекая программистов"?
При том, что изменение в документе вовсе необязательно приводят к изменению обрабатывающего его кода. WH>Или ты хочешь сказать что у тебя представление не программисты правят?
Почему? Программисты, только основная работа с UI идёт в Expression Blend, заточенном под дизайнера. В принципе, не проблема отдать на оутсорс/обзавестись профессиональным дизайнером UI, у нас просто масштаб не тот.
WH>Мы не работаем с документом. WH>Это просто не нужно.
Увы, нужно. Например, в клиентском JS, в макросе ворда, внутри behavior-ов WPF. Т.е. в той самой части, которая по своей природе вынуждена иметь дело с динамикой и чью необходимость вы отрицаете.
Здравствуйте, Gaperton, Вы писали:
G>Не совсем так. Ты уверен, что другие идиоты. Это не одно и то же.
Я просто вижу массу ошибок проектирования, из-за которых нужно делать больше чем действительно нужно.
G>Правильно-ли я понял, что ты не можешь показать, как затипизировать DOM в Хиндли-Милнере?
Зачем мне его в Хиндли-Милнере типизировать?
G>Правильно-ли я понимаю, что вырезанный тобой мой вопрос, который я задал дважды (про то, чем pattern-matching лучше JS-ный селекторов), означает, что ты не в состоянии дать на него ответ?
Разные ДСЛ нужны для разных задач.
Я думал такой крутой инженер как ты должен понимать такие банальные вещи.
G>Не вижу здесь динамически обновляемых фрагментов DOM, анимации, и обработки событий, характерных для модели страницы браузера. http://www.impredicative.com/ur/demo/listEdit.html http://www.impredicative.com/ur/demo/increment.html
Про то насколько легко делается общение с сервером я вообще молчу.
G>"Засунуть" это в браузер можно, но получится редкостное убожество, ибо на модель браузера это ни разу не заточено.
То что ты не увидел очевидного говорит лишь о том насколько ты хорошо смотришь.
G>Сгенерить аналогичный гуй внутри браузера, воспользовавшись современным JS фреймворком вроде ExtJS, будет куда проще. И кода получится меньше.
Ну-ну.
G>Любое распределенное приложение (например, работающее с enterprise bus), имеет дело именно с от природы такими данными. Такая ситуация возникает при любом интеропе, где задействован тегированный формат передачи данных.
Достаточно проверки при загрузке.
Динамика не нужна.
G>Раздербанивая мой текст на абзацы, ты лишаешь себя возможности понять, что я хочу тебе сказать (а это, меж тем, очень простые вещи). Мне приходится повторять по двадцать раз одно и то же. Надоело.
Простые и не правильные.
G>Ты не веришь в существование слабоструктурированных данных? Забавно.
Я не верю в то, что данные нельзя типизировать.
Такого не бывает.
G>Заканчиваем тем, с чего начали. Тебе кажется, что вера в то, что вокруг идиоты, должна автоматически означать, что ты сам большого ума. Это очень забавно.
Я тебе показал статически типизированное решение.
Но ты даже не понял, как оно работает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Ну а интерфейсами, базовыми классами, и generic-ами тоже не пользуешься? Вот там, где ты воткнешь generic, в динамике я опущу спецификацию типа.
Оно нихрена не аналог.
G>Можно и не указывать. В одном контексте это проблема, в другом — преимущество.
Контекст, в котором преимущество в студию.
G>А что до твоего понятия "нормы" — то я всегда завидовал людям, у которых мир черно-белый без градаций, и двоичный, как единичка или нолик. У меня не так.
G>Тебе кто эту невероятную глупость сказал?
Это факт.
Все что делают юнит тесты это фиксируют поведение для конкретного набора данных.
Если проблема будет при другом наборе данных, то юнит тест скажет что все хорошо.
Ты же крутой инженер. Что же мне приходится тебе элементарные вещи то объяснять.
G>Я вообще ни во что не верю, я инженер, а не священник. 100% покрытие по функциям я не только видел, но и регулярно делал. 100% покрытия по строкам кода тоже никаких проблем не представляет (если ты используешь let-it-crash с исключениями, а не шпигуешь код ручными проверками корректности на каждый чих). И его гарантированно достаточно для отлова ошибок типизации.
Для этого нужно 100% покрытие по входным данным.
Комбинаторику не забыл?
Прелесть типов в том, что они дают 100% покрытие и по методам и по строкам и данным.
Причем всегда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinix, Вы писали:
S>Увы, нужно. Например, в клиентском JS, в макросе ворда, внутри behavior-ов WPF. Т.е. в той самой части, которая по своей природе вынуждена иметь дело с динамикой и чью необходимость вы отрицаете.
Ох. Я тебе показал код, который делает это не нужным.
Переключись на задачу.
Задача: Сделать динамичный УИ.
Тут нет ни слова на про ДОМ ни про жабаскрипт ни про динамическую типизацию.
Лучший известный мне подход это реактивная ViewModel и описание рендера этой ViewModel.
Как только у нас меняется ViewModel рендер автоматически находит все места, которые нужно исправить.
Никаких селекторов и прочей мути просто не нужно.
Нужно просто решать изначальную задачу.
А не задачу: Как поставить раком жабаскрипт чтобы было не очень больно...
Повторю еще раз: Проблема тут в том, что средства разработки изначально не адекватны для задачи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ох. Я тебе показал код, который делает это не нужным.
Ок, подход понял, спорить о применимости не хочется Спасибо!
Здравствуйте, WolfHound, Вы писали:
G>>Ну а интерфейсами, базовыми классами, и generic-ами тоже не пользуешься? Вот там, где ты воткнешь generic, в динамике я опущу спецификацию типа. WH>Оно нихрена не аналог.
Конечно не аналог. Оно лучше и проще.
G>>Можно и не указывать. В одном контексте это проблема, в другом — преимущество. WH>Контекст, в котором преимущество в студию.
Приводил рядом, ты понимать не хочешь, повторять здесь не вижу смысла.
G>>А что до твоего понятия "нормы" — то я всегда завидовал людям, у которых мир черно-белый без градаций, и двоичный, как единичка или нолик. У меня не так.
G>>Тебе кто эту невероятную глупость сказал? WH>Это факт.
Это не "факт", а твое мнение. На факты можно посмотреть, тезисы обосновывают.
WH>Все что делают юнит тесты это фиксируют поведение для конкретного набора данных.
Это уж как напишешь. Но обычно да. И что с того?
WH>Если проблема будет при другом наборе данных, то юнит тест скажет что все хорошо.
Вовсе не обязательно. Это зависит от того, как подобран "тестовый вектор". Который я могу, например, генерировать автоматически, и довольно длинный, проверяя результат инвариантами.
И уж во всяком случае, то что ловит компилятор, юнит тест поймает без проблем. Типы у тебя вообще от набора данных не зависят. Так что не занимайся демагогией, нечего разговор в космические дали уводить.
WH>Ты же крутой инженер. Что же мне приходится тебе элементарные вещи то объяснять.
Наверное, потому, что я, как полагается инженерам (всем, не только крутым) верю только в закон Ома, а все остальное надо проверять, сколь бы "элементарным" оно религиозным деятелям не казалось.
G>>Я вообще ни во что не верю, я инженер, а не священник. 100% покрытие по функциям я не только видел, но и регулярно делал. 100% покрытия по строкам кода тоже никаких проблем не представляет (если ты используешь let-it-crash с исключениями, а не шпигуешь код ручными проверками корректности на каждый чих). И его гарантированно достаточно для отлова ошибок типизации. WH>Для этого нужно 100% покрытие по входным данным. WH>Комбинаторику не забыл?
Нет, для "этого" (если мы говорим о типах, да и обо всем остальном) не нужно 100% покрытие по входным данным. Совершенно надежным является уже 100% покрытие по цикломатике. Достаточно надежным является 100% покрытие по строка кода (тебе все равно придется такое тестовое покрытие организовать даже в "статическом" языке, иначе выйдет, что ты пускаешь в релиз код, который ни разу не запускал).
А на практике 99% ошибок типов ловят самые простые тесты, покрытие которых далеко от надежного.
WH>Прелесть типов в том, что они дают 100% покрытие и по методам и по строкам и данным. WH>Причем всегда.
Да неужели? И что, это "100% покрытие" тебе 100% ошибок ловит, да?
Или нет? А какое же это тогда 100% покрытие? Ты что в эти свои 100% вкладываешь?
Здравствуйте, Gaperton, Вы писали:
G>Не совсем так. Семантика все-таки динамическая, суть soft type system в том, что ты ограничиваешь множество возможных вариантов типов для каждого случая настолько сильно, насколько это нужно.
И чем это отличается от статических систем типов? Там тоже есть наследование контрактов, утиная типизация и тому подобные вещи. Чуть более слабым контролем?
G>Но по сути разница между статикой и динамикой этими штуками нивелируется, это да.
Мне больше нравится вариант шарпа, когда весь динамический шит нужно вводить явно, если уж без него никак.
Здравствуйте, Gaperton, Вы писали:
G>Конечно не аналог. Оно лучше и проще.
G>Приводил рядом, ты понимать не хочешь, повторять здесь не вижу смысла.
Рядом ты сказки рассказывал про то что данные невозможно типизировать.
WH>>Все что делают юнит тесты это фиксируют поведение для конкретного набора данных. G>Это уж как напишешь. Но обычно да. И что с того?
Не обычно, а всегда. Ибо ничего другого просто физически не могут.
WH>>Если проблема будет при другом наборе данных, то юнит тест скажет что все хорошо. G>Вовсе не обязательно. Это зависит от того, как подобран "тестовый вектор". Который я могу, например, генерировать автоматически, и довольно длинный, проверяя результат инвариантами.
И каким же святым духом ты его генерировать собрался?
И сколько это все времени займет?
G>И уж во всяком случае, то что ловит компилятор, юнит тест поймает без проблем. Типы у тебя вообще от набора данных не зависят. Так что не занимайся демагогией, нечего разговор в космические дали уводить.
Ну так тип на то и тип чтобы задать контракт для всех данных.
G>Наверное, потому, что я, как полагается инженерам (всем, не только крутым) верю только в закон Ома, а все остальное надо проверять, сколь бы "элементарным" оно религиозным деятелям не казалось.
Ну-ну. Кто тут верит в то что юнит тесты ошибки ловят?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>>>Плюс там ровно один — пологая learning curve. И именно это привлекает к динамике стада малообразованных программистов. A>>>>Аха, Perl НС>>>Перл — безусловно. Меня посещает дежа вю. A>>Если тебе при изучении Perl так показалось, то ты не научился им пользоваться. НС>Попробуй подумать о том, что означает термин "пологая learning curve"
О, признаю, неправильно понял. Но всё же в случае Perl и Erlang не видно описанных стад, а в случае PHP они есть. Вон и Lisp вдруг в исключениях. Может дело вовсе не в динамике? Потому что с другой стороны есть статические Delphi и клепалки форм для С++.
N>>Тот же Erlang можно вполне назвать динамическим языком. Стоит ли напоминать о надежности правильно написанных на нем программ? WH>ЛОЛ. WH>Программы на ерланге не надежны, они просто падают и быстренько перезапускаются, делая вид, что ничего не произошло.
1. Это чушь (потму что высказанно обобщение, в общем случае это неверно)
2. И что с того?
WH>И динамическая типизация для этого не нужна.
Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо.
Здравствуйте, Ночной Смотрящий, Вы писали:
G>>Не совсем так. Семантика все-таки динамическая, суть soft type system в том, что ты ограничиваешь множество возможных вариантов типов для каждого случая настолько сильно, насколько это нужно.
НС>И чем это отличается от статических систем типов? Там тоже есть наследование контрактов, утиная типизация и тому подобные вещи. Чуть более слабым контролем?
Я же сказал, чем это отличается. Не более слабым контролем, а возможностью произвольно варьировать силу этого контроля для каждого отдельного случая. Что упрощает язык и проектирование на нем, делая ненужными многие языковые навороты, например, generic-и.
G>>Но по сути разница между статикой и динамикой этими штуками нивелируется, это да.
НС>Мне больше нравится вариант шарпа, когда весь динамический шит нужно вводить явно, если уж без него никак.
Если говорить о soft type system, то ты не можешь знать, нравится он тебе или нет, если не попробовал. А рассуждать о (пред)убеждениях мне не интересно.
Такого не бывает.
Если серьёзно — это элементарная фича для отчётов/WPF/форм word-а, да и html-странички нечасто вынуждают изменять поведение ради изменения UI.
