При оценке рисков информационной безопасности распределенных систем (к классу которых относятся и веб-приложения) актуальные угрозы выявляются на основании данных о точках пересечения потоками данных границ доверия компонентов системы. Для веб-приложений одной из таких точек является 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>если будет в открытую на клиенте обращение к некому сервису с передачей параметров авторизации то понятно что ими легко можно воспользоваться.
Если оно будет в открытую с сервера на какой-нибудь внешний сервис, воспользоваться им атакующему будет не особо сложнее.
На самом деле, с т.з. безопасности, используемая клиентская технология не является (и не может являться) фактором, обуславливающим наличие или отсутствие актуальных информационных угроз для всей системы в целом.
Здравствуйте, 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.
Здравствуйте, WolfHound, Вы писали:
A>>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. WH>Такой pattern matching есть во всех языках семейства ML созданном в 1973 году.
Ну и что?
A>>Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления. WH>А мне не нужно сопоставлять строки. Мне нужно сопоставлять деревья.
Здравствуйте, Mamut, Вы писали:
A>>Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет? M>Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.
Вы можете подразумевать, что угодно под термином «pattern matching», но ваше представление о нём не будет соответствовать действительности, если не включает в себя регулярные выражения.
И ещё. Тут что, никто не в курсе, что деревья можно однозначно отображать в строки и обратно? И сопоставлять потом с помощью регулярных выражений.
Здравствуйте, 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>т.к. всегда есть риск что желающие даже запутанный лабиринт с десятком замков и вооруженных техникой охранников преодолеют за конечное время.
И именно поэтому, обеспечение ИБ сводится почти к классическому: "конфиденциально, доступно, целостно — выбери любые два".
Здравствуйте, Mamut, Вы писали:
M>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
Здравствуйте, nbaksalyar, Вы писали:
N>Полагаю, gcc он догоняет за счет JIT оптимизации, которая хорошо ложиться на определенный круг задач. В любом случае, Google V8 невероятно быстр — для Веб-приложений такой скорости вполне достаточно. А ведь его еще периодически улучшают.
Для веб приложений/UI важно с какой скоростью можно манипулировать DOM моделью. Если рендеринг тормозной то и никакой JIT в JS его не спасет.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, WolfHound, Вы писали:
WH>>>>>Назови хоть один минус статической типизации. A>>>>Чрезмерные ограничения. WH>>>Их нет. A>>Их есть. WH>Аргументации как обычно нет.
Я вижу.
A>>Например, решили мы по каким-то причинам изменить поведение объекта. WH>Это не задача. Это деталь реализации конкретного решения. WH>А если ты сформулируешь исходную задачу, то станет ясно что динамическая типизация для ее решения не нужна.
Вот только толку от такого кода ни хрена нет.
A>>Вот есть Интернет, значимая (а возможно, и большая) часть которого, написана на динамических языках. Чем тебе не задача? Конечно, можно было б всё это написать и на статических языках. Но ведь не написали. WH>1)Миллион мух это не аргумент.
Ещё какой аргумент. Потому что миллион мух — это практика, которая борет все ваши философствования.
WH>2)Ты сейчас общаешься на сайте где вся серверная часть написана на статически типизированном языке.
Здравствуйте, Mamut, Вы писали:
M>>>Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям. A>>Вы можете подразумевать, что угодно под термином «pattern matching», но ваше представление о нём не будет соответствовать действительности, если не включает в себя регулярные выражения. M>В Немерле, Хаскеле, Скале, Эрланге есть и решулярные выражения и сопоставление с образцом. То сопоставление, о котором говорим с Wolfhound'ом в JS отсутсвует напрочь
Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.
A>>И ещё. Тут что, никто не в курсе, что деревья можно однозначно отображать в строки и обратно? И сопоставлять потом с помощью регулярных выражений. M>Так делать — идиотизм.
Я это к тому, что сопоставление деревьев и сопоставление последовательностей эквивалентны.
Есть такое мнение что 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, но это врятли будет частой практикой в коммерческих проектах.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
Здравствуйте, FR, Вы писали:
FR>Чтобы не было спора просто надо назвать все своими именами. Тогда вполне справедливо что ПМ из ФЯ в JavaScript нет.
С этим не спорю. Однако подобный pattern matching достаточно легко реализуется имеющимися средствами языка. Например, библиотека match.js позволяет делать так:
Здравствуйте, 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, хотя как продукт они коммерческой ценности не имеют, т.к. заточены на конкретный банк и использоваться могут только с этим банком, даже было бы банку
выгодно если ошибки могли исправлять сами клиенты, но это не допустимо именно из-за риска что стоимость взлома и подмены клиента в таком виде существенно снижается.
Также как оставив открытую дверь в машине вероятность того что кто-то в нее залезет намного выше, чем если дверь будет закрыта, не смотря на то что разбить стекло не намного тяжелее чем открыть дверь за ручку. Если размышлять по теории ИБ то защитить машину не возможно, кроме как удаления ее на бесконечное расстояние, т.к. всегда есть риск что желающие даже запутанный лабиринт с десятком замков и вооруженных техникой охранников преодолеют за конечное время.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
Здравствуйте, 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 член класса? сколько кода тебе на это потребуется? (не забываем, что а нарушении контракта должен узнать программист, а не пользователь)
Здравствуйте, gandjustas, Вы писали:
g> A>Что я ожидаю я написал в 1м посте в конце А именно то что нифига html5 существенно не изменит, в том числе Flash и Silverlight останутся как основные средства разработки интерактивных интерфейсов.
g> Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.
Слабо верится. Либо у первых (Flash, SL) единственная исполняющая среда/платформа (а значит ноль проблем с совместимостью), либо у второго, по меньшей мере, 4 сильных игрока. Как уже сказали, вряд-ли HTML5 уйдет дальше украшательств страничек (которые начнут резать, как и flash-баннеры) и несложных игрушек
Здравствуйте, WolfHound, Вы писали:
A>>Я вижу. WH>Что ты видишь? Ты выдвинул утверждение вот и доказывай.
Что доказать, что статическая типизация меня ограничивает? Клянусь! Теперь опровергай.
A>>Да в общем-то и статическая тоже не нужна. 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% вкладываешь?
Здравствуйте, WolfHound, Вы писали:
G>>Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка. WH> Ты что в самом деле думал что я не замечу такой дешёвой подтасовки? WH>Ты вызываешь функцию по таймеру. WH>А в оригинальном коде создается два потока.
У меня создается два настоящих потока через HTML5 Web Worker API (Видишь вызов new Worker? Это оно). Внутри каждого из потоков я использую таймер.
Позорище.
G>>Твоя шняга и JSONP-то поди делать не умеет. WH>Он ей не нужен.
Ну естественно. Про same origin security policy и JSONP ты, разумеется, тоже не в курсе.
С пионерами спорь. Пока.
Re[16]: Гы, а Wolfhound — неосилятор, оказывается.
Здравствуйте, WolfHound, Вы писали:
G>>У меня создается два настоящих потока через HTML5 Web Worker API (Видишь вызов new Worker? Это оно). Внутри каждого из потоков я использую таймер. WH>А я что сказал? Ты вызываешь функцию по таймеру.
То же самое происходит и в коде на Ur, даже более примитивно, поскольку настоящих процессов не создаётся.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Это чего, преподносится как что то значимое в общем смысле? Ты же прекрасно понимаешь, что это голимый примитив, никак не демонстрирующий преимуществ динамики.
G>>Ты тред читал? Это ответ на
НС>Читал. Только какой смысл расползаться мыслью по древу?
Я отвечал на зацитированное. Повторил код на мегаязыке, создающий два потока, и, вопреки предположениям, не вспотел. Смысл очень простой — это называется "контрпример".
G>>У тебя еще чего-нибудь?
НС>Ну там в сообщении немного больше было. Но не хочешь отвечать — я не настаиваю.
Да мне не трудно. > И правда, нафига в том же дотнете все эти TPL и Rx с асинками? Написал несколько простеньких хелперов с лямбдами поверх пула потоков и вуаля, все проблемы решены.
Учитывая, что ты при этом не теряешь отладчика в браузере — да, именно так. Вуаля, все проблемы решены. Ну, soft-type checker, вроде того, что есть в Google Closure Compiler еще сильно поможет, да. А в остальном все хорошо.
G>>Не-не-не, не надо никаких sleep-ов никуда втыкать. G>>Повтори вот этот код Worker-а в "потоке" на своем мегаязыке — без delay-ев. WH>Мне еще сколько десятков раз написать, что потоки кооперативные?
Там нет потоков вообще. Там есть только setTimeout и прочая братия.
WH>С другой стороны это дает возможность спокойно работать с данными без плясок с бубном.
В JS тоже можно так работать knockout.js и прочая.
WH>Кстати надеюсь, ты понимаешь, что ничто не мешает скомпилировать этот код так чтобы не было этой проблемы... вспомни, что делает ерланг и скажи, почему это не сможет сделать ур...
Не сможет, потому что ur (ну или то, что в примерах) компилируется в JS.
G>>А что до синхронных вызовов — в настоящих потоках WebWorker я совершенно спокойно могу делать AJAX-вызовы синхронно, не переживай. Это работает без каких-либо дополнительных танцев с бубном. Ничего они мне, кроме того потока, не заблокируют. WH>Не переживай ты так. Вызовы серверного кода в ur все "синхронные". WH>Причем везде. WH>И при этом ничего не тормозиться. WH>Магия, да и только...
function requestUri(xhr, uri, needsSig) {
if (unloading)
return;
xhr.open("POST", uri, true);
Я боюсь тебя разочаровать, но этот параметр означает асинхронный вызов
WH>Повторю еще раз мне все равно во что ур это перепишет. WH>Я прекрасно понимаю, что там получается.
Ага. как ты там говорил. «Настоящие потоки». Сразу видно, как ты это понимаешь, ага
WH>Мне важна модель исполнения самого ур.
Ну да, сферовакуумная модель в вакууме.
Gaperton показал тебе реальную многопоточность в JS безо всяких моделей исполнения.
G>>Этого, ты, разумеется, тоже не знал, да? WH>Да я прекрасно понимаю, что такое этот твой воркер. WH>Похоже, что даже лучше чем ты.
WH>Кстати ты не забыл с чего разговор начался? WH>
WH>>Может ты покажешь задачу где нужна динамическая типизация?
WH>Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере.
WH>Так зачем тут динамическая типизация то? Если насквозь статический ур с этим справляется лучше, чем жабаскрипт не смотря на мегатонны библиотек?
Ага. Аргументы закончились, внезпно надо восстанавливать контекст, который ты сам и забыл со своими примерами. «А вот это вообще делать вспотеешь: http://www.impredicative.com/ur/demo/threads.html», видимо, Гапертон написал...
Здравствуйте, anonymous, Вы писали:
A>А в веб-программировании, как правило, DSL достаточно.
ДСЛ они разные.
WH>>Какими? Что-то knockuot.js они не помогли. Куча мусора в коде. A>Не заметил.
Например, все, что начинается с "ko.", скобки после вызова свойств.
A>Только он мне не нагенерирует клиентов, поэтому пользы от написания клиента и сервера на одном языке никакой.
Да какая ему разница что генерировать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Так как результатом будет все равно JS, возникает вопрос. Что мешает сделать то же самое средствами самого JS?
Клиника.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Ты на РСДНе сколько? Два дня?
НС>В профиль заглянуть сил не хватило?
M>> Тут система форумов расчитана на то, чтобы вести рассуждения на несколько тем сразу.
НС>Демагогия.
M>>Но вы решили этого не делать.
НС>Не надо тут на WH ссылаться, я к нему отношения не имею.
Но мозгов спокойно начать параллеьную ветку с обсуждением именно системы типов, тебе не хватило. Более того, тебе не хватило мозгов задать именно Wolfhound'у вопрос: какое отношение система типов имеет к приведенному им примеру, примерам. Ты решил влезть только тогда, когда вопрос про якобы настоящую многопоточность Ur'а заеш в тупик (благодаря, кстати, Wolfhound'у).
G>>Боишься, что теперь Маммут, как Гапертон, тебя в очередной раз на незнании предмета поймает? Он может. WH>Ну так как признаешь что был не прав или как? WH>
WH>Не вижу здесь динамически обновляемых фрагментов DOM, анимации, и обработки событий, характерных для модели страницы браузера. "Засунуть" это в браузер можно, но получится редкостное убожество, ибо на модель браузера это ни разу не заточено.
Ты мне лучше объясни, почему
M>> Зы. Библиотеку, генерящую исходный HTML+JS и контролирующую все то же можно написать на любом языке программирования
WH> БРЕД!
Правда, тут все просто. Ты идешь по уже проторенной дорожке, которую я как-то описывал. Алгоритм выглядит так:
1. Ты делаешь максимально общее заявление (например, что пример из Ur'а на JS сделать очень сложно)
2. Когда тебе показывают, что ты неправ, ты начинаешь сужать рамки того, что тебе надо. Например (по сужению):
— тебе нужна не настоящая многопоточность, а кооперативная
— тебе нужна не модель асинхронных событий с коллбэками, а непременно хрен знает, что
— тебе не нужны скобочик, тебе нужно без скобочек
3. В тот момент, когда ты сузил свои критерии до одного единственного языка, который соотвествует твоим «критериям» (обычно Немерле, сейчас Ur), ты гордо восклицаешь: «а я же говорил!», и повторяешь тезис из п.1
Несмотря на то, что доказав один единственный специфический частный случай из п.3, ты никаким образом не доказал п.1.
Но, к сожалению, ты не способен это понять, потому что тот самый парадокс блаба в тебе проявляется в максимальной степени.
Что ты там хотел? Рактивное программирование для GWT? Ну есть, например, http://code.google.com/p/reactive4java/ Но ты начнешь рассказывать сказки про скобочки и реальную многопоточность, как пить дать. То, что, при желании, можно написать библиотеку, которая вообще позволит задать все это декларативно (даже в Java) тебе в голову даже и не придет. Если, не дай бог, кто-то найдет и такую библиотеку, ты заузишь задачу еще больше до тех пор, пока не придешь к п.3.
Здравствуйте, Sinix, Вы писали:
S>Увы, нужно. Например, в клиентском JS, в макросе ворда, внутри behavior-ов WPF. Т.е. в той самой части, которая по своей природе вынуждена иметь дело с динамикой и чью необходимость вы отрицаете.
Ох. Я тебе показал код, который делает это не нужным.
Переключись на задачу.
Задача: Сделать динамичный УИ.
Тут нет ни слова на про ДОМ ни про жабаскрипт ни про динамическую типизацию.
Лучший известный мне подход это реактивная ViewModel и описание рендера этой ViewModel.
Как только у нас меняется ViewModel рендер автоматически находит все места, которые нужно исправить.
Никаких селекторов и прочей мути просто не нужно.
Нужно просто решать изначальную задачу.
А не задачу: Как поставить раком жабаскрипт чтобы было не очень больно...
Повторю еще раз: Проблема тут в том, что средства разработки изначально не адекватны для задачи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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, но это врятли будет частой практикой в коммерческих проектах.
Здравствуйте, Mamut, Вы писали:
M>Регулярные выражения не являются полноценным аналогом сопоставления с образцом. В лучшем случае они являются весьма малой частью этого понятия.
Здравствуйте, Евгений Акиньшин, Вы писали:
KV>>Я не знаю, для кого это ад, но писать UI на http://knockoutjs.com/ — одно удовольствие, флеш там и рядом не стоял. А ведь это даже и не html5... ЕА>а есть real-life примеры использования этого чуда? все что у них на сайте на уровне HelloWorld
Често говоря, real-life примерами я как-то не озадачивался. Мне вполне хватило того, что есть у них на сайте + содержимого пары статей отсюда: http://www.knockmeout.net/
Здравствуйте, Mamut, Вы писали:
M>Это ли не звиздец?
То есть всё таки нет в JavaScript сопоставления с образцом? (:
M>Тебе сто раз сказали, что именно мы имеем в виду, а ты продолжал упираться рогом в регулярные выражения. Хотя уже тут
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, Вы писали:
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>Есть решения созданные не от большого ума.
Заканчиваем тем, с чего начали. Тебе кажется, что вера в то, что вокруг идиоты, должна автоматически означать, что ты сам большого ума. Это очень забавно.
Здравствуйте, anonymous, Вы писали:
A>>>почему вспотеешь это делать, WH>>Ну покажи мне клиентскую многопоточность на жабаскрипте.
A>В браузере клиентский код всегда выполняется в один поток. Можно создать лишь эмуляцию многопоточности, например, через setTimeout(), как это делается в примере. Ничего необычного и сложного.
Уже не так. Настоящая многопоточность в браузере есть, с момента появления Web Worker API в HTML5. Рядом я привел пример. И он выглядит попроще, чем этот ужас на мегаязыке.
Здравствуйте, 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) и ничего другого не предвидится.
Здравствуйте, Евгений Акиньшин, Вы писали:
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>Но в то же время на данный момент V8 объективно один из лучших по скорости интерпретаторов для скриптовых языков, оставляя ... и PHP далеко позади.
О да! Достойный конкурент
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, anonymous, Вы писали:
WH>>Назови хоть один минус статической типизации. A>Чрезмерные ограничения.
Их нет.
WH>>Зачем добавлять метода в рантайм? A>Для удобства.
А конкретно?
WH>>Где ты видел pattern matching в жибаскрипте? A>Регулярные выражения.
В таком виде "pattern matching" везде есть.
За все годы, которые я пытаюсь выяснить, для чего нужны динамически типизированные языки мне не показали ни одной задачи, где они давали бы хоть что-то.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>>>>Где ты видел pattern matching в жибаскрипте? A>>>Регулярные выражения. WH>>В таком виде "pattern matching" везде есть.
A>Ну вот, я ответил на твой вопрос.
Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
M>>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет.
A>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
Этот паттерн матчинг точно так же реализован в Scala, Erlang'е, Haskell'е. И никакого отношения к регулярным выражениеям не имеет
Здравствуйте, Mamut, Вы писали:
A>>>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом. M>>>Мы не сужаем понятие, а расширяем его. A>>Расширяете, выкидывая из понятия разновидность сопоставления — сопоставление с последовательностями? M>Никто. Ничего. Не. Выкидывает.
Но ты же утверждаешь, что в JavaScript нет сопоставления с образцом.
M>По ссылке в википедии, ты видимо, так и не удосужился пройти. Увы.
Почему я должен читать какие-то ссылки, если ты не читаешь мои сообщения?
M>В пятидесятый раз. Сопоставления с образцом, о котором говорит Wolfhound, в JS нет. RegExp'ы являются неизмеримо малой частью сопоставления с образцом. Если ты не
Здравствуйте, Mamut, Вы писали:
M>Тебе сто раз сказали, что именно мы имеем в виду, а ты продолжал упираться рогом в регулярные выражения.
Я тебя предупреждал. Он и дальше так же делать будет — ему просто другого не остается. Потому что он давно понял, что не прав, а признаться в этом не может.
Здравствуйте, Gaperton, Вы писали:
G>Не совсем так. Семантика все-таки динамическая, суть soft type system в том, что ты ограничиваешь множество возможных вариантов типов для каждого случая настолько сильно, насколько это нужно.
И чем это отличается от статических систем типов? Там тоже есть наследование контрактов, утиная типизация и тому подобные вещи. Чуть более слабым контролем?
G>Но по сути разница между статикой и динамикой этими штуками нивелируется, это да.
Мне больше нравится вариант шарпа, когда весь динамический шит нужно вводить явно, если уж без него никак.
Здравствуйте, Ночной Смотрящий, Вы писали:
G>>Не совсем так. Семантика все-таки динамическая, суть soft type system в том, что ты ограничиваешь множество возможных вариантов типов для каждого случая настолько сильно, насколько это нужно.
НС>И чем это отличается от статических систем типов? Там тоже есть наследование контрактов, утиная типизация и тому подобные вещи. Чуть более слабым контролем?
Я же сказал, чем это отличается. Не более слабым контролем, а возможностью произвольно варьировать силу этого контроля для каждого отдельного случая. Что упрощает язык и проектирование на нем, делая ненужными многие языковые навороты, например, generic-и.
G>>Но по сути разница между статикой и динамикой этими штуками нивелируется, это да.
НС>Мне больше нравится вариант шарпа, когда весь динамический шит нужно вводить явно, если уж без него никак.
Если говорить о soft type system, то ты не можешь знать, нравится он тебе или нет, если не попробовал. А рассуждать о (пред)убеждениях мне не интересно.
Здравствуйте, Mamut, Вы писали:
M>1. Это чушь (потму что высказанно обобщение, в общем случае это неверно)
Назови мне другой источник "надежности" ерланга.
Ну, хоть один.
M>2. И что с того?
То, что это не надежность, а показуха.
M>Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо.
Это по тому, что среди их клиентов нет людей понимающих плюсы статической типизации.
Просто по тому, что такие люди ерланг не используют.
Но ты можешь повторить эксперимент только сделай опрос среди хаскелистов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>Можно подробнее рассказать, что здесь крутого,
Да много что.
Защита от кучи уязвимостей.
Реактивность.
Клиентская многопоточность.
Прозрачное взаимодействие с сервером.
A>почему вспотеешь это делать,
Ну покажи мне клиентскую многопоточность на жабаскрипте.
A>и вообще, зачем код смешан с разметкой?
По тому, что автор ученый.
Сам язык не мешет писать правильно.
А если над синтаксисом
G>>Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка. WH> Ты что в самом деле думал что я не замечу такой дешёвой подтасовки? WH>Ты вызываешь функцию по таймеру.
Если бы ты прочитал код, то увидел бы, что создается два потока и к ним привязывается хэндлер событий. В потоках по таймауту генерируются события. ТО есть не потоки якобы работают на таймаутах, а внутри самих потоков исполюзуются таймауты, чтобы генерировать события для этого синтетического примера.
Здравствуйте, Mamut, Вы писали:
M>Ты всерьез считаешь, что ur генерирует два настоящих потока в генерируемом им HTML и JS? Извини, но это — бред, с реальностью не имеющий ничего общего. Там точно так же генерируются setTimeout'ы и прочая. Только в них можно сломать голову.
Ты пойми мне абсолютно пофигу что там генерируется.
Мне важно, что есть в исходном коде.
Языки высокого уровня для того и нужны чтобы на ассемблере не писать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Я же сказал, чем это отличается. Не более слабым контролем, а возможностью произвольно варьировать силу этого контроля для каждого отдельного случая.
При развитой статике такая возможность тоже имеется. Утиная типизация та же — пример такой фигни. Принципиальное отличие статики одно — необходимость каких то метаданных для конкретного вызова, чтобы сгенерить машинный код. Но эти метаданные совершенно не обязаны быть жестко структурированными классами.
G> Что упрощает язык и проектирование на нем, делая ненужными многие языковые навороты, например, generic-и.
Дженерики как раз таки обеспечивают очень жесткий контроль, это не движение в направлении его ослабления. И замена дженериков на динамику, это не вопрос инструментария, это вопрос важности статического контроля. Т.е. в итоге все сводится к тому же, с чего начали.
НС>>Мне больше нравится вариант шарпа, когда весь динамический шит нужно вводить явно, если уж без него никак.
G>Если говорить о soft type system, то ты не можешь знать, нравится он тебе или нет, если не попробовал.
А чем шарповые динамики под такое не прокатывают? Где надо, легким движением руки можно перейти к статике. Взгляни пошире — упираться надо не в конкретные решения, а в исходно стоящие проблемы. Тебе пример Ur уже приводили — разберись, для общеобразовательных целей совсем не бесполезно будет.
Вообще, как раз таки баланс и гибкость статического контроля сейчас — острие прогресса в разработке инструментария. Почти все интересные новинки тем или иным способом с этим связаны. И сворачивать его до примитивного статика-динамика — дилетантизм.
Да, чтобы пресечь бесполезный флейм с переходом на личности — пробовал.
G> А рассуждать о (пред)убеждениях мне не интересно.
Здравствуйте, WolfHound, Вы писали:
M>>Ты всерьез считаешь, что ur генерирует два настоящих потока в генерируемом им HTML и JS? Извини, но это — бред, с реальностью не имеющий ничего общего. Там точно так же генерируются setTimeout'ы и прочая. Только в них можно сломать голову. WH>Ты пойми мне абсолютно пофигу что там генерируется. Мне важно, что есть в исходном коде. Языки высокого уровня для того и нужны чтобы на ассемблере не писать.
То есть берём любую обёртку на JavaScript, и задумываемся, зачем нам Ur? Кстати, на какой бы уровень ты не перешёл, не будет настоящих потоков.
Здравствуйте, Mamut, Вы писали:
M>Для ликбеза по selective receive
Не нужен.
M>Что произойдет в случае , если в систему пойдут сообщения в таком порядке, например:
хъ M>в случае твоей линейной системы?
В моем случае будет канал с протоколом и сообщения просто физически не смогут прийти не в том порядке.
Компилятор настучит по голове задолго до того как это произойдет.
См сингулярити.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Если ur будет компилировать во что-то нечто erlang'а — пожалуйста. Пока он компилируется в JS — нереально (ну или нереально до того момента, пока он не начнет использовать workers для настоящих потоков). WH>Ты в самом деле думаешь что я не смогу переписать код в Continuation-passing style и прерывать поток каждые 1000 редукций?
В JS? Посмотрим, как у тебя получится. Более того, почему ты утверждаешь, что нельзя будет сделать точно так же на JS?
M>>Ах, да, я помню. Там еще было «замучаешься писать sleep в потоке на JS» при том, что JS, в который компилируется Ur, это умеет WH>Умеет он это по тому, что переписывает код в жуткую лапшу. Ну, ты ее сам видел. Есть желание самому такой писать? WH>Думаю что нет.
M>>Угу. Про библиотеки Wolfhound все так же не слышал. WH>Библиотеки не убирают весь мусор.
Зависит от библиотеки
M>>Это мне не даст, по сути, ни один язык, кроме java+gwt, так что мимо кассы. WH>Это тебе дает ур/веб.
Да? Где?
WH>Причем в гораздо более лучшем исполнении чем java+gwt.
Не видно этого исполнения даже в упор. Ну, если ты кашу из html'я среди логики и компиляцию в далеко не самый лучший JS называешь гораздо более лучшим исполнением
Кстати. Почему Ur, а не сверхсупермегапуперкрутой Nemerle?
Зы. Библиотеку, генерящую исходный HTML+JS и контролирующую все то же можно написать на любом языке программирования
G>>Я отвечал на зацитированное.
НС>Удивительно вы с Мамутом быстро забыли про контекст разговора.
Ты на РСДНе сколько? Два дня? Тут система форумов расчитана на то, чтобы вести рассуждения на несколько тем сразу. Ничто не мешало ни тебе ни Wolfhound'у параллеельно обсуждению «реальной многопоточности» Ur'а обсуждать типизацию
Но вы решили этого не делать. Как только у вас закончились аргументы про «крутость» Ur'а, вы тут же решили вспомнить контекст
Здравствуйте, WolfHound, Вы писали:
WH>А самое главное ты настырно пытаешься уйти от изначальной темы, ибо понял, что ур с ГУИ справляется лучше, чем жабаскрипт со всеми своими библиотеками и твои утверждения о том, что тут динамика рулит, рассыпались в пыль.
Ur в принципе не может ничего сделать лучше, чем JavaScript, поскольку транслируется в него. Единственное и несущественное его достоинство — он предоставляет привычные средства для некоторых разработчиков.
A>>Ur в принципе не может ничего сделать лучше, чем JavaScript, поскольку транслируется в него. Единственное и несущественное его достоинство — он предоставляет привычные средства для некоторых разработчиков. WH>Конечно же, может. WH>Просто по тому, что в случае с ур нужно писать меньше. WH>Причем не за счет мутных сокращений, а за счет того что решение получается в терминах изначальной задачи (динамический ГУИ).
Борец с синтаксическим оверхедом детектед
A>>А динамика тут вообще не при чём. WH>Ну, так она вообще не нужна. WH>Ибо каждый раз, когда начинаешь разбирать задачу, начиная от изначальной постановки решение на статике, оказывается не хуже. WH>И эта ветка прекрасно это демонстрирует.
M>>Борец с синтаксическим оверхедом детектед WH>Что аргументы совсем закончились?
Не у меня, далеко не у меня.
WH>Запомни: Все языки высокого уровня борются с синтаксическим оверхедом. WH>Борьба с синтаксическим оверхедом это просто смысл существования ЯВУ.
Да, но не в стиле
WH>>Какими? Что-то knockuot.js они не помогли. Куча мусора в коде.
A>Не заметил.
Например, все, что начинается с "ko.", скобки после вызова свойств.
M>>При чем тут статика к конкретно этому примеру? WH>При том, что Гапертон утверждал что я озверею делать этот пример на статике. Как видим не только не озверел, но решение получилось даже лучше чем каноническое на жабоскрипте.
Gaperton:
Не вижу здесь динамически обновляемых фрагментов DOM, анимации, и обработки событий, характерных для модели страницы браузера.
WH>Других задач, где нужна динамика продемонстрировано не было. WH>А раз любители динамики не могут сказать какие же задачи динамика решает лучше чем статика то можно сделать вывод что никакие.
Пока что ты не показал, чем статика круче динамики Конекретно на приведенных примерах
M>>Все, что делает Ur — это генерит HTML+JS. По сути, это DSL для чего-то там. Любой язык, позволяющий создавать DSL'и способен сделать Ur (Lisp, Haskell, Ruby). WH>Другими словами любой язык, который позволяет вмешиваться в работу собственного компилятора/интерпретатора.
M>>Более того, в любом языке с достаточно высокоуровневыми конструкциями (типа ФВП и continuation'ами) достаточно легко сделать библиотеку, генерирующую на выходе HTML+JS и обрабатывающую входящую информацию. Причем эта библиотека (в зависимости от языка) может быть достаточно простой и изящной. WH>Все равно будет тонна синтаксического оверхеда.
Не обязательно
WH>И не будет нормальных проверок.
Теперь полключаем твою любимую статику и?
M>>Гы, чем Ur отличается от любимой Шериданом Kalpa/Vedga? Да ничем WH>Полный звездец. WH>Ур RESTful до мозга костей.
Ты не понял. По сути, шеридановская Kalpa/Vedga реализует все то же, что ты так хотел — все пишется на сервере, все счастливы. Яркий пример того, что можно сделать все, что угодно, с проверками и т.п. даже на таком языке, как С++.
WH>>>Я показываю конкретный пример и прошу его воспроизвести. WH>>>На что мне приводят код, который делает совсем не то, что делает изначальный пример. M>>Ой да ну? WH>Что да ну? Мне вместо простого линейного кода показали лапшу на каллбеках.
Каша там только в твоей голове. А делает этот код, если я не ошибаюсь, то же самое (с разными интервалами выводит на странице текст).
Особой разницы с Ur'ом нет. Единственная «разница» в том, что не явно отправляются сообщения, а вызывается Buffer.write и Buffer.render Пример, описанный Гапертоном более низкоуровневый, что не мешает ео уложить в настолько же прямолинейную обертку
M>>Ну и прочая броедятина в этом стиле показывает, как «хорошо» ты понимаешь, как работает тот же Ur, ага WH>Я то понимаю. А ты? WH>Что такое кооперативная многозадачность знаешь? WH>Или слышишь в первый раз?
Ах, да
Тип многозадачности, при котором следующая задача выполняется только после того, как текущая задача явно объявит себя готовой отдать процессорное время другим задачам.
Недостатки: неспособность всех приложений работать в случае ошибки в одном из них, приводящей к отсутствию вызова операции «отдать процессорное время».
И ты еще утверждаешь, что это гуано лучше, чем полноценная многозадачность, которую привел Gaperton?
И ты еще утверждаешь, что ее же невозможно реализовать средствами JS?
M>>Я уже один раз спрашивал, что именно тебе нужно. Я же говорил, ты намеренно говоришь максимально общими словами, а когда тебя ловят на том, что твои утверждения ложны, начинаешь придумывать все новые и новые рамки, которые в конечном итоге дадут только один язык (сейчас Ur, а обычно — Немерле). WH>Ну значит в жабаскрипте есть паттернмачинг.
То есть, внятно объяснить, что именно тебе надо, ты не в состоянии.
M>>Я продемонстрировал реактивность на Java/GWT Google —> "GWT reactive programming" —> первая ссылка. Теперь это «опять не то» WH>Это такая же реактивность как регексы паттернмачинг.
То есть, внятно объяснить, что именно тебе надо, ты не в состоянии.
M>>Ты отрицаешь возможность создания библиотеки для реактивного программирования для Java вообще и для GWT в частности? WH>Ну с тонной синтаксического (и не только) оверхеда может что-то и получится. Полноту по Тьюрингу ни кто не отменял. Но нахрена оно такое надо? Там же черт ногу сломит.
Пишешь к этому тонкий враппер — и вперед
Напомню контекст. Ты утверждал, что сделать что-то, что делает Ur, билиотекой невозможно. Оказалось, что не только возможно, но и делают. Единственный твой аргумент — это «синтаксический оверхед»
Внятно объяснить, что именно тебе надо, ты не в состоянии. Хотя — нет, можешь даже не утруждать себя. Тебе надо, чтобы оно выглядело, как Ur, вело себя,к ак Ur, и до последней запятой содержало абсолютно точно такое же количество букв, как Ur.
Здравствуйте, Mamut, Вы писали:
WH>>Все равно будет тонна синтаксического оверхеда. M>Не обязательно
Практика показывает что обязательно.
WH>>И не будет нормальных проверок. M>Теперь полключаем твою любимую статику и?
Как? У нас компилятора то нет.
M>Ты не понял. По сути, шеридановская Kalpa/Vedga реализует все то же, что ты так хотел — все пишется на сервере, все счастливы. Яркий пример того, что можно сделать все, что угодно, с проверками и т.п. даже на таком языке, как С++.
Бред.
Ты совершенно не понимаешь что такое ур.
Код пишется на одном языке.
Но выполняется и на клиенте и на сервере.
Ур не пойдет на сервер пока пользователь не захочет то, что без сервера сделать не возможно.
В то время как Kalpa/Vedga ходит на сервер на каждое шевеление мышкой.
M>Каша там только в твоей голове. А делает этот код, если я не ошибаюсь, то же самое (с разными интервалами выводит на странице текст).
Каша там в коде.
У Гапертона два калбека в то время как в оригинале 0.
M>Особой разницы с Ur'ом нет.
Куча лишнего кода на ровном месте это конечно ерунда.
M>Единственная «разница» в том, что не явно отправляются сообщения, а вызывается Buffer.write и Buffer.render
Buffer.render вызывается один раз.
Дальше всю работу делает реактивность.
M>Пример, описанный Гапертоном более низкоуровневый, что не мешает ео уложить в настолько же прямолинейную обертку
Ну попробуй.
M>И ты еще утверждаешь, что это гуано лучше, чем полноценная многозадачность, которую привел Gaperton?
Это "гуано" позволяет писать прямолинейный код без кучи каллбеков.
M>И ты еще утверждаешь, что ее же невозможно реализовать средствами JS?
Без тонный синтаксического оверхеда не получится.
M>То есть, внятно объяснить, что именно тебе надо, ты не в состоянии.
То есть ты не в состоянии посмотреть на то, как работает ур?
Ну посмотри на knockuot.js там реактивность правильная.
Но с кучей синтаксического оверхеда.
M>Напомню контекст. Ты утверждал, что сделать что-то, что делает Ur, билиотекой невозможно. Оказалось, что не только возможно, но и делают. Единственный твой аргумент — это «синтаксический оверхед»
Так это единственный смысл существования яву.
Есть лишь один способ сравнить уровень языков это сравнить сколько кода будет написано при решении одной и той же задачи.
M>Внятно объяснить, что именно тебе надо, ты не в состоянии. Хотя — нет, можешь даже не утруждать себя. Тебе надо, чтобы оно выглядело, как Ur, вело себя,к ак Ur, и до последней запятой содержало абсолютно точно такое же количество букв, как Ur.
Аргументы совсем кончились.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Блин. Причем тут компилятор???? Берешь в руки GWT — у тебя генерируется HTML+JS.
А GWT это что?
M>Добавляешь к нему reactivejava, у тебя есть реактивность. Да еще и со столь любимой тобой статикой
Это не та реактивность.
M>В оригинале там Buffer.write, как минимум
И? Разве это каллбек? Это просто изменяемая структура данных в которую добавляют данные.
M>Которая где-то там упрятана в недрах Ur'а. И? Тебе написать обертку над достаточно низкоуровневым кодом Гапертона религия не позволяет?
Ну, так напиши.
А я похихикаю.
M>runWorkerJS взят отсюда: https://gist.github.com/989438. Код там страшный, потому что в W3C, как всегда, придумали какую-то хрень Код не тестировался, так, для иллюстрации идеи.
Каша и есть каша.
Опять калбеки на ровном месте.
Сколько ты еще будешь в мою пользу код показывать?
M>Достаточно generic обертка будет выглядеть, естественно, по-другому. По сути, runWorkerJs уже достаточно.
Ну, так код без калбеков в студию.
M>Который не будет работать чуть более, чем во всех реальных случаев из-за реализации, но это е тебя не волнует, так ведь
Его можно убить только вечным циклом.
Зачем он нужен в ГУИ?
M>Ну да, я помню, что такое твой синтаксичесий оверхед. Скобочки там, ага
И главное что их нельзя забыть иначе будешь ловить глюки.
И тебе никто об этом не скажет.
M>Смотрю я на Ur. Конкретно в данный момент я смотрю на threads. Ничего сверхъестественного там нет. Ну сахар и сахар Пишешь тонкий враппер над Гапертоновским кодом и радуешься жизни. Если то вообще надо...
Ну так код в студию.
Только чтобы без калбеков.
M>Смотрю на ListEdit. Ну, сигналы/слоты Вау. Это и есть реактивность? А, нет, наверное «реактивность» это установка значений вручную вот так:
Знакомое слово увидел? Зря. Там другая модель.
M>
M><button value="Change to:" onclick={s <- get ss'; set ss s}/>
M>
И как ты собрался не в ручную устанавливать?
Ты вообще понял, что там происходит?
Когда ты правишь текст в текстбоксе то значение автоматически попадает в ss'.
Когда жмешь кнопку это значение перебрасывается в ss.
Далее начинает работать реактивность, обновляя все, что зависит от ss.
M>Вся «реактивность» заключается в сахаре над signal/slots
Манипуляцию с ДОМ видишь?
А она есть.
Ибо реактивность!
M>И этот человек мне говорит, что вот это вот нельзя реализовать в библиотеке для любого серверного языка? Ах, да, signal/slot есть и для JS. Правда, для тебя он будет слишком многословным, видать.
Код в студию.
M>Его не так много, чтобы этого кого-либо парило, кроме тебя
Его достаточно чтобы было верно утверждение что ур лучше жабоскрипта для ГУИ.
M>Самый крутой — мой язык. Там есть одна функция, «сделатьОхрененно()» Я частично согласен с тобой в определении, до тех пор пока это не превращается в абсурд. Потому что бесспорным победителем (на определенном классе задач) выйдет какой-нибудь J.
Хороший калькулятор для одноразовых вычислений.
Вполне себе задача.
M>У тебя — да. Почему реактивнотсь для GWT — это не то, ты так и не объяснил.
По тому, что это совсем другая реактивность.
Это клон мелкософтовского Rx.
Это вообще не о том.
На этой реактивности тебе придется самому с ДОМ возится.
M>Почему невозможно реализовать библиотекой (на Java/C++/Python/Ruby/хрен знает что там еще) то, что реализует Ur, ты так и не объяснил. Твой единственный «аргумент» — это «Без компилятора не получится».
Ну, так код в студию.
Только чтобы без километров синтаксического оверхеда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Добавляешь к нему reactivejava, у тебя есть реактивность. Да еще и со столь любимой тобой статикой WH>Это не та реактивность.
Я так понимаю, в четвертый раз спрашивать, какая именно тебе реактивность смысла нет. Ведь все равно не ответишь.
M>>В оригинале там Buffer.write, как минимум WH>И? Разве это каллбек? Это просто изменяемая структура данных в которую добавляют данные.
Блаб, он и есть блаб. То, что в каком-то другом языке делается что-то не так, все, ты решаешь, что тот язык — гуано.
В случае с Ur'ом ты пишешь структуру, внутри которой пишешь функцию, которая что-то делает. Потом вызываешь эту функцию.
В другом языке ты пишешь функцию, которую передаешь в другую функцию, и она вызывает первую.
M>>Которая где-то там упрятана в недрах Ur'а. И? Тебе написать обертку над достаточно низкоуровневым кодом Гапертона религия не позволяет? WH>Ну, так напиши. WH>А я похихикаю.
M>>runWorkerJS взят отсюда: https://gist.github.com/989438. Код там страшный, потому что в W3C, как всегда, придумали какую-то хрень Код не тестировался, так, для иллюстрации идеи. WH>Каша и есть каша. WH>Опять калбеки на ровном месте.
Достаточно коротко, не находишь? То, что в враппере callback'и тебя интересовать не должно.
Ты пойми мне абсолютно пофигу что там генерируется.
Тебе должно быть пофиг, как оно там реализовано.
WH>Сколько ты еще будешь в мою пользу код показывать? M>>Достаточно generic обертка будет выглядеть, естественно, по-другому. По сути, runWorkerJs уже достаточно. WH>Ну, так код без калбеков в студию.
Что я и говорил. ты все пытаешься свести к тому, чтобы все, абсолютно все выглядело и было реализовано один-в-один ровно так же и точно такими же терминами, словами и буквами, как и (в данном случае Ur| обычно Nemerle).
M>>Который не будет работать чуть более, чем во всех реальных случаев из-за реализации, но это е тебя не волнует, так ведь WH>Его можно убить только вечным циклом. WH>Зачем он нужен в ГУИ?
Не только им. Любым достаточно длинным процессом. Например, синхронным Ajax-вызовом.
M>>Смотрю я на Ur. Конкретно в данный момент я смотрю на threads. Ничего сверхъестественного там нет. Ну сахар и сахар Пишешь тонкий враппер над Гапертоновским кодом и радуешься жизни. Если то вообще надо... WH>Ну так код в студию. WH>Только чтобы без калбеков.
Угу. Я вот боюсь, если вдруг ты ударишься в коллбэки и будешь ьтребовать код только с ними, но ни в коем случае с «просто изменяемой структурой данных в которую добавляют данные»
M>>Смотрю на ListEdit. Ну, сигналы/слоты Вау. Это и есть реактивность? А, нет, наверное «реактивность» это установка значений вручную вот так: WH>Знакомое слово увидел? Зря. Там другая модель.
M>>
M>><button value="Change to:" onclick={s <- get ss'; set ss s}/>
M>>
WH>И как ты собрался не в ручную устанавливать?
Как минимум не напрямю в HTML-коде.
WH>Ты вообще понял, что там происходит? WH>Когда ты правишь текст в текстбоксе то значение автоматически попадает в ss'. WH>Когда жмешь кнопку это значение перебрасывается в ss. WH>Далее начинает работать реактивность, обновляя все, что зависит от ss.
Вау. Да неужели. там работает банальный slot/signal механизм, на который еще подписываться надо вручную:
<dyn signal={showString ss}/>
<dyn signal={show rls}/>
и т.п.
И т.п.
Дадададдада. Это, конечно, В РАЗЫ лучше, чем ko.obervable сотоварищи, ага
M>>Вся «реактивность» заключается в сахаре над signal/slots WH>Манипуляцию с ДОМ видишь? WH>А она есть.
Вау. Покажи мне, где манипуляция DOM'ом, например, в следующем коде:
var w = new Ext.Window();
w.show();
Если библиотека/DSL прячет DOM от тебя, это хорошо, но н является революцией.
WH>Ибо реактивность!
Повтори это заклинание еще пару раз, авось я проникнусь Сигналы и слоты, задаваемые вручную по всему коду, смешанные с HTML'ем — это видимо круто, с твоей точки зрения
M>>И этот человек мне говорит, что вот это вот нельзя реализовать в библиотеке для любого серверного языка? Ах, да, signal/slot есть и для JS. Правда, для тебя он будет слишком многословным, видать. WH>Код в студию.
Код чего?
M>>Его не так много, чтобы этого кого-либо парило, кроме тебя WH>Его достаточно чтобы было верно утверждение что ур лучше жабоскрипта для ГУИ.
БРЕД!
M>>Самый крутой — мой язык. Там есть одна функция, «сделатьОхрененно()» Я частично согласен с тобой в определении, до тех пор пока это не превращается в абсурд. Потому что бесспорным победителем (на определенном классе задач) выйдет какой-нибудь J. WH>Хороший калькулятор для одноразовых вычислений. WH>Вполне себе задача.
M>>У тебя — да. Почему реактивнотсь для GWT — это не то, ты так и не объяснил. WH>По тому, что это совсем другая реактивность.
Какая — другая?
Реактивное программирование — парадигма программирования ориентированная на потоки данных и распространении изменений.
WH>Это клон мелкософтовского Rx. WH>Это вообще не о том. WH>На этой реактивности тебе придется самому с ДОМ возится.
Натягиваем реактивность на существующие классы GWT — и вуаля.
M>>Почему невозможно реализовать библиотекой (на Java/C++/Python/Ruby/хрен знает что там еще) то, что реализует Ur, ты так и не объяснил. Твой единственный «аргумент» — это «Без компилятора не получится». WH>Ну, так код в студию. WH>Только чтобы без километров синтаксического оверхеда.
Что я и говорил. ты все пытаешься свести к тому, чтобы все, абсолютно все выглядело и было реализовано один-в-один ровно так же и точно такими же терминами, словами и буквами, как и (в данном случае Ur| обычно Nemerle).
Но начнем с другого бока. Сначала ты ответишь на мой вопрос, а потом я буду под тебя прогибаться, давай?
Итак, вопрос: Почему невозможно реализовать библиотекой (на Java/C++/Python/Ruby/хрен знает что там еще) то, что реализует Ur?
Здравствуйте, 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.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
Здравствуйте, 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 останутся как основные средства разработки интерактивных интерфейсов.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
Здравствуйте, 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 работает. Только будет чуть красивше.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
Здравствуйте, 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 это не проблема, если будет в открытую на клиенте обращение к некому сервису с передачей параметров авторизации то понятно что ими легко можно воспользоваться.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
Здравствуйте, 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>.
Безотносительно же безопасности, я считаю, что инструмент должен подбираться под задачу и условия, в которых она решается, а не наоборот. И говорить о том, что HTML5 однозначно и всегда кака, не способная заменить Flash и SL везде и во всем, не очень корректно. Например, на ios-based устройствах нет ни флеша не силверлайта, в отличии от. Проблема же полиморфизма в суровых условиях объектов на прототипах (кстати, а почему проблема-то?), может быть решена генерацией клиентских сценариев на стороне сервера под нужную железку, приславшуюю HTTP-запрос. Причем эта генерация может осуществляться на базе кода на вполне себе статически-типизированном языке. Именно этот подход планируется реализовать в Nemerle.WUI и именно он реализован в GWT, где народ пишет себе на Java и Python и даже не вникает, в общем случае, как именно этот код будет преобразован в клиентский js.
Главное, отбросив веру и фанатизм, аргументированно подойти к вопросу выбора технологии и не пихать куда попало html5 также, как и не пытаться до последнего держаться за более зрелые технологии, только потому что они являются таковыми. Если видны бенефиты от использования новой технологии, значит ее стоит использовать. Если они неочевидны или несущественны, то смысла в переходе на нее не будет никакого (искренне ваш, Кэп ).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, ankf, Вы писали:
KV>Безотносительно же безопасности, я считаю, что инструмент должен подбираться под задачу и условия, в которых она решается, а не наоборот. И говорить о том, что HTML5 однозначно и всегда кака, не способная заменить Flash и SL везде и во всем, не очень корректно.
Да собственно никто и не говорит что HTML5 не найдет своего применения, конечно когда нужно нарисовать "летающие снежинки", показать видео или прожужжать чтонибудь ( это условно сложность задачи ) то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.
Поэтому как я уже писал в начальном посте HTML5 войдет в жизнь но не так кардинально как об этом некоторые переживают.
Я программист, я Иван Помидоров, хватить трепатся — наш козырь error.
Здравствуйте, 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>Да собственно никто и не говорит что 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 хз.
Здравствуйте, kochetkov.vladimir, Вы писали:
A>> то тащить флеш с сильверлайтом смысла нет особого, но если что-то более сложное , а как правило толстые клиенты на flash, silverlight достаточно сложны и на языке javascript их писать — это будет ад.
KV>Я не знаю, для кого это ад, но писать UI на http://knockoutjs.com/ — одно удовольствие, флеш там и рядом не стоял. А ведь это даже и не html5...
а есть real-life примеры использования этого чуда? все что у них на сайте на уровне HelloWorld
Здравствуйте, 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'ы?
Здравствуйте, gandjustas, Вы писали:
G>Не останутся, HTML5 их вытеснит нафиг. Нету у SL и Flash значимых преимуществ перед html5, особенно в плане графики.
Ха! Если бы всегда побеждала та технологий, у которой есть преимущества...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, 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.
В немерле их можно на раз два прикрутить макросами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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.
Здравствуйте, 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>За все годы, которые я пытаюсь выяснить, для чего нужны динамически типизированные языки мне не показали ни одной задачи, где они давали бы хоть что-то.
Вот есть Интернет, значимая (а возможно, и большая) часть которого, написана на динамических языках. Чем тебе не задача? Конечно, можно было б всё это написать и на статических языках. Но ведь не написали.
Здравствуйте, 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)Ты сейчас общаешься на сайте где вся серверная часть написана на статически типизированном языке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hattab, Вы писали:
H>Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.
На WP7 флэш работает. Говорю как пользователь оного девайса.
Сложность программы растет до тех пор, пока не превысит способности программиста
Здравствуйте, yoriсk.kiev.ua, Вы писали:
A>>Можно пример библиотеки специально написанной для последующей трансляции в JavaScript и использования именно в таком виде? YKU>Это что, попытка уехать во флейм — "это библиотека, а это — нет" что-ли?
Здравствуйте, anonymous, Вы писали:
A>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle.
Такой pattern matching есть во всех языках семейства ML созданном в 1973 году.
A>Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления.
А мне не нужно сопоставлять строки.
Мне нужно сопоставлять деревья.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Menestrel, Вы писали:
M> H>Flash на мобильных девайсах есть На Андроиде флэш работает, на HP'шном WebOS тоже поддержка есть, на ежевике тоже, для яблы проблема решаемая, WP7 хз.
M> На WP7 флэш работает. Говорю как пользователь оного девайса.
Здравствуйте, 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 флэш работает. Говорю как пользователь оного девайса.
M>>>>Справедливости ради, это не ответ на вопрос. Паттерн матчинга (сопоставления с образцом) в том виде, который подразумевает Wolfhound, в JS нет. A>>>Да, я понимаю, что для него «настоящий» pattern matching — это то, что реализовано в Nemerle. Только это ни разу не отменяет того, что регулярные выражения являются образцами для сопоставления. M>>Этот паттерн матчинг точно так же реализован в Scala, Erlang'е, Haskell'е. И никакого отношения к регулярным выражениеям не имеет
A>Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?
Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.
WH>>>Назови хоть один минус статической типизации. A>>Чрезмерные ограничения. WH>Их нет.
WH>>>Зачем добавлять метода в рантайм? A>>Для удобства. WH>А конкретно?
A>>>Ещё раз спрошу: ну и что, регулярные выражения от этого перестают быть сопоставлением с образцом? Напоминаю, вопрос был: есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет? M>>Нет, потому что pattern matching, который подразумевает WolfHound, не имеет никакого отношения к регулярным выражениям.
A>Вы можете подразумевать, что угодно под термином «pattern matching», но ваше представление о нём не будет соответствовать действительности, если не включает в себя регулярные выражения.
В Немерле, Хаскеле, Скале, Эрланге есть и решулярные выражения и сопоставление с образцом. То сопоставление, о котором говорим с Wolfhound'ом в JS отсутсвует напрочь
A>И ещё. Тут что, никто не в курсе, что деревья можно однозначно отображать в строки и обратно? И сопоставлять потом с помощью регулярных выражений.
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>Скажем так, если ты хочешь упаковывать структуру данных в строку, и бегать по ней регулярками? Пожалуйста. Я для того возьму внятные средства для разбора структур данных в виде полноценного сопоставления с образцом.
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>Ну давай ты напишешь аналог этого регулярными выражениями и мы поговорим об эквивалентности, ок?
Давай, я не буду выполнять твои задания? Если у тебя есть опровержение моих слов, представь его. Только учти, что громоздкость и неудобство сопоставления деревьев через строки не является опровержением.
Здравствуйте, anonymous, Вы писали:
A>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом.
Все таки строки это очень узкая разновидность PM и приравнивать их к PM из ML подобных (включая и Хаскель) ФЯ или PM пролога будет неправильно.
Даже если смотреть исторически SNOBOL в котором появился впервые текстовый PM вполне ровесник Рефалу — ФЯ в котором одна из самых
мощных разновидностей PM.
Здравствуйте, FR, Вы писали:
A>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом. FR>Все таки строки это очень узкая разновидность PM и приравнивать их к PM из ML подобных (включая и Хаскель) ФЯ или PM пролога будет неправильно.
Если заглянуть в начало дискуссии, то вопрос стоял такой: есть ли сопоставление с образцом в JavaScript? Ври всей своей «узости» регулярные выражения, на мой взгляд, позволяют ответить на этот вопрос положительно. Однако почему-то у некоторых участников эта мысль вызывает идиосинкразию.
Далее, я ни в коем случае не оспариваю мощности и удобства сопоставления деревьев в отдельных языках. Это однако не исключает того, что подобные вещи можно реализовать путём сравнения последовательностей, хоть и при более громоздкой записи.
Здравствуйте, anonymous, Вы писали:
A>Если заглянуть в начало дискуссии, то вопрос стоял такой: есть ли сопоставление с образцом в JavaScript? Ври всей своей «узости» регулярные выражения, на мой взгляд, позволяют ответить на этот вопрос положительно. Однако почему-то у некоторых участников эта мысль вызывает идиосинкразию.
Тут все просто разные вещи обозначены одним термином. Вообще даже ПМ из ФЯ ПМ из пролога и ПМ из рефала тоже весьма разные вещи.
Чтобы не было спора просто надо назвать все своими именами. Тогда вполне справедливо что ПМ из ФЯ в JavaScript нет.
A>Далее, я ни в коем случае не оспариваю мощности и удобства сопоставления деревьев в отдельных языках. Это однако не исключает того, что подобные вещи можно реализовать путём сравнения последовательностей, хоть и при более громоздкой записи.
Реализовать конечно можно, но без слез на это смотреть невозможно, ладно еще в питоне на декораторах получается хоть что-то похожее, а тут совсем уж слабое подобие.
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>Тогда могу ответить только словами
В таком разрезе все полные по Тьюрингу языки эквивалентны.
A>>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом. M>>Мы не сужаем понятие, а расширяем его.
A>Расширяете, выкидывая из понятия разновидность сопоставления — сопоставление с последовательностями?
Никто. Ничего. Не. Выкидывает.
По ссылке в википедии, ты видимо, так и не удосужился пройти. Увы.
В пятидесятый раз. Сопоставления с образцом, о котором говорит Wolfhound, в JS нет. RegExp'ы являются неизмеримо малой частью сопоставления с образцом. Если ты не
И нет, мы не говорим про «то, что реализовано в Nemerle», как ты выразился. Мы говорим хотя бы про то, что написано по (одной!) ссылке, по которой ты так и не удосужился сходить.
A>>>>>Да, регулярные выражения не являются аналогом сопоставления с образцом, потому что это сопоставление с образцом и есть, одна из его разновидностей. Вы же почему-то считаете сопоставлением с образцом исключительно другую его разновидность, искусственно сужая определение термина. Так вот, в JavaScript есть сопоставление с образцом. M>>>>Мы не сужаем понятие, а расширяем его. A>>>Расширяете, выкидывая из понятия разновидность сопоставления — сопоставление с последовательностями? M>>Никто. Ничего. Не. Выкидывает.
A>Но ты же утверждаешь, что в JavaScript нет сопоставления с образцом.
Где? Ссылку и точную цитату.
M>>По ссылке в википедии, ты видимо, так и не удосужился пройти. Увы.
A>Почему я должен читать какие-то ссылки, если ты не читаешь мои сообщения?
M>>В пятидесятый раз. Сопоставления с образцом, о котором говорит Wolfhound, в JS нет. RegExp'ы являются неизмеримо малой частью сопоставления с образцом. Если ты не
A>— Есть ли в JavaScript patterm matching? Мой ответ: да. Ваш: нет?
A>— Нет.
Теперь возбмем другую цитату:
- В Немерле, Хаскеле, Скале, Эрланге есть и решулярные выражения и сопоставление с образцом. То сопоставление, о котором говорим с Wolfhound'ом в JS отсутсвует напрочь
— Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему. Таким образом pattern matching в JavaScript есть, о чём бы вы там не говорили.
Это ли не звиздец?
Тебе сто раз сказали, что именно мы имеем в виду, а ты продолжал упираться рогом в регулярные выражения. Хотя уже тут
WolfHound даже бдизко не упоминал их. Ты прикопался к термину, будучи уверенным, что раз в языке есть часть чего-то общего (регулярки), то в языке есть и общее (сопоставление с образцом в целом)?
Тебя спросили (и потом пятьдесят раз уточняли): есть ли в JS сопоставление с образцом в таком же виде, в каком оно есть в Nemerle/Erlang'е/Scala/Haskell'е. «Дададададада там есть регулярные выражения!!!!одинодинодин»
при этом намеренно заменяя общее понятие «сопоставление с образцом» узкой, малой его частью — регулярными выражениями.
A>Ничего подобного. Похоже, ты спорил сам с собой. Бывает.
Ой да ну. Из цитаты выше:
Ещё раз, регулярные выражения и есть сопоставление с образцом, а не что-то в дополнение к нему.
Регулярные выражения есть всего лишь часть общего понятия «сопоставление с образцом». То есть {regexp < pattern matching, regexp ⊆ pattern matching }, а ты упорно настаиваешь на том, что regexp === pattern matching.
В JS есть регулярные выражения, но в JS нет сопоставления с образцом:
— в его общем понятии (есть только часть)
— в том виде, в котором его подразумевал 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
Первое что они сделали, это начали строить классы, чтобы к полям объекта можно было обращаться по индексу.
А сделать это можно только в тех случаях, когда код фактически статически типизирован.
Ибо если типы будут постоянно меняться эта магия только тормозов добавит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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>Тормозит? Да!
Да.
Тот же Erlang можно вполне назвать динамическим языком. Стоит ли напоминать о надежности правильно написанных на нем программ?
WH>Полноценную навигацию и рефакторинг сделать можно? Нет!
Ну и что? Так я могу раз в десять больше способов отстрелить себе ногу в статически типизированном 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>Непонимание матчасти детектед.
Здравствуйте, 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>Не отрицаю.
А что же тогда в спор влез, если не знаешь, о чем говоришь?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>я для себя только один юз-кейс нашел — когда требуется ввод логики от конечного пользователя: ЕА>во-первых проще обработать все возможные ошибки, чем объяснить не-программистам что вместо (a + b) надо писать (a + (int)b) ЕА>во-вторых приходится делать всякие контекстно-зависмые подстановки: опять же например ЕА>sum(Order.Lines.Amount) ЕА>бизнес пользователю понятно, а Order.Lines.Sum(line => (double)line.Amount) уже не очень.
Это ДСЛ обыкновенный.
Причем тут динамическая типизация не ясно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>я для себя только один юз-кейс нашел — когда требуется ввод логики от конечного пользователя: ЕА>>во-первых проще обработать все возможные ошибки, чем объяснить не-программистам что вместо (a + b) надо писать (a + (int)b) ЕА>>во-вторых приходится делать всякие контекстно-зависмые подстановки: опять же например ЕА>>sum(Order.Lines.Amount) ЕА>>бизнес пользователю понятно, а Order.Lines.Sum(line => (double)line.Amount) уже не очень. WH>Это ДСЛ обыкновенный. WH>Причем тут динамическая типизация не ясно.
в dsl-х, предназначенных для редактирования енд-юзером приходится приводить типы автоматически за пользователей: если бизнес пользователю хочется складывать апельсины с яблоками, мы попытаемся использовать все возможные способы приведения, и ошибку выдадим, только если уж совсем ничего не получилось
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>в dsl-х, предназначенных для редактирования енд-юзером приходится приводить типы автоматически за пользователей: если бизнес пользователю хочется складывать апельсины с яблоками, мы попытаемся использовать все возможные способы приведения, и ошибку выдадим, только если уж совсем ничего не получилось
А динамическая типизация то зачем?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>в dsl-х, предназначенных для редактирования енд-юзером приходится приводить типы автоматически за пользователей: если бизнес пользователю хочется складывать апельсины с яблоками, мы попытаемся использовать все возможные способы приведения, и ошибку выдадим, только если уж совсем ничего не получилось WH>А динамическая типизация то зачем?
а как это сделать статически? например наша программа позволяет пользователю подключится к его данным и выполнить операции над его данными — например подсчитать sum(db.Oranges) + avеrage(db.Apples). Типы известны только в момент подключения к источнику, причем источники могут быть разные с разными тиипами. Т.е. на момент ввода выражений нам надо проверить синтаксис, но проверить совместимость типов мы не можем. Это не динамтическая типизация?
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>а как это сделать статически? например наша программа позволяет пользователю подключится к его данным и выполнить операции над его данными — например подсчитать sum(db.Oranges) + avеrage(db.Apples).
И что должно быть в этом случае?
ИМХО нужно говорить, что так делать нельзя.
ЕА>Типы известны только в момент подключения к источнику, причем источники могут быть разные с разными тиипами.
Те одно выражение пользователь засовывает в разные источники?
В любом случае типы можно проверить в момент подключения к источнику, а не во время исполнения запроса.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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> И сколько таких исключений?
Если не считать клоны Лиспа, то других исключений мне неизвестно.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Угу, как будто мало других вещей, которые не могут быть разрулены кроме как административно, так мы еще и за компьютеры работу делать будем — для удобства
У тебя и в статически типизированном языке надо "разруливать" эту вещь административно. Точно также.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, nbaksalyar, Вы писали:
N>>У вас устаревшие данные. JavaScript уже давно шагнул вперед за DOM — поглядите, например, Angry Birds или Linux в браузере — DOM-модель там упоминается разве только в ключе document.getElementById('canvas').
TK>В случае с canvas в первую очередь важна скорость рендеринга — это делается браузером.
А в случае с WebGL ты тоже считаешь, что "это делается браузером"?
Здравствуйте, WolfHound, Вы писали:
WH>Полноценную навигацию и рефакторинг сделать можно? Нет! WH>Что дает? Ничего!
Валяй, затипизируй в своем любимом Хиндли-Милнере от природы динамические DOM-деревья. Паржом. И покажи, чем pattern-matching будет в работе с ними удобнее, чем типичные для JS, насквозь динамические селекторы вида $('.node').
Здравствуйте, Gaperton, Вы писали:
TK>>В случае с canvas в первую очередь важна скорость рендеринга — это делается браузером. G>А в случае с WebGL ты тоже считаешь, что "это делается браузером"?
Ну, мы же не будем опускаться до того, что рендеринг делается видео-картой?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Такие системы типов называются soft type system. Для Эрланга статический тайпчекер входит в штатную поставку, и прекрасно ловит ошибки типов.
Для JS она, разумеется, тоже есть, и наличествует, например, в Google Closure Compiler. И никаких фундаментальных проблем делать это для динамических языков не существует.
Здравствуйте, 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>>До тех пор, пока не пользуешься типом 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) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ох. Я тебе показал код, который делает это не нужным.
Ок, подход понял, спорить о применимости не хочется Спасибо!
Здравствуйте, 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>И динамическая типизация для этого не нужна.
Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо.
Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка.
WH>Вот тебе демка покруче: http://www.impredicative.com/ur/more/dragList.html
N>>>Тот же Erlang можно вполне назвать динамическим языком. Стоит ли напоминать о надежности правильно написанных на нем программ? WH>>ЛОЛ. WH>>Программы на ерланге не надежны, они просто падают и быстренько перезапускаются, делая вид, что ничего не произошло.
M>1. Это чушь (потму что высказанно обобщение, в общем случае это неверно) M>2. И что с того?
С какого перепугу что-то должно падать, непонятно.
В общем виде работа выглядит в таком виде:
handle_call({message1, Params}, From, State) ->
делаем что-то с message1;
handle_call({message2, Param2, Param3}, From, State) ->
делаем что-то с message2;
handle_call(message3, From, State) ->
делаем что-то с message3;
handle_call(_, From, State) ->
игнорируем все отсальное.
Что произойдет, если придет {message4, с, какими-то, параметрами}? Мы его просто проигнорируем.
Что произойдет, если придет {message1, с, неправильно, сматченными, параметрами}? Да, мы упадем и перезапустимся. Только вот незадача. Это <b>точно так же</b> произойдет и со статической типизацией
Здравствуйте, WolfHound, Вы писали:
A>>Можно подробнее рассказать, что здесь крутого, WH>Да много что. Защита от кучи уязвимостей. Реактивность. Клиентская многопоточность. Прозрачное взаимодействие с сервером.
Все эти общие слова уже несколько лет являются обыденными в клиентской разработке. Можно какую-то конкретику привести?
A>>почему вспотеешь это делать, WH>Ну покажи мне клиентскую многопоточность на жабаскрипте.
В браузере клиентский код всегда выполняется в один поток. Можно создать лишь эмуляцию многопоточности, например, через setTimeout(), как это делается в примере. Ничего необычного и сложного.
A>>и вообще, зачем код смешан с разметкой? WH>По тому, что автор ученый. Сам язык не мешет писать правильно. А если над синтаксисом
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mamut, Вы писали:
M>>1. Это чушь (потму что высказанно обобщение, в общем случае это неверно) WH>Назови мне другой источник "надежности" ерланга. WH>Ну, хоть один.
Можно назвать целых два.
— Модель процессов и selective receive.
— Отсутствие опасных конструкций в языке.
На Эрланге писать куда приятнее, чем на C++ и Java. Ошибок делаешь меньше. Несмотря на динамику.
А вообще, эта тема подробно раскрыта в диссертации Джо Армстронга. Разумеется, тебе никто не будет пересказывать диссертацию в форуме, и насильно заставлять ее читать.
M>>2. И что с того? WH>То, что это не надежность, а показуха.
Девять девяток надежности по итогам эксплуатации AXD301 — это не надежность, а показуха? LOL! Мне бы в портфолио такую показуху.
M>>Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо. WH>Это по тому, что среди их клиентов нет людей понимающих плюсы статической типизации.
А что, среди твоих клиентов есть такие, которые знают слово "типизация"?
Здравствуйте, Gaperton, Вы писали:
WH>>А вот это вообще делать вспотеешь: http://www.impredicative.com/ur/demo/threads.html G>Неужели?
Ага.
G>Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка. Ты что в самом деле думал что я не замечу такой дешёвой подтасовки?
Ты вызываешь функцию по таймеру.
А в оригинальном коде создается два потока.
Причем ждать они умеют не только на sleep но и на rpc.
Так что в реальном коде получишь ты лапшу из кучи каллбеков вместо простого кода.
G>ЗЫ: Падсталом валялся, глядя на твои крутые демки.
Давай ка я процитирую, на что я отвечал:
Не вижу здесь динамически обновляемых фрагментов DOM, анимации, и обработки событий, характерных для модели страницы браузера.
Так что это доказательство того что читать ты не умеешь.
Все там есть.
G>Куда уж легче-то.
rpc (speak line)
Вызываем серверный метод speak с аргументом line.
G>Твоя шняга и JSONP-то поди делать не умеет.
Он ей не нужен.
И вообще посмотри это: http://www.impredicative.com/ur/demo/chat.html
G>Это если ручками запрос оформлять, что в случае ExtJS вообще-то делать не нужно, там они автоматически строятся.
Код в студию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Можно назвать целых два. G>- Модель процессов и
Это и есть то самое "они просто падают и быстренько перезапускаются, делая вид, что ничего не произошло".
G>selective receive.
А это ошибка дизайна и ведет к снижению надежности.
The system is dimensioned so that the CPU load is low (say 10 %). Now at some point in time, the backend service takes one second longer than usual to process one particular request. You'd expect that some requests will be delayed (by no more than one second) and that quality of service will return to normal within two seconds, since there is so much spare capacity.
Instead, the following can happen: During the one second outage, requests accumulate in the message queue of the server process. Subsequent gen_server calls take more CPU time than usual because they have to scan the whole message queue to extract replies. As a result, more messages accumulate, and so on.
snowball.erl (attached) simulates all this. It slowly increases the CPU load to 10 %. Then it pauses the backend for one second, and you can see the load rise to 100 % and remain there, although the throughput has fallen dramatically.
Here are several ways to avoid this scenario...
...
Add a proxy process dedicated to buffering requests from clients and making sure the message queue of the server remains small. This was suggested to me at the erlounge. It is probably the best solution, but it complicates process naming and supervision. And programmers just shouldn't have to wonder whether each server needs a proxy or not.
G>- Отсутствие опасных конструкций в языке.
Этим ты сейчас никого не удивишь.
G>На Эрланге писать куда приятнее, чем на C++ и Java. Ошибок делаешь меньше. Несмотря на динамику.
На немерле еще приятнее.
G>Девять девяток надежности по итогам эксплуатации AXD301 — это не надежность, а показуха? LOL! Мне бы в портфолио такую показуху.
Я же сказал, как это достигается.
M>>>Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо. WH>>Это по тому, что среди их клиентов нет людей понимающих плюсы статической типизации. G>А что, среди твоих клиентов есть такие, которые знают слово "типизация"?
Ты точно читать не умеешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>1. Это чушь (потму что высказанно обобщение, в общем случае это неверно) WH>Назови мне другой источник "надежности" ерланга. WH>Ну, хоть один.
1. Это — безусловно, возможность отловить ошибки в пдающих процессах и сделать им graceful рестарт
2. Async message passing и отсутсвие разделяемых данных (и bottlenck'ов', с этим связанных)
3. Стабильность и устойчивость VM (в частности — в scheduler'е, gc и работе с сетью)
Что-то мне подсказывает, что и первое и второе, и третье у всегда неявно подразумеваемого во всех твоих сообщениях Nemerle отсутствует, как класс.
M>>2. И что с того? WH>То, что это не надежность, а показуха.
Понимаешь, чтобы ты себе ни нафантазировал, падать Erlang'у совсем необязательно
M>>Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо. WH>Это по тому, что среди их клиентов нет людей понимающих плюсы статической типизации.
Ну да, потому что все — дебилы, один Wolfhound в белом платье, ага
WH>Просто по тому, что такие люди ерланг не используют.
WH>>>А вот это вообще делать вспотеешь: http://www.impredicative.com/ur/demo/threads.html G>>Неужели? WH>Ага.
G>>Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка. WH> Ты что в самом деле думал что я не замечу такой дешёвой подтасовки? WH>Ты вызываешь функцию по таймеру. WH>А в оригинальном коде создается два потока. WH>Причем ждать они умеют не только на sleep но и на rpc. WH>Так что в реальном коде получишь ты лапшу из кучи каллбеков вместо простого кода.
Ты всерьез считаешь, что ur генерирует два настоящих потока в генерируемом им HTML и JS? Извини, но это — бред, с реальностью не имеющий ничего общего. Там точно так же генерируются setTimeout'ы и прочая. Только в них можно сломать голову.
Здравствуйте, Gaperton, Вы писали:
G>У меня создается два настоящих потока через HTML5 Web Worker API (Видишь вызов new Worker? Это оно). Внутри каждого из потоков я использую таймер.
А я что сказал?
Ты вызываешь функцию по таймеру.
Раз великий ынжынэр это не понимает то распишу по полочкам, что происходит в твоем коде:
worker.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Вообще вспотеешь это делать!</title>
<script type="text/javascript">
//Создаем два отдельных изолированных контекста исполнения
var worker1 = new Worker('worker.js');
var worker2 = new Worker('worker.js');
//Подписываемся на сообщения которые приходят из этих сообщений
//каллбек раз!
worker1.onmessage = worker2.onmessage = function handle(event) {
document.write( event.data );
};
//Отправляем сообщения в контексты исполнения
//Приход сообщения инициирует работу.
worker1.postMessage({ prefix: "A", delay: 5000 });
worker2.postMessage({ prefix: "B", delay: 3000 });
</script>
</head>
<body>
</body>
</html>
worker.js:
//Подписываемся на сообщения приходящие извне
onmessage = function( a_event ){
var count = 0;
//Запускаем таймер который будет каждые n миллисекунд вызывать переданную функцию
//каллбек два!
setInterval( function(){
//посылаем сообщение в родительский контекст
postMessage( a_event.data.prefix + ' ' + count++ );
}, a_event.data.delay );
};
Это только на таком простом коде три контекста, два каллбека, посылки сообщений и запуск таймера.
При том что в исходном коде ничего этого нет.
G>Ну естественно. Про same origin security policy и JSONP ты, разумеется, тоже не в курсе.
В курсе.
Не нужен.
G>С пионерами спорь. Пока.
Великий ынжынэр опять слился?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>1. Это — безусловно, возможность отловить ошибки в пдающих процессах и сделать им graceful рестарт
Быстренько перезапуститься и сделать вид что так и надо.
M>2. Async message passing и отсутсвие разделяемых данных (и bottlenck'ов', с этим связанных)
Типа этим можно когото удивить.
И причем тут кстати типизация?
M>3. Стабильность и устойчивость VM (в частности — в scheduler'е, gc и работе с сетью) Ну да, конечно.
Здравствуйте, Mamut, Вы писали:
M>Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо.
1) Миллионы леммингов не могут ошибаться?
2) Клиенты вообще — весьма посредственные эксперты, если мы говорим не о зарабатывании бабала, а о чисто технических моментах. А в этом топике пока было именно так.
3) Клиенты, пишущие программы для железок — еще более фиговые эксперты, бо текущее состояние телекомовского софта, работающего близко к железу — ниже плинтуса. Примеров тому масса. Например — все производителеи смартфонов в итоге перешли на созданные чистым софтвером операционки, а не угробные поделия железного сектора.
Это, впрочем, никак не означает что ерланг плох. Но его хорошесть вряд ли определяется его динамикой.
Здравствуйте, Gaperton, Вы писали:
G>Девять девяток надежности по итогам эксплуатации AXD301 — это не надежность
Ты с этим AXD уже лет пять носишься если не больше, вот только надежность пока что это больше вопрос приоритетов разработки, а не языка программирования. Время полностью верифицируемых языков пока не настало.
Здравствуйте, Mamut, Вы писали:
M>1. Это — безусловно, возможность отловить ошибки в пдающих процессах и сделать им graceful рестарт
То есть ты подтверждаешь его слова.
M>2. Async message passing и отсутсвие разделяемых данных (и bottlenck'ов', с этим связанных)
Т.е. safety. Что, очевидно, связано с управляемостью, а не наличием/отсутствием статической типизации
M>3. Стабильность и устойчивость VM (в частности — в scheduler'е, gc и работе с сетью)
Которая написана совсем не на динамике.
M>Что-то мне подсказывает, что и первое и второе, и третье у всегда неявно подразумеваемого во всех твоих сообщениях Nemerle отсутствует, как класс.
Ты путаешь язык и рантайм. Все, что ты перечислил, относится ко второму.
Это чего, преподносится как что то значимое в общем смысле? Ты же прекрасно понимаешь, что это голимый примитив, никак не демонстрирующий преимуществ динамики.
G>Куда уж легче-то.
И правда, нафига в том же дотнете все эти TPL и Rx с асинками? Написал несколько простеньких хелперов с лямбдами поверх пула потоков и вуаля, все проблемы решены.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это чего, преподносится как что то значимое в общем смысле? Ты же прекрасно понимаешь, что это голимый примитив, никак не демонстрирующий преимуществ динамики.
Там пример с тредами. Сделал. Не вспотел. Ибо элементарно. К преимуществам динамики или статики это вообще никакого отношения не имеет, в данном микропримере это не имеет значения.
Здравствуйте, Gaperton, Вы писали:
НС>>Это чего, преподносится как что то значимое в общем смысле? Ты же прекрасно понимаешь, что это голимый примитив, никак не демонстрирующий преимуществ динамики.
G>Ты тред читал? Это ответ на
Читал. Только какой смысл расползаться мыслью по древу?
G>У тебя еще чего-нибудь?
Ну там в сообщении немного больше было. Но не хочешь отвечать — я не настаиваю.
Здравствуйте, Ночной Смотрящий, Вы писали:
A>>О, признаю, неправильно понял. Но всё же в случае Perl и Erlang не видно описанных стад НС>Ну, не может же быть вся динамика мегапопулярной.
PHP — потому что очень просто. Ruby — поотому что RoR. Python — потому что Django. При чём тут динамика? Могу допустить, что только в случае PHP она при чём.
A>>Может дело вовсе не в динамике? НС>Я никогда и не утверждал, что дело только в динамике.
Здравствуйте, Ночной Смотрящий, Вы писали:
A>>PHP — потому что очень просто. Ruby — поотому что RoR. Python — потому что Django. При чём тут динамика? НС>Пологая ... ну ты понял.
Я понял, но по прежнему не вижу связи с динамикой.
M>>Ты всерьез считаешь, что ur генерирует два настоящих потока в генерируемом им HTML и JS? Извини, но это — бред, с реальностью не имеющий ничего общего. Там точно так же генерируются setTimeout'ы и прочая. Только в них можно сломать голову. WH>Ты пойми мне абсолютно пофигу что там генерируется. WH>Мне важно, что есть в исходном коде. WH>Языки высокого уровня для того и нужны чтобы на ассемблере не писать.
Тебе такое понятия, как «библиотека», знакомо?
Тут спокойно пишется то, что тебе надо в виде библиотеки.
Здравствуйте, anonymous, Вы писали:
A>То же самое происходит и в коде на Ur, даже более примитивно, поскольку настоящих процессов не создаётся.
Там наблюдаются настоящие кооперативные потоки.
Из этого следует, что нам не нужно плясать с бубном, чтобы обновлять UI.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Гы, а Wolfhound — неосилятор, оказывается.
Здравствуйте, Mamut, Вы писали:
M>Что-то мне кажется, что ты противопроставил эти два предложения Ж-\
Ты на самом деле не понимаешь чем поток отличается от таймера с калбеком?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>То есть берём любую обёртку на JavaScript, и задумываемся, зачем нам Ur? Кстати, на какой бы уровень ты не перешёл, не будет настоящих потоков.
1)За тем чтобы писать еще меньше кода.
Ибо все эти обертки заставляют писать кучу мусора.
2)За тем чтобы компилятор ловил ошибки.
Это ты вообще никакими обертками не сделаешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>1. Это — безусловно, возможность отловить ошибки в пдающих процессах и сделать им graceful рестарт WH>Быстренько перезапуститься и сделать вид что так и надо.
От того, что ты это повторяешь, менее бредом это не становится.
M>>2. Async message passing и отсутсвие разделяемых данных (и bottlenck'ов', с этим связанных) WH>Типа этим можно когото удивить. WH>И причем тут кстати типизация?
"Назови мне другой источник "надежности" ерланга." — это, видимо не я спрашивал, ага
M>>3. Стабильность и устойчивость VM (в частности — в scheduler'е, gc и работе с сетью) WH>Ну да, конечно.
Угу. Теперь приведи мне хоть что-то близкое к перформансу и фичам Erlang'а на твоем людимом Nemerle, и только тогда можно будет поговорить с тобой о надежности VM Erlang'а.
Здравствуйте, Mamut, Вы писали:
M>Тебе такое понятия, как «библиотека», знакомо?
M>Тут спокойно пишется то, что тебе надо в виде библиотеки.
Да правда чтоли?
Повтори код на UR в виде библиотеки.
fun main () =
buf <- Buffer.create;
let
fun loop prefix delay =
let
fun loop' n =
Buffer.write buf (prefix ^ ": Message #" ^ show n);
sleep delay;//Вот тут у тебя будут большие проблемы
loop' (n + 1)
in
loop'
end
in
return <xml><body onload={spawn (loop "A" 5000 0); spawn (loop "B" 3000 100)}>
<dyn signal={Buffer.render buf}/>
</body></xml>
end
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>1. Это — безусловно, возможность отловить ошибки в пдающих процессах и сделать им graceful рестарт
НС>То есть ты подтверждаешь его слова.
Только частично. Это — всего лишь один из пунктов.
M>>2. Async message passing и отсутсвие разделяемых данных (и bottlenck'ов', с этим связанных)
НС>Т.е. safety. Что, очевидно, связано с управляемостью, а не наличием/отсутствием статической типизации
Блин. еще один.
«Назови мне другой источник "надежности" ерланга.» — это было так сказано, в воздух? Я должен был сконцентрироваться только лишь на типизации?
M>>3. Стабильность и устойчивость VM (в частности — в scheduler'е, gc и работе с сетью)
НС>Которая написана совсем не на динамике.
И? См. цитату выше.
M>>Что-то мне подсказывает, что и первое и второе, и третье у всегда неявно подразумеваемого во всех твоих сообщениях Nemerle отсутствует, как класс.
НС>Ты путаешь язык и рантайм. Все, что ты перечислил, относится ко второму.
G>>Девять девяток надежности по итогам эксплуатации AXD301 — это не надежность
НС>Ты с этим AXD уже лет пять носишься если не больше, вот только надежность пока что это больше вопрос приоритетов разработки, а не языка программирования. Время полностью верифицируемых языков пока не настало.
Можно и не AXD301, просто это один из самых ярких примеров. Данные по другим баируются только на hearsay. Типа
В конце Дэвида (http://klarna.com/) спросили: а с технической точки зрения как проявился переход на Erlang? Очень хорошо: 20 Java-машин были заменены 2-мя с Erlang'ом. За последние три года было 48 секунд простоя. Система неубиваема.
Сейчас прибежит Wolfhound и будет рассказывать сказки про то, что на Немерле у него простоя вообще не было, ага.
Здравствуйте, WolfHound, Вы писали:
M>>Что-то мне кажется, что ты противопроставил эти два предложения Ж-\ WH>Ты на самом деле не понимаешь чем поток отличается от таймера с калбеком?
А ты на самом деле не понимаешь, чем настоящий поток WebWorker отличается от этой шняги, которая генерится твоим мегаязыком? А ты убери в примере на мегаязыке ожидания внутри циклов, и убери в моем примере из WorkerThread-ов таймеры, запусти оба, и увидишь.
G>>selective receive. WH>А это ошибка дизайна и ведет к снижению надежности. WH>
WH>The system is dimensioned so that the CPU load is low (say 10 %). Now at some point in time, the backend service takes one second longer than usual to process one particular request. You'd expect that some requests will be delayed (by no more than one second) and that quality of service will return to normal within two seconds, since there is so much spare capacity.
WH>Instead, the following can happen: During the one second outage, requests accumulate in the message queue of the server process. Subsequent gen_server calls take more CPU time than usual because they have to scan the whole message queue to extract replies. As a result, more messages accumulate, and so on.
WH>snowball.erl (attached) simulates all this. It slowly increases the CPU load to 10 %. Then it pauses the backend for one second, and you can see the load rise to 100 % and remain there, although the throughput has fallen dramatically.
WH>Here are several ways to avoid this scenario...
WH> ...
WH> Add a proxy process dedicated to buffering requests from clients and making sure the message queue of the server remains small. This was suggested to me at the erlounge. It is probably the best solution, but it complicates process naming and supervision. And programmers just shouldn't have to wonder whether each server needs a proxy or not.
Never, but never use async messages into a blocking server from the outside world.
С интернетов:
The problem in this scenario is *coupling* too closely the asynchronous selective receive with the backend synchronous service. This is not an uncommon scenario in all kinds of "service-oriented architectures" and the solution, generally, should be the one quoted above.
То есть ВНЕЗАПНО проблема оказалась не в якобы ошибке дизайна (в чем там ошибка? ну, раз так сказал сам WolfHound, она там просто обязана быть, ага), а в ошибке архитектуры приложения.
Любая система, обрабатывающая сообщения медленнее, чем они в нее входят, будет иметь эту проблему.
WH>Здравствуйте, Mamut, Вы писали:
M>>Что-то мне кажется, что ты противопроставил эти два предложения Ж-\ WH>Ты на самом деле не понимаешь чем поток отличается от таймера с калбеком?
Ты на само мделе не видишь в примере Гапертона двух потоков? То, как они между собой общаются — это дело десятое.
Ты на самом деле видишь в примере ur'а два настоящих потока? При том, что они релизованы таймерами и колбеком?
M>>Тебе такое понятия, как «библиотека», знакомо?
M>>Тут спокойно пишется то, что тебе надо в виде библиотеки. WH>Да правда чтоли? WH>Повтори код на UR в виде библиотеки. WH>
WH>fun main () =
WH> buf <- Buffer.create;
WH> let
WH> fun loop prefix delay =
WH> let
WH> fun loop' n =
WH> Buffer.write buf (prefix ^ ": Message #" ^ show n);
WH> sleep delay;//Вот тут у тебя будут большие проблемы
WH> loop' (n + 1)
WH> in
WH> loop'
WH> end
WH> in
WH> return <xml><body onload={spawn (loop "A" 5000 0); spawn (loop "B" 3000 100)}>
WH> <dyn signal={Buffer.render buf}/>
WH> </body></xml>
WH> end
WH>
Предполагаю, что sleep delay там транслируется в yield sleep(delay)
Но я помню, ты слепо веришь в то, что в Ur создаются два настоящих потока, ага Фигня, что Ur транслируется в JS. Значит, ВНЕЗАПНО, это — по сути, всего лишь DSL, транслирующийся в JS. Значит, реализовать это не должно вызывать больших проблем.
A>>То же самое происходит и в коде на Ur, даже более примитивно, поскольку настоящих процессов не создаётся. WH>Там наблюдаются настоящие кооперативные потоки. WH>Из этого следует, что нам не нужно плясать с бубном, чтобы обновлять UI.
Wolfhound, этот код транслируется в голый JavaScript. То есть никакими потоками там и не пахнет.
Для того, чтобы не плясать с бубном при обновлении UI, Ur не нужен. Нужен, например, knockout.js.
Здравствуйте, Mamut, Вы писали:
M>То есть ВНЕЗАПНО проблема оказалась не в якобы ошибке дизайна (в чем там ошибка? ну, раз так сказал сам WolfHound, она там просто обязана быть, ага), а в ошибке архитектуры приложения.
M>Любая система, обрабатывающая сообщения медленнее, чем они в нее входят, будет иметь эту проблему.
ВНЕЗАПНО выяснилось, что ты тоже не умеешь читать.
Там приводится сценарий, в котором система в среднем справляется с нагрузкой с десятикратным запасом.
Но если хоть одно сообщение притормозить, то очередь распухнет и благодаря данной "гениальной" идеи создателей языка система уже не выйдет из ступора. Ибо все время начинает, есть операция "получить сообщение".
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>Тут спокойно пишется то, что тебе надо в виде библиотеки. WH>Да правда чтоли? WH>Повтори код на UR в виде библиотеки.
Не-не-не, не надо никаких sleep-ов никуда втыкать.
Повтори вот этот код Worker-а в "потоке" на своем мегаязыке — без delay-ев.
onmessage = function( a_event ){
var count = 0;
while( true ){
for( var i = 0; i < 10000000000; i ++ ){} // вот тут у тебя будут большие проблемы.
postMessage( a_event.data.prefix + ' ' + count++ );
}
};
Вообще вспотеешь. Ибо, у тебя там никакие не потоки, а дешевая их симуляция. Трюк. Обман. Видимость.
А что до синхронных вызовов — в настоящих потоках WebWorker я совершенно спокойно могу делать AJAX-вызовы синхронно, не переживай. Это работает без каких-либо дополнительных танцев с бубном. Ничего они мне, кроме того потока, не заблокируют.
Здравствуйте, Mamut, Вы писали:
M>Wolfhound, этот код транслируется в голый JavaScript. То есть никакими потоками там и не пахнет.
Читать ты точно не умеешь.
M>Для того, чтобы не плясать с бубном при обновлении UI, Ur не нужен. Нужен, например, knockout.js.
На ур кода всеравно меньше получается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Wolfhound, этот код транслируется в голый JavaScript. То есть никакими потоками там и не пахнет. WH>Читать ты точно не умеешь.
Читать что?
Ты даешь ссылку на демонстрацию якобы многопоточности в ur.
Ты хочешь сказать, что ur транслируется не в HTML + Javascript?
Ты хочешь сказать, Ur реализует реальную многопоточность в Javascript? Каким образом?
M>>Для того, чтобы не плясать с бубном при обновлении UI, Ur не нужен. Нужен, например, knockout.js. WH>На ур кода всеравно меньше получается.
Какая разница? Реальной многопоточностью там и не пахнет. При желании к JS можно прикрутить coffescript и получить совсем мало кода.
M>>То есть ВНЕЗАПНО проблема оказалась не в якобы ошибке дизайна (в чем там ошибка? ну, раз так сказал сам WolfHound, она там просто обязана быть, ага), а в ошибке архитектуры приложения.
M>>Любая система, обрабатывающая сообщения медленнее, чем они в нее входят, будет иметь эту проблему. WH>ВНЕЗАПНО выяснилось, что ты тоже не умеешь читать. WH>Там приводится сценарий, в котором система в среднем справляется с нагрузкой с десятикратным запасом. WH>Но если хоть одно сообщение притормозить, то очередь распухнет и благодаря данной "гениальной" идеи создателей языка система уже не выйдет из ступора. Ибо все время начинает, есть операция "получить сообщение".
ВНЕЗАПНО выяснилось, что читать не умеешь ты.
В систему втекает поток сообщений, который обрабатывается, по сути, блокирующим сервером:
the backend service takes one second longer than usual to process one particular request
То есть тормозит не сообщение, не очередь, а обработка этой очереди. Банальный (D)DOS, из которого ты делаешь максимально неверные далеко идущие выводы.
Я боюсь даже попросить тебя предоставить правильный вариант на замену selective receive
Здравствуйте, Gaperton, Вы писали:
G>Не-не-не, не надо никаких sleep-ов никуда втыкать. G>Повтори вот этот код Worker-а в "потоке" на своем мегаязыке — без delay-ев.
Мне еще сколько десятков раз написать, что потоки кооперативные?
С другой стороны это дает возможность спокойно работать с данными без плясок с бубном.
Кстати надеюсь, ты понимаешь, что ничто не мешает скомпилировать этот код так чтобы не было этой проблемы... вспомни, что делает ерланг и скажи, почему это не сможет сделать ур...
G>А что до синхронных вызовов — в настоящих потоках WebWorker я совершенно спокойно могу делать AJAX-вызовы синхронно, не переживай. Это работает без каких-либо дополнительных танцев с бубном. Ничего они мне, кроме того потока, не заблокируют.
Не переживай ты так. Вызовы серверного кода в ur все "синхронные".
Причем везде.
И при этом ничего не тормозиться.
Магия, да и только...
Повторю еще раз мне все равно во что ур это перепишет.
Я прекрасно понимаю, что там получается. Мне важна модель исполнения самого ур.
G>Этого, ты, разумеется, тоже не знал, да?
Да я прекрасно понимаю, что такое этот твой воркер.
Похоже, что даже лучше чем ты.
Кстати ты не забыл с чего разговор начался?
WH>Может ты покажешь задачу где нужна динамическая типизация?
Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере.
Так зачем тут динамическая типизация то? Если насквозь статический ур с этим справляется лучше, чем жабаскрипт не смотря на мегатонны библиотек?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>То есть тормозит не сообщение, не очередь, а обработка этой очереди. Банальный (D)DOS, из которого ты делаешь максимально неверные далеко идущие выводы.
Ты не то выделил. Вот так правильно:
the backend service takes one second longer than usual to process one particular request
Те один запрос протормозил и приехали.
Вместо того чтобы быстренько разобрать накопившийся хвост система будет тупить на выборке сообщений из очереди.
M>Я боюсь даже попросить тебя предоставить правильный вариант на замену selective receive
Обычная очередь такой проблемы не имеет. Ибо получение сообщения O(1) гарантировано. В то время как selective receive O(N) в общем случае.
И как следствие мы попадаем на O(N^2) чтобы прочитать всю очередь.
Что собственно все и убило.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>То есть тормозит не сообщение, не очередь, а обработка этой очереди. Банальный (D)DOS, из которого ты делаешь максимально неверные далеко идущие выводы. WH>Ты не то выделил. Вот так правильно: WH>
WH>the backend service takes one second longer than usual to process one particular request
WH>Те один запрос протормозил и приехали. WH>Вместо того чтобы быстренько разобрать накопившийся хвост система будет тупить на выборке сообщений из очереди.
Каким образом система будет разбирать этот хвост по твоему?
M>>Я боюсь даже попросить тебя предоставить правильный вариант на замену selective receive WH>Обычная очередь такой проблемы не имеет. Ибо получение сообщения O(1) гарантировано. В то время как selective receive O(N) в общем случае. WH>И как следствие мы попадаем на O(N^2) чтобы прочитать всю очередь. WH>Что собственно все и убило.
ВНЕЗПНО в рассылке сказали так, по сути, и сделать, но ты их всех считаешь идиотами, и создателями языка — в том числе.
Ты хотя бы вообще в курсе, что такое selective recieve и зачем он нужен?
Здравствуйте, Mamut, Вы писали:
M>Каким образом система будет разбирать этот хвост по твоему?
У системы в среднем десятикратный запас по производительности.
Повторю еще раз ДЕСЯТИКРАТНЫЙ!!!!!!!!!
Так что если без тормозов при получении сообщения, то все будет просто летать.
И очередь разберется за 100-200 миллисекунд.
M>Ты хотя бы вообще в курсе, что такое selective recieve и зачем он нужен?
Чтобы любой всплеск нагрузки убивал систему.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Каким образом система будет разбирать этот хвост по твоему? WH>У системы в среднем десятикратный запас по производительности. WH>Повторю еще раз ДЕСЯТИКРАТНЫЙ!!!!!!!!! WH>Так что если без тормозов при получении сообщения, то все будет просто летать. WH>И очередь разберется за 100-200 миллисекунд.
И? Берешь в руки любую очередь и тормозишь с обработкой сообщения. У тебя будет точно такая же проблема Банальный, блин, DOS.
M>>Ты хотя бы вообще в курсе, что такое selective recieve и зачем он нужен? WH>Чтобы любой всплеск нагрузки убивал систему.
Здравствуйте, Mamut, Вы писали:
M>И? Берешь в руки любую очередь и тормозишь с обработкой сообщения. У тебя будет точно такая же проблема Банальный, блин, DOS.
Это не ДОС, а кратковременный всплеск. Обычная ситуация.
При использовании нормальной очереди рассосётся само за 100-200 миллисекунд.
WH>>Чтобы любой всплеск нагрузки убивал систему. M>Угу, так и запишем: не знает, и знать не хочет.
А нахрена мне линейный алгоритм, если я тоже самое могу сделать константным?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>То есть берём любую обёртку на JavaScript, и задумываемся, зачем нам Ur? Кстати, на какой бы уровень ты не перешёл, не будет настоящих потоков. WH>1)За тем чтобы писать еще меньше кода. Ибо все эти обертки заставляют писать кучу мусора.
Зависит от обёртки. Ведь Ur тоже всего лишь обёртка.
WH>2)За тем чтобы компилятор ловил ошибки. Это ты вообще никакими обертками не сделаешь.
Здравствуйте, Mamut, Вы писали:
M>Там нет потоков вообще. Там есть только setTimeout и прочая братия.
В ур setTimeout.
А на то что есть в ассемблере мне плевать.
M>Не сможет, потому что ur (ну или то, что в примерах) компилируется в JS.
Ну то есть как работает интерпритатор ерланга ты не знаешь.
M>Я боюсь тебя разочаровать, но этот параметр означает асинхронный вызов
Для ур это синхронный код.
А то что он переписывается в асинхронный это дело компилятора.
И на то как я пишу программу не влияет.
M>Ага. Аргументы закончились, внезпно надо восстанавливать контекст, который ты сам и забыл со своими примерами. «А вот это вообще делать вспотеешь: http://www.impredicative.com/ur/demo/threads.html», видимо, Гапертон написал...
Это была одна маленька строка из большого сообщения которое было написано по тому что гапертон не смог найти как же ур на события реагирует.
Кстати гапертон так и не повторил тот код.
Он написал совсем другой код.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>Зависит от обёртки. Ведь Ur тоже всего лишь обёртка.
Не зависит.
Разве что ты напишешь еще один ур вид в профиль.
Только это будет не библиотека для жабаскрипта, а полноценный язык с компилятором и прочими плюшками.
WH>>2)За тем чтобы компилятор ловил ошибки. Это ты вообще никакими обертками не сделаешь. A>Не нужно.
Повтори это еще тыщу раз. Может наконец убедишь себя в этом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Зависит от обёртки. Ведь Ur тоже всего лишь обёртка. WH>Не зависит. Разве что ты напишешь еще один ур вид в профиль. Только это будет не библиотека для жабаскрипта, а полноценный язык с компилятором и прочими плюшками.
Скорее это будет набор отлаженных решений типа knockuot.js и прочих. Возможно, слегка присыпанных сахаром.
WH>>>2)За тем чтобы компилятор ловил ошибки. Это ты вообще никакими обертками не сделаешь. A>>Не нужно. WH>Повтори это еще тыщу раз. Может наконец убедишь себя в этом.
Себя-то мне зачем убеждать? Я в этом на практике уже давно убедился.
M>>И? Берешь в руки любую очередь и тормозишь с обработкой сообщения. У тебя будет точно такая же проблема Банальный, блин, DOS. WH>Это не ДОС, а кратковременный всплеск. Обычная ситуация. WH>При использовании нормальной очереди рассосётся само за 100-200 миллисекунд.
WH>>>Чтобы любой всплеск нагрузки убивал систему. M>>Угу, так и запишем: не знает, и знать не хочет. WH>А нахрена мне линейный алгоритм, если я тоже самое могу сделать константным?
M>>Там нет потоков вообще. Там есть только setTimeout и прочая братия. WH>В ур setTimeout. WH>А на то что есть в ассемблере мне плевать.
Угу. То есть в итоге любой поток с длинным вычислением убъет программу к чертям. Тебя же проблемы ассемблера не волнуют, ага
M>>Не сможет, потому что ur (ну или то, что в примерах) компилируется в JS. WH>Ну то есть как работает интерпритатор ерланга ты не знаешь.
Кстати надеюсь, ты понимаешь, что ничто не мешает скомпилировать этот код так чтобы не было этой проблемы... вспомни, что делает ерланг и скажи, почему это не сможет сделать ур...
Если ur будет компилировать во что-то нечто erlang'а — пожалуйста. Пока он компилируется в JS — нереально (ну или нереально до того момента, пока он не начнет использовать workers для настоящих потоков).
M>>Я боюсь тебя разочаровать, но этот параметр означает асинхронный вызов WH>Для ур это синхронный код. WH>А то что он переписывается в асинхронный это дело компилятора. WH>И на то как я пишу программу не влияет.
Еще как влияет. Гапертон предложил тебе написать то, что влияет
, но этого не захотел. Видимо «настоящая многопоточность» в ur'е все же миф
M>>Ага. Аргументы закончились, внезпно надо восстанавливать контекст, который ты сам и забыл со своими примерами. «А вот это вообще делать вспотеешь: http://www.impredicative.com/ur/demo/threads.html», видимо, Гапертон написал... WH>Это была одна маленька строка из большого сообщения которое было написано по тому что гапертон не смог найти как же ур на события реагирует. WH>Кстати гапертон так и не повторил тот код. WH>Он написал совсем другой код.
Чем принципиально его код отличается от твоего?
Ах, да, я помню. Там еще было «замучаешься писать sleep в потоке на JS» при том, что JS, в который компилируется Ur, это умеет
Здравствуйте, anonymous, Вы писали:
A>Скорее это будет набор отлаженных решений типа knockuot.js и прочих. Возможно, слегка присыпанных сахаром.
Если не присыпать сахаром то ур будет короче.
А если присыпать то здравствуй компилятор.
Ну и присыпание сахаром knockuot.js тебе никак не поможет с серверной частью.
Да и вот это тебе никакой сахар не даст:
Ur/Web is Ur plus a special standard library and associated rules for parsing and optimization. Ur/Web supports construction of dynamic web applications backed by SQL databases. The signature of the standard library is such that well-typed Ur/Web programs "don't go wrong" in a very broad sense. Not only do they not crash during particular page generations, but they also may not:
Suffer from any kinds of code-injection attacks
Return invalid HTML
Contain dead intra-application links
Have mismatches between HTML forms and the fields expected by their handlers
Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
Attempt invalid SQL queries
Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
A>>Скорее это будет набор отлаженных решений типа knockuot.js и прочих. Возможно, слегка присыпанных сахаром. WH>Если не присыпать сахаром то ур будет короче. WH>А если присыпать то здравствуй компилятор.
Угу. Про библиотеки Wolfhound все так же не слышал.
WH>Ну и присыпание сахаром knockuot.js тебе никак не поможет с серверной частью. WH>Да и вот это тебе никакой сахар не даст: WH>
skip
Это мне не даст, по сути, ни один язык, кроме java+gwt, так что мимо кассы.
Здравствуйте, WolfHound, Вы писали:
A>>Скорее это будет набор отлаженных решений типа knockuot.js и прочих. Возможно, слегка присыпанных сахаром. WH>Если не присыпать сахаром то ур будет короче. А если присыпать то здравствуй компилятор.
Да, можно присыпать так, что и Ur останется далеко позади, только незачем. А откуда тут взялся компилятор, вообще не понятно.
WH>Ну и присыпание сахаром knockuot.js тебе никак не поможет с серверной частью. Да и вот это тебе никакой сахар не даст:
Серверную часть я напишу отдельно, использовав для взаимодействия стандартный протокол, типа JSON-RPC. Тогда у меня будет один сервер и сколько угодно клиентов, не обязательно браузерных.
Здравствуйте, Mamut, Вы писали:
M>Если ur будет компилировать во что-то нечто erlang'а — пожалуйста. Пока он компилируется в JS — нереально (ну или нереально до того момента, пока он не начнет использовать workers для настоящих потоков).
Ты в самом деле думаешь что я не смогу переписать код в Continuation-passing style и прерывать поток каждые 1000 редукций?
M>Ах, да, я помню. Там еще было «замучаешься писать sleep в потоке на JS» при том, что JS, в который компилируется Ur, это умеет
Умеет он это по тому, что переписывает код в жуткую лапшу. Ну, ты ее сам видел. Есть желание самому такой писать?
Думаю что нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Угу. Про библиотеки Wolfhound все так же не слышал.
Библиотеки не убирают весь мусор.
M>Это мне не даст, по сути, ни один язык, кроме java+gwt, так что мимо кассы.
Это тебе дает ур/веб.
Причем в гораздо более лучшем исполнении чем java+gwt.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>Да, можно присыпать так, что и Ur останется далеко позади, только незачем.
Это как?
Можешь показать лишний код?
A>А откуда тут взялся компилятор, вообще не понятно.
А чем ты сахарить собрался?
A>Серверную часть я напишу отдельно, использовав для взаимодействия стандартный протокол, типа JSON-RPC. Тогда у меня будет один сервер и сколько угодно клиентов, не обязательно браузерных.
Ну так ур по сети гоняет все тот же json.
Так что тут никаких проблем нет.
А экономия кода есть.
Например, не нужно два раза писать валидацию данных.
Про мелочи типа того что один и тот же код генерирует ХТМЛ и на сервере и на клиенте я вообще молчу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Да, можно присыпать так, что и Ur останется далеко позади, только незачем. WH>Это как? Можешь показать лишний код?
Читал же, наверняка, тему про ультракороткий язык программирования. (:
A>>А откуда тут взялся компилятор, вообще не понятно. WH>А чем ты сахарить собрался?
Средствами JavaScript, но можно и транслировать, да.
A>>Серверную часть я напишу отдельно, использовав для взаимодействия стандартный протокол, типа JSON-RPC. Тогда у меня будет один сервер и сколько угодно клиентов, не обязательно браузерных. WH>Ну так ур по сети гоняет все тот же json. Так что тут никаких проблем нет. А экономия кода есть. Например, не нужно два раза писать валидацию данных.
Ну, таким уж точно никого не удивишь нынче.
WH>Про мелочи типа того что один и тот же код генерирует ХТМЛ и на сервере и на клиенте я вообще молчу.
Это если нужно под браузером только остаться. А если я хочу клиенты под Android, iPhone и Java2ME?
Здравствуйте, anonymous, Вы писали:
A>Читал же, наверняка, тему про ультракороткий язык программирования. (:
Ултракороткий язык всего навсего кривой ДСЛ для узкого класса задач.
Так что это не в тему.
A>Средствами JavaScript, но можно и транслировать, да.
Какими? Что-то knockuot.js они не помогли.
Куча мусора в коде.
A>Это если нужно под браузером только остаться. А если я хочу клиенты под Android, iPhone и Java2ME?
Не проблема. Я же сказал что ур по сети JSON гоняет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ты в самом деле думаешь что я не смогу переписать код в Continuation-passing style и прерывать поток каждые 1000 редукций?
И на что только люди не готовы пойти ради удобства .
Здравствуйте, Mamut, Вы писали:
НС>>Ты с этим AXD уже лет пять носишься если не больше, вот только надежность пока что это больше вопрос приоритетов разработки, а не языка программирования. Время полностью верифицируемых языков пока не настало.
M>Можно и не AXD301, просто это один из самых ярких примеров.
Это называется читал, но не понял что написано.
M> Данные по другим баируются только на hearsay. Типа
M>
M>В конце Дэвида (http://klarna.com/) спросили: а с технической точки зрения как проявился переход на Erlang? Очень хорошо: 20 Java-машин были заменены 2-мя с Erlang'ом. За последние три года было 48 секунд простоя. Система неубиваема.
Здравствуйте, Mamut, Вы писали:
M>«Назови мне другой источник "надежности" ерланга.» — это было так сказано, в воздух? Я должен был сконцентрироваться только лишь на типизации?
Да! Потому что речь изначально шла о типизации, а не о ерланге.
НС>>Ты путаешь язык и рантайм. Все, что ты перечислил, относится ко второму.
M>И?
Чего, уже забыто все, с чего разговор начинался? Понятно.
Здравствуйте, Gaperton, Вы писали:
G>Я отвечал на зацитированное.
Удивительно вы с Мамутом быстро забыли про контекст разговора.
>> И правда, нафига в том же дотнете все эти TPL и Rx с асинками? Написал несколько простеньких хелперов с лямбдами поверх пула потоков и вуаля, все проблемы решены.
G>Учитывая, что ты при этом не теряешь отладчика в браузере — да, именно так.
Здравствуйте, WolfHound, Вы писали:
A>>Читал же, наверняка, тему про ультракороткий язык программирования. (: WH>Ултракороткий язык всего навсего кривой ДСЛ для узкого класса задач. Так что это не в тему.
А в веб-программировании, как правило, DSL достаточно.
A>>Средствами JavaScript, но можно и транслировать, да. WH>Какими? Что-то knockuot.js они не помогли. Куча мусора в коде.
Не заметил.
A>>Это если нужно под браузером только остаться. А если я хочу клиенты под Android, iPhone и Java2ME? WH>Не проблема. Я же сказал что ур по сети JSON гоняет.
Только он мне не нагенерирует клиентов, поэтому пользы от написания клиента и сервера на одном языке никакой.
Нужен
M>>Что произойдет в случае , если в систему пойдут сообщения в таком порядке, например: WH>хъ M>>в случае твоей линейной системы? WH>В моем случае будет канал с протоколом и сообщения просто физически не смогут прийти не в том порядке.
WH>Компилятор настучит по голове задолго до того как это произойдет. WH>См сингулярити.
Порядок показан правильный, сообщения приходят именно в этом порядке.
НС>>>Ты с этим AXD уже лет пять носишься если не больше, вот только надежность пока что это больше вопрос приоритетов разработки, а не языка программирования. Время полностью верифицируемых языков пока не настало.
M>>Можно и не AXD301, просто это один из самых ярких примеров.
НС>Это называется читал, но не понял что написано.
M>> Данные по другим баируются только на hearsay. Типа
M>>
M>>В конце Дэвида (http://klarna.com/) спросили: а с технической точки зрения как проявился переход на Erlang? Очень хорошо: 20 Java-машин были заменены 2-мя с Erlang'ом. За последние три года было 48 секунд простоя. Система неубиваема.
НС>Маркетинговый булшит.
Вообще-то, именно на этом они мегауспешный бизнес построили
M>>«Назови мне другой источник "надежности" ерланга.» — это было так сказано, в воздух? Я должен был сконцентрироваться только лишь на типизации? НС>Да! Потому что речь изначально шла о типизации, а не о ерланге.
То есть, отвечая на вопрос «Назови мне другой источник "надежности" ерланга.» я обязан оставаться только в рамках системы типов? ты сам не считаешь это идиотизмом?
НС>>>Ты путаешь язык и рантайм. Все, что ты перечислил, относится ко второму.
M>>И?
НС>Чего, уже забыто все, с чего разговор начинался? Понятно.
То есть, отвечая на вопрос «Назови мне другой источник "надежности" ерланга.» я обязан оставаться только в рамках системы типов? ты сам не считаешь это идиотизмом?
Здравствуйте, Mamut, Вы писали:
M>Порядок показан правильный, сообщения приходят именно в этом порядке.
Тут проблема в том, что ты сначала создал проблему, а потом пытаешься ее героически решать костылем.
Если ты сформулируешь исходную задачу то тебе самому станет ясно, как ее решить без этого костыля.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>В JS? Посмотрим, как у тебя получится. А что мне помешает?
Все что мне нужно это указатель на функцию. В JS есть замыкания. Это даже круче.
M>Более того, почему ты утверждаешь, что нельзя будет сделать точно так же на JS?
Для этого тебе придется написать компилятор JS.
M>Значит Ur'у можно, а библиотеке на JS нельзя?
Компилятору можно. А как ты собрался библиотекой код на JS переписывать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Зависит от библиотеки
Не зависит.
M>>>Это мне не даст, по сути, ни один язык, кроме java+gwt, так что мимо кассы. WH>>Это тебе дает ур/веб. M>Да? Где? Я это все скопировал с главной страницы. Ты хочешь сказать, что автор ур врет?
Ну, тогда тебе не составит труда уличить его во лжи.
Только смотри, чтобы как у Гапертона не получилось.
M>Не видно этого исполнения даже в упор. Ну, если ты кашу из html'я среди логики и компиляцию в далеко не самый лучший JS называешь гораздо более лучшим исполнением
Повторю еще раз: Каша там только по тому что автор ученый.
M>Кстати. Почему Ur, а не сверхсупермегапуперкрутой Nemerle?
По тому, что никто такую либу не написал.
M>Зы. Библиотеку, генерящую исходный HTML+JS и контролирующую все то же можно написать на любом языке программирования
БРЕД!
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Порядок показан правильный, сообщения приходят именно в этом порядке. WH>Тут проблема в том, что ты сначала создал проблему, а потом пытаешься ее героически решать костылем.
Я ее не создавал. Я задал конкретный вопрос на который ожидал конкретный ответ, а не юление.
WH>Если ты сформулируешь исходную задачу то тебе самому станет ясно, как ее решить без этого костыля.
M>>В JS? Посмотрим, как у тебя получится. WH> А что мне помешает? WH>Все что мне нужно это указатель на функцию. В JS есть замыкания. Это даже круче.
M>>Более того, почему ты утверждаешь, что нельзя будет сделать точно так же на JS? WH>Для этого тебе придется написать компилятор JS.
С какого перепугу?
M>>Значит Ur'у можно, а библиотеке на JS нельзя? WH>Компилятору можно. А как ты собрался библиотекой код на JS переписывать?
WH>>> Библиотеки не убирают весь мусор. M>>Зависит от библиотеки WH>Не зависит.
Ну, согласен, зависит и от языка тоже.
M>>>>Это мне не даст, по сути, ни один язык, кроме java+gwt, так что мимо кассы. WH>>>Это тебе дает ур/веб. M>>Да? Где?
WH> Я это все скопировал с главной страницы. Ты хочешь сказать, что автор ур врет? WH>Ну, тогда тебе не составит труда уличить его во лжи. WH>Только смотри, чтобы как у Гапертона не получилось.
Да, вопрос задан некорректно.
M>>Не видно этого исполнения даже в упор. Ну, если ты кашу из html'я среди логики и компиляцию в далеко не самый лучший JS называешь гораздо более лучшим исполнением WH>Повторю еще раз: Каша там только по тому что автор ученый.
Ты не в курсе, что доказательство тезиса лежит на плечах выдвинувшего тезис?
Твое утверждение:
Все это (тут ижет список с главной страницы) ur делает лучше, чем Java/GWT. Я поставил этот тезис под сомнение. Доказательств того, что он делает это лучше не видно в упор.
M>>Кстати. Почему Ur, а не сверхсупермегапуперкрутой Nemerle? WH>По тому, что никто такую либу не написал.
M>>Зы. Библиотеку, генерящую исходный HTML+JS и контролирующую все то же можно написать на любом языке программирования WH>БРЕД!
Ггггг. Ты хочешь мне сказать, что невозможно написать генератор исходного HTML+JS на каком-либо языке? Может ты эта, перегрелся? Ну или расскажи мне, почему это бред
Нет, давай так. По пунктам
1. Ты на ur решаешь некоторую задачу — да/нет?
2. При компиляции ur генерирует HTML+JS — да/нет?
3. Вызовы в JS связаны с коллбэками на сервере — да/нет?
4. Ничего не мешает реализовать такое же для любого другого языка программирования — да/нет? Прежде, чем скажешь «нет» или «бред», расскажи мне, как тогда в природе существует GWT
WH>>>Какими? Что-то knockuot.js они не помогли. Куча мусора в коде. A>>Не заметил. WH>Например, все, что начинается с "ko.", скобки после вызова свойств.
Здравствуйте, Mamut, Вы писали:
WH>>Если ты сформулируешь исходную задачу то тебе самому станет ясно, как ее решить без этого костыля. M>Это не костыль.
Ну так ты задачу то сформулируешь или как?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>>>Если ты сформулируешь исходную задачу то тебе самому станет ясно, как ее решить без этого костыля. M>>Это не костыль. WH>Ну так ты задачу то сформулируешь или как?
У тебя есть сервер, обрабатывающий входящие сообщения.
Здравствуйте, Mamut, Вы писали:
M>Все это (тут ижет список с главной страницы) ur делает лучше, чем Java/GWT. Я поставил этот тезис под сомнение. Доказательств того, что он делает это лучше не видно в упор.
Ну так продемонстрируй хотябы реактивность на Java/GWT.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
WH>>Для этого тебе придется написать компилятор JS. M>С какого перепугу?
А как ты собрался без компилятора код переписывать?
Востановим контекст: M>>>>>Ах, да, я помню. Там еще было «замучаешься писать sleep в потоке на JS» при том, что JS, в который компилируется Ur, это умеет WH>>>>Умеет он это по тому, что переписывает код в жуткую лапшу. Ну, ты ее сам видел. Есть желание самому такой писать? WH>>>>Думаю что нет. M>>>Значит Ur'у можно, а библиотеке на JS нельзя? WH>>Компилятору можно. А как ты собрался библиотекой код на JS переписывать? M>Зачем мне переписывать код на JS? M>Может хватит пороть чушь?
Вот теперь ответь не вопрос: Кто тут чушь порет?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
WH>>>>Если ты сформулируешь исходную задачу то тебе самому станет ясно, как ее решить без этого костыля. M>>>Это не костыль. WH>>Ну так ты задачу то сформулируешь или как? M>У тебя есть сервер, обрабатывающий входящие сообщения.
Что за сервер?
Что за сообщения?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Все это (тут ижет список с главной страницы) ur делает лучше, чем Java/GWT. Я поставил этот тезис под сомнение. Доказательств того, что он делает это лучше не видно в упор. WH>Ну так продемонстрируй хотябы реактивность на Java/GWT.
Реактивное программирование — парадигма программирования ориентированная на потоки данных и распространении изменений.
1. Надо еще убедится, что она есть в ur
2. Что именно тебе надо?
WH>>>Для этого тебе придется написать компилятор JS. M>>С какого перепугу? WH>А как ты собрался без компилятора код переписывать?
Нахрена мне его переписывать?
WH>Востановим контекст: M>>>>>>Ах, да, я помню. Там еще было «замучаешься писать sleep в потоке на JS» при том, что JS, в который компилируется Ur, это умеет WH>>>>>Умеет он это по тому, что переписывает код в жуткую лапшу. Ну, ты ее сам видел. Есть желание самому такой писать? WH>>>>>Думаю что нет. M>>>>Значит Ur'у можно, а библиотеке на JS нельзя? WH>>>Компилятору можно. А как ты собрался библиотекой код на JS переписывать? M>>Зачем мне переписывать код на JS? M>>Может хватит пороть чушь? WH>Вот теперь ответь не вопрос: Кто тут чушь порет?
Ты, конечно.
Ты предлагаешь переписать Ur так, чтобы он компилировался в JS (!) и для решения «проблемы» с sleep или длительными вычислениями в разных потоков (которых в JS пока что нет) ты предалагаешь переписать компилятор так, чтобы Ur компилировался в JS (!) но в другом стиле (редукции, CPS и т.п.).
Так как результатом будет все равно JS, возникает вопрос. Что мешает сделать то же самое средствами самого JS?
То есть, что мешает написать библиотеку/обертку, которая будет прятать весь этот boilerplate за приятным библиотечным интерфейсом? Казалось бы, никто. Ах, да, мешает Wolfhound. Который уверен, что если что-то реализовано на JS, то нет никакой возможности эту реализацию упаковать в обертку
Но ведь у Wolfhound'а нет других аргументов против этого, кроме:
— тебе надо переписывать код на JS
— тебе надо писать компилятор
— кода больше, чем на Ur
Первые два утверждения явно ложны, потому что обертки над чем угодно нам писать никто не запрещает.
Третье утверждение не представляет интереса, если разница в коде вычисляется единицами процентов
WH>>>>>Если ты сформулируешь исходную задачу то тебе самому станет ясно, как ее решить без этого костыля. M>>>>Это не костыль. WH>>>Ну так ты задачу то сформулируешь или как? M>>У тебя есть сервер, обрабатывающий входящие сообщения. WH>Что за сервер? WH>Что за сообщения?
Сервер. В сети.
Сообщения — любые:
— показания с датчиков (для некоторых сообщений важен порядок)
— поток данных с биржи (или нескольких бирж)
— любой другой поток сообщений
Порядок входящих сообщений, понятное дело, ты контролировать не можешь
Здравствуйте, Mamut, Вы писали:
M>- показания с датчиков (для некоторых сообщений важен порядок) M>- поток данных с биржи (или нескольких бирж) M>- любой другой поток сообщений
И зачем тут selective receive?
Чем простая очередь не подходит?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Так как результатом будет все равно JS, возникает вопрос. Что мешает сделать то же самое средствами самого JS? WH>Клиника.
В твоем случае — да. Внятного объяснения, почему супепупермногопоточность Ur'а невозможно точно так же реализовать в JS так и не получено. Абсолютно все твои аргументы сводятся к
— Нужно писать компилятор
— Нужно переписать JS
— Не получится
— Клиника
Хотя казалось бы. Если это невозможно, и тебе понятно, почему, достаточно написать два-три предложения, объясняя это
M>>- показания с датчиков (для некоторых сообщений важен порядок) M>>- поток данных с биржи (или нескольких бирж) M>>- любой другой поток сообщений WH>И зачем тут selective receive? WH>Чем простая очередь не подходит?
Разные сообщения обрабатываются по разному, для некоторых (не всех) сообщений важен порядок их поступления
Здравствуйте, WolfHound, Вы писали:
G>>Не-не-не, не надо никаких sleep-ов никуда втыкать. G>>Повтори вот этот код Worker-а в "потоке" на своем мегаязыке — без delay-ев. WH>Мне еще сколько десятков раз написать, что потоки кооперативные?
Неужели. И чем же твои недопотоки лучше полноценных из html5? Тем, что надо ручками точки прерывания расставлять? Или, может быть, тем, что они на многоядерных процах не параллелятся?
WH>С другой стороны это дает возможность спокойно работать с данными без плясок с бубном.
Неужели. А в чем именно проблема "работать с данными без плясок с бубном" из настоящего потока — worker-а, в котором я могу преспокойно выполнять AJAX-запросы синхронно безо всякой магии?
Ну вот нахрена мне твои недопотоки, если в HTML5 есть полноценные из коробки, а? Раскрой тему, пожалуйста, страсть как интересно.
G>>Этого, ты, разумеется, тоже не знал, да? WH>Да я прекрасно понимаю, что такое этот твой воркер. WH>Похоже, что даже лучше чем ты.
Увы, не похоже. Похоже на то, что тебя поймали на явной глупости, а ты выкручиваешься вместо того, чтобы признать неправоту. Ниче, бывает.
Здравствуйте, Gaperton, Вы писали:
G>Боишься, что теперь Маммут, как Гапертон, тебя в очередной раз на незнании предмета поймает? Он может.
Ну так как признаешь что был не прав или как?
Не вижу здесь динамически обновляемых фрагментов DOM, анимации, и обработки событий, характерных для модели страницы браузера. "Засунуть" это в браузер можно, но получится редкостное убожество, ибо на модель браузера это ни разу не заточено.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Неужели. И чем же твои недопотоки лучше полноценных из html5? Тем, что надо ручками точки прерывания расставлять?
Тем, что мне не нужно плясать с бубном вокруг посылки сообщений.
G>Или, может быть, тем, что они на многоядерных процах не параллелятся?
Ну и нахрена оно для организации ГУИ нужно?
G>Неужели. А в чем именно проблема "работать с данными без плясок с бубном" из настоящего потока — worker-а, в котором я могу преспокойно выполнять AJAX-запросы синхронно безо всякой магии?
Ну обнови дом находясь в потоке воркере
Что? Не можешь?
Нужно сообщения в основной поток слать... калбеки городить.
G>Увы, не похоже. Похоже на то, что тебя поймали на явной глупости, а ты выкручиваешься вместо того, чтобы признать неправоту. Ниче, бывает.
Явные глупости пишешь ты.
Сначала не увидел что ур вполне себе реагирует на события.
Потом вместо линейного кода написал лапшу на калбеках.
Для обращения к серверу накатал десяток строк, в то время как уру достаточно трех букв.
Теперь вот не можешь понять, что кооперативные потоки для работы с ГУИ банально удобнее полноценных.
А самое главное ты настырно пытаешься уйти от изначальной темы, ибо понял, что ур с ГУИ справляется лучше, чем жабаскрипт со всеми своими библиотеками и твои утверждения о том, что тут динамика рулит, рассыпались в пыль.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>Ur в принципе не может ничего сделать лучше, чем JavaScript, поскольку транслируется в него. Единственное и несущественное его достоинство — он предоставляет привычные средства для некоторых разработчиков.
Конечно же, может.
Просто по тому, что в случае с ур нужно писать меньше.
Причем не за счет мутных сокращений, а за счет того что решение получается в терминах изначальной задачи (динамический ГУИ).
A>А динамика тут вообще не при чём.
Ну, так она вообще не нужна.
Ибо каждый раз, когда начинаешь разбирать задачу, начиная от изначальной постановки решение на статике, оказывается не хуже.
И эта ветка прекрасно это демонстрирует.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>То есть, отвечая на вопрос «Назови мне другой источник "надежности" ерланга.» я обязан оставаться только в рамках системы типов? ты сам не считаешь это идиотизмом?
M>>То есть, отвечая на вопрос «Назови мне другой источник "надежности" ерланга.» я обязан оставаться только в рамках системы типов? ты сам не считаешь это идиотизмом?
НС>Я считаю демагогией попытки ухода от темы.
Итак. Был задан вопрос: «Назови мне другой источник "надежности" ерланга.» . Что, по-твоему, я должен был на него ответить?
Здравствуйте, Mamut, Вы писали:
M>Борец с синтаксическим оверхедом детектед
Что аргументы совсем закончились?
Запомни: Все языки высокого уровня борются с синтаксическим оверхедом.
Борьба с синтаксическим оверхедом это просто смысл существования ЯВУ.
M>При чем тут статика к конкретно этому примеру?
При том, что Гапертон утверждал что я озверею делать этот пример на статике. Как видим не только не озверел, но решение получилось даже лучше чем каноническое на жабоскрипте.
Других задач, где нужна динамика продемонстрировано не было.
А раз любители динамики не могут сказать какие же задачи динамика решает лучше чем статика то можно сделать вывод что никакие.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Ты мне лучше объясни, почему
По тому что это невозможно сделать библиотекой.
M>1. Ты делаешь максимально общее заявление (например, что пример из Ur'а на JS сделать очень сложно)
Я показываю конкретный пример и прошу его воспроизвести.
На что мне приводят код, который делает совсем не то, что делает изначальный пример.
Ну и как на такое реагировать?
M>Но, к сожалению, ты не способен это понять, потому что тот самый парадокс блаба в тебе проявляется в максимальной степени.
У меня его нет.
Парадокс Блаба говорит о том, что человек не может понять, зачем нужна некая конструкция в языке.
Я же прекрасно понимаю, что делает код, который привел Гапертон.
Но в отличие от вас я также понимаю, чем этот код хуже.
M>Что ты там хотел? Рактивное программирование для GWT? Ну есть, например, http://code.google.com/p/reactive4java/
Это мягко говоря не то.
Ты сейчас ведешь себя точно также как anonymous утверждая, что в жабоскрипте есть паттерн матчинг.
M>Но ты начнешь рассказывать сказки про скобочки и реальную многопоточность, как пить дать. То, что, при желании, можно написать библиотеку, которая вообще позволит задать все это декларативно (даже в Java) тебе в голову даже и не придет.
Дело в том, что я прекрасно знаю возможности жабы.
И в случае с жабой синтаксический оверхед будет таким что закачаешься.
M>Если, не дай бог, кто-то найдет и такую библиотеку, ты заузишь задачу еще больше до тех пор, пока не придешь к п.3.
Без компилятора то не сделать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Ты мне лучше объясни, почему WH>По тому что это невозможно сделать библиотекой.
Невозможно сделать что? Тебе контекст восстановить?
Библиотеку, генерящую исходный HTML+JS и контролирующую все то же можно написать на любом языке программирования
Все, что делает Ur — это генерит HTML+JS. По сути, это DSL для чего-то там. Любой язык, позволяющий создавать DSL'и способен сделать Ur (Lisp, Haskell, Ruby). Более того, в любом языке с достаточно высокоуровневыми конструкциями (типа ФВП и continuation'ами) достаточно легко сделать библиотеку, генерирующую на выходе HTML+JS и обрабатывающую входящую информацию. Причем эта библиотека (в зависимости от языка) может быть достаточно простой и изящной.
Гы, чем Ur отличается от любимой Шериданом Kalpa/Vedga? Да ничем
M>>1. Ты делаешь максимально общее заявление (например, что пример из Ur'а на JS сделать очень сложно) WH>Я показываю конкретный пример и прошу его воспроизвести. WH>На что мне приводят код, который делает совсем не то, что делает изначальный пример.
Ой да ну?
WH>Ну и как на такое реагировать?
Спокойно.
M>>Но, к сожалению, ты не способен это понять, потому что тот самый парадокс блаба в тебе проявляется в максимальной степени. WH>У меня его нет. WH>Парадокс Блаба говорит о том, что человек не может понять, зачем нужна некая конструкция в языке. WH>Я же прекрасно понимаю, что делает код, который привел Гапертон. WH>Но в отличие от вас я также понимаю, чем этот код хуже.
Дадада.
A>почему вспотеешь это делать,
Ну покажи мне клиентскую многопоточность на жабаскрипте.
Там [в Ur] наблюдаются настоящие кооперативные потоки.
Ну и прочая броедятина в этом стиле показывает, как «хорошо» ты понимаешь, как работает тот же Ur, ага
Я уже один раз спрашивал, что именно тебе нужно. Я же говорил, ты намеренно говоришь максимально общими словами, а когда тебя ловят на том, что твои утверждения ложны, начинаешь придумывать все новые и новые рамки, которые в конечном итоге дадут только один язык (сейчас Ur, а обычно — Немерле).
Тебе твои слова повторить?
M>Все это (тут ижет список с главной страницы) ur делает лучше, чем Java/GWT. Я поставил этот тезис под сомнение. Доказательств того, что он делает это лучше не видно в упор.
Ну так продемонстрируй хотябы реактивность на Java/GWT.
Я продемонстрировал реактивность на Java/GWT Google —> "GWT reactive programming" —> первая ссылка. Теперь это «опять не то»
WH>Ты сейчас ведешь себя точно также как anonymous утверждая, что в жабоскрипте есть паттерн матчинг.
Ты отрицаешь возможность создания библиотеки для реактивного программирования для Java вообще и для GWT в частности?
M>>Но ты начнешь рассказывать сказки про скобочки и реальную многопоточность, как пить дать. То, что, при желании, можно написать библиотеку, которая вообще позволит задать все это декларативно (даже в Java) тебе в голову даже и не придет. WH>Дело в том, что я прекрасно знаю возможности жабы. WH>И в случае с жабой синтаксический оверхед будет таким что закачаешься.
M>>Если, не дай бог, кто-то найдет и такую библиотеку, ты заузишь задачу еще больше до тех пор, пока не придешь к п.3. WH>Без компилятора то не сделать.
Здравствуйте, Mamut, Вы писали:
M>Да, но не в стиле
И в нем тоже.
Например, во втором C# появились анонимные делегаты. Но ими почти никто не пользовался, ибо писать много. В третьем добавили простейший сахар и народ начал использовать.
Та же фигня с linq.
А в данном случае все совсем плохо.
Мало того что этот мусор нужно написать так еще и никто по рукам не даст если забудешь. Программа просто молча будет делать не то что нужно.
M>Оказалось, что не вспотели оба. И?
Вот только началось все с:
WH>Может ты покажешь задачу где нужна динамическая типизация?
Я тебе ее показываю. Это работа с отрисовкой веб-страницы и сетью в браузере.
И как оказалось статика справляется ничуть не хуже.
M>Пока что ты не показал, чем статика круче динамики Конекретно на приведенных примерах
Было утверждение, что динамика круче статики на данных примерах.
Чтобы его опровергнуть мне нужно было показать решение как минимум не хуже.
Я показал решение, которое даже лучше.
А если добавить сюда плюсы статики как таковой, то получается что динамика слила с треском.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Все, что делает Ur — это генерит HTML+JS. По сути, это DSL для чего-то там. Любой язык, позволяющий создавать DSL'и способен сделать Ur (Lisp, Haskell, Ruby).
Другими словами любой язык, который позволяет вмешиваться в работу собственного компилятора/интерпретатора.
M>Более того, в любом языке с достаточно высокоуровневыми конструкциями (типа ФВП и continuation'ами) достаточно легко сделать библиотеку, генерирующую на выходе HTML+JS и обрабатывающую входящую информацию. Причем эта библиотека (в зависимости от языка) может быть достаточно простой и изящной.
Все равно будет тонна синтаксического оверхеда.
И не будет нормальных проверок.
M>Гы, чем Ur отличается от любимой Шериданом Kalpa/Vedga? Да ничем
Полный звездец.
Ур RESTful до мозга костей.
WH>>Я показываю конкретный пример и прошу его воспроизвести. WH>>На что мне приводят код, который делает совсем не то, что делает изначальный пример. M>Ой да ну?
Что да ну? Мне вместо простого линейного кода показали лапшу на каллбеках.
M>Ну и прочая броедятина в этом стиле показывает, как «хорошо» ты понимаешь, как работает тот же Ur, ага
Я то понимаю. А ты?
Что такое кооперативная многозадачность знаешь?
Или слышишь в первый раз?
M>Я уже один раз спрашивал, что именно тебе нужно. Я же говорил, ты намеренно говоришь максимально общими словами, а когда тебя ловят на том, что твои утверждения ложны, начинаешь придумывать все новые и новые рамки, которые в конечном итоге дадут только один язык (сейчас Ur, а обычно — Немерле).
Ну значит в жабаскрипте есть паттернмачинг.
M>Я продемонстрировал реактивность на Java/GWT Google —> "GWT reactive programming" —> первая ссылка. Теперь это «опять не то»
Это такая же реактивность как регексы паттернмачинг.
M>Ты отрицаешь возможность создания библиотеки для реактивного программирования для Java вообще и для GWT в частности?
Ну с тонной синтаксического (и не только) оверхеда может что-то и получится. Полноту по Тьюрингу ни кто не отменял. Но нахрена оно такое надо? Там же черт ногу сломит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>>>Все равно будет тонна синтаксического оверхеда. M>>Не обязательно WH>Практика показывает что обязательно.
WH>>>И не будет нормальных проверок. M>>Теперь полключаем твою любимую статику и? WH>Как? У нас компилятора то нет.
Блин. Причем тут компилятор???? Берешь в руки GWT — у тебя генерируется HTML+JS. Добавляешь к нему reactivejava, у тебя есть реактивность. Да еще и со столь любимой тобой статикой
M>>Каша там только в твоей голове. А делает этот код, если я не ошибаюсь, то же самое (с разными интервалами выводит на странице текст). WH>Каша там в коде. WH>У Гапертона два калбека в то время как в оригинале 0.
В оригинале там Buffer.write, как минимум
M>>Особой разницы с Ur'ом нет. WH>Куча лишнего кода на ровном месте это конечно ерунда. M>>Единственная «разница» в том, что не явно отправляются сообщения, а вызывается Buffer.write и Buffer.render WH>Buffer.render вызывается один раз. WH>Дальше всю работу делает реактивность.
Которая где-то там упрятана в недрах Ur'а. И? Тебе написать обертку над достаточно низкоуровневым кодом Гапертона религия не позволяет?
M>>Пример, описанный Гапертоном более низкоуровневый, что не мешает ео уложить в настолько же прямолинейную обертку WH>Ну попробуй.
runWorkerJS взят отсюда: https://gist.github.com/989438. Код там страшный, потому что в W3C, как всегда, придумали какую-то хрень Код не тестировался, так, для иллюстрации идеи.
Достаточно generic обертка будет выглядеть, естественно, по-другому. По сути, runWorkerJs уже достаточно.
M>>И ты еще утверждаешь, что это гуано лучше, чем полноценная многозадачность, которую привел Gaperton? WH>Это "гуано" позволяет писать прямолинейный код без кучи каллбеков.
Который не будет работать чуть более, чем во всех реальных случаев из-за реализации, но это е тебя не волнует, так ведь
M>>И ты еще утверждаешь, что ее же невозможно реализовать средствами JS? WH>Без тонный синтаксического оверхеда не получится.
Ну да, я помню, что такое твой синтаксичесий оверхед. Скобочки там, ага
M>>То есть, внятно объяснить, что именно тебе надо, ты не в состоянии. WH>То есть ты не в состоянии посмотреть на то, как работает ур?
Смотрю я на Ur. Конкретно в данный момент я смотрю на threads. Ничего сверхъестественного там нет. Ну сахар и сахар Пишешь тонкий враппер над Гапертоновским кодом и радуешься жизни. Если то вообще надо...
Смотрю на ListEdit. Ну, сигналы/слоты Вау. Это и есть реактивность? А, нет, наверное «реактивность» это установка значений вручную вот так:
<button value="Change to:" onclick={s <- get ss'; set ss s}/>
<li onmousedown={set draggingItem (Some itemSource)}
onmouseup={set draggingItem None}
onmouseover={di <- get draggingItem;
case di of
None => return ()
| Some di => original <- get di;
movedOver <- get itemSource;
set di movedOver;
set itemSource original;
set draggingItem (Some itemSource)}>
<dyn signal={Monad.mp cdata (signal itemSource)}/>
</li></xml>
Вся «реактивность» заключается в сахаре над signal/slots
И этот человек мне говорит, что вот это вот нельзя реализовать в библиотеке для любого серверного языка? Ах, да, signal/slot есть и для JS. Правда, для тебя он будет слишком многословным, видать.
WH>Ну посмотри на knockuot.js там реактивность правильная. WH>Но с кучей синтаксического оверхеда.
Его не так много, чтобы этого кого-либо парило, кроме тебя
M>>Напомню контекст. Ты утверждал, что сделать что-то, что делает Ur, билиотекой невозможно. Оказалось, что не только возможно, но и делают. Единственный твой аргумент — это «синтаксический оверхед» WH>Так это единственный смысл существования яву. WH>Есть лишь один способ сравнить уровень языков это сравнить сколько кода будет написано при решении одной и той же задачи.
Самый крутой — мой язык. Там есть одна функция, «сделатьОхрененно()» Я частично согласен с тобой в определении, до тех пор пока это не превращается в абсурд. Потому что бесспорным победителем (на определенном классе задач) выйдет какой-нибудь J.
M>>Внятно объяснить, что именно тебе надо, ты не в состоянии. Хотя — нет, можешь даже не утруждать себя. Тебе надо, чтобы оно выглядело, как Ur, вело себя,к ак Ur, и до последней запятой содержало абсолютно точно такое же количество букв, как Ur. WH>Аргументы совсем кончились.
У тебя — да. Почему реактивнотсь для GWT — это не то, ты так и не объяснил.
Почему невозможно реализовать библиотекой (на Java/C++/Python/Ruby/хрен знает что там еще) то, что реализует Ur, ты так и не объяснил. Твой единственный «аргумент» — это «Без компилятора не получится».
Здравствуйте, Mamut, Вы писали:
M>Я так понимаю, в четвертый раз спрашивать, какая именно тебе реактивность смысла нет. Ведь все равно не ответишь.
Я тебе уже не раз показал.
M>Блаб, он и есть блаб. То, что в каком-то другом языке делается что-то не так, все, ты решаешь, что тот язык — гуано.
Язык гуано по тому, что заставляет писать кучу кода, который можно не писать.
M>В случае с Ur'ом ты пишешь структуру, внутри которой пишешь функцию, которая что-то делает. Потом вызываешь эту функцию.
В случае с ур я просто пишу функцию.
M>В другом языке ты пишешь функцию, которую передаешь в другую функцию, и она вызывает первую.
В случае с жабоскриптом мне придется возиться с калбеками.
M>Достаточно коротко, не находишь? То, что в враппере callback'и тебя интересовать не должно. M>
M>Ты пойми мне абсолютно пофигу что там генерируется.
M>Тебе должно быть пофиг, как оно там реализовано.
Мне пофигу что там генерируется.
Но не пофигу что нужно писать руками.
И в твоём случае все это безобразие нужно писать руками.
А если нужно больше одного калбека то будет все совсем весело.
M>Что я и говорил. ты все пытаешься свести к тому, чтобы все, абсолютно все выглядело и было реализовано один-в-один ровно так же и точно такими же терминами, словами и буквами, как и (в данном случае Ur| обычно Nemerle).
Я пытаюсь добиться чистого кода без костылей.
Калбеки создают кучу грязи в коде.
Особенно если нужно в основном потоке дергать больше одного калбека.
M>Не только им. Любым достаточно длинным процессом. Например, синхронным Ajax-вызовом.
Ну попробуй
Ajax вызов это одно из мест, на котором происходит переключение контекста.
Так что только большим циклом с вычислениями.
M>Угу. Я вот боюсь, если вдруг ты ударишься в коллбэки и будешь ьтребовать код только с ними, но ни в коем случае с «просто изменяемой структурой данных в которую добавляют данные»
Вертись дальше... Это уже смешно.
Что так трудно признать, что код на жабоскрипте без костылей не написать?
M>Как минимум не напрямю в HTML-коде.
Я уже несколько раз говорил что это из-за того что автор ученый.
Сам язык не мешает разделить ViewModel и View как следует.
M>Вау. Да неужели. там работает банальный slot/signal механизм, на который еще подписываться надо вручную:
БРЕД!
Это не slot/signal.
Учи матчасть.
M>Дадададдада. Это, конечно, В РАЗЫ лучше, чем ko.obervable сотоварищи, ага
Тем что синтаксического мусора меньше. И все на этапе компиляции проверяется.
M>>>Его не так много, чтобы этого кого-либо парило, кроме тебя WH>>Его достаточно чтобы было верно утверждение что ур лучше жабоскрипта для ГУИ. M>БРЕД!
Факт.
WH>>По тому, что это совсем другая реактивность. M>Какая — другая?
Выключи уже anonymous мод и разберись с матчастью.
Сравни ту реактивность, что ты мне суешь с тем, что реализовано в knockuot.js и ур.
M>Что я и говорил. ты все пытаешься свести к тому, чтобы все, абсолютно все выглядело и было реализовано один-в-один ровно так же и точно такими же терминами, словами и буквами, как и (в данном случае Ur| обычно Nemerle).
Я пытаюсь получить чистое решение без мусора.
Ты его показать не можешь.
Поэтому включил дурака и пытаешься выехать на демагогии.
M>Но начнем с другого бока. Сначала ты ответишь на мой вопрос, а потом я буду под тебя прогибаться, давай?
Я уже на него несколько раз отвечал.
M>Итак, вопрос: Почему невозможно реализовать библиотекой (на Java/C++/Python/Ruby/хрен знает что там еще) то, что реализует Ur?
По тому, что библиотечная реализация приведет к тоннам сиснтаксического мусора.
Например, в knockuot.js есть куча всякой байды, которая начинается с "ko.", нужно писать () при доступе к реактивным объектам,...
А главное что если это забыть тебе никто не скажет об этом.
Просто программа не будет работать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Я так понимаю, в четвертый раз спрашивать, какая именно тебе реактивность смысла нет. Ведь все равно не ответишь. WH>Я тебе уже не раз показал.
Ты показал ЧТО? Банальный сигнал/слот и назвал это реактивностью. ВАУ.
M>>Не только им. Любым достаточно длинным процессом. Например, синхронным Ajax-вызовом. WH>Ну попробуй WH>Ajax вызов это одно из мест, на котором происходит переключение контекста.
Ах, да. Я забыл, что ты УВЕРЕН, что в Ur Ajax-вызовы синхронные, ага
WH>Так что только большим циклом с вычислениями.
M>>Вау. Да неужели. там работает банальный slot/signal механизм, на который еще подписываться надо вручную: WH>БРЕД! WH>Это не slot/signal. WH>Учи матчасть.
А что, это, по-твоему? Опиши механизм работы того дела в Ur'е.
M>>>>Его не так много, чтобы этого кого-либо парило, кроме тебя WH>>>Его достаточно чтобы было верно утверждение что ур лучше жабоскрипта для ГУИ. M>>БРЕД! WH>Факт.
Только в твоем воспаленном воображении.
WH>>>По тому, что это совсем другая реактивность. M>>Какая — другая? WH>Выключи уже anonymous мод и разберись с матчастью. WH>Сравни ту реактивность, что ты мне суешь с тем, что реализовано в knockuot.js и ур.
Нет. Сравнивать тебе. Ты тезис выдвинул, тебе и доказывать.
M>>Что я и говорил. ты все пытаешься свести к тому, чтобы все, абсолютно все выглядело и было реализовано один-в-один ровно так же и точно такими же терминами, словами и буквами, как и (в данном случае Ur| обычно Nemerle). WH>Я пытаюсь получить чистое решение без мусора. WH>Ты его показать не можешь. WH>Поэтому включил дурака и пытаешься выехать на демагогии.
Дурака включаешь только ты. Ты выдвинул и постоянно выдвигаешь условия, которые в итоге приведут к Ur'у и только к Ur'у. То тебе не нравятся скобки, то тебе не нравится еще что-то. Понятно, что ты не примешь ни одного решения, которое будет отличаться от решения на Ur'е даже на один символ.
M>>Но начнем с другого бока. Сначала ты ответишь на мой вопрос, а потом я буду под тебя прогибаться, давай? WH>Я уже на него несколько раз отвечал.
Ты ни разу на него не ответил. Ниже.
M>>Итак, вопрос: Почему невозможно реализовать библиотекой (на Java/C++/Python/Ruby/хрен знает что там еще) то, что реализует Ur? WH>По тому, что библиотечная реализация приведет к тоннам сиснтаксического мусора.
Тонны существуют только в твоей голове.
WH>Например, в knockuot.js есть куча всякой байды, которая начинается с "ko.", нужно писать () при доступе к реактивным объектам,...
Вау. Да. Код возрастет на 10%. Это — да, это, безусловно, тонны. То, что в ur'е на каждый чих надо писать <dyn signal="название функции с параметрами"> это тебя не смущает, ага
WH>А главное что если это забыть тебе никто не скажет об этом. WH>Просто программа не будет работать.
То естьты опять прицепился к JS b только к JS.
Повторю вопрос еще раз. Специяльно для дислексиков и неосиляторов выделяю то, что они (дислексики и неосиляторы) пердпочитают не читать и не воспринимать.
Почему невозможно реализовать библиотекой (на Java/C++/C#/Python/Ruby/хрен знает что там еще) то, что реализует Ur?
Здравствуйте, Mamut, Вы писали:
M>Ты показал ЧТО? Банальный сигнал/слот и назвал это реактивностью. ВАУ.
Это не сигнал/слот.
M>Ах, да. Я забыл, что ты УВЕРЕН, что в Ur Ajax-вызовы синхронные, ага
В коде на ур безусловно.
А то, что оно будет переписано компилятором в асинхронную лапшу это отдельная история.
M>Только в твоем воспаленном воображении.
Я вроде показал уже кучу кода.
В ответ получил только лапшу на калбеках.
M>Нет. Сравнивать тебе. Ты тезис выдвинул, тебе и доказывать.
Выключи уже anonymous мод и разберись с матчастью.
M>Дурака включаешь только ты. Ты выдвинул и постоянно выдвигаешь условия, которые в итоге приведут к Ur'у и только к Ur'у. То тебе не нравятся скобки, то тебе не нравится еще что-то. Понятно, что ты не примешь ни одного решения, которое будет отличаться от решения на Ur'е даже на один символ.
Ну что поделать, если в ур нет почти ничего лишнего.
А то, что ты не можешь показать код, не страдающий описанными недостатками то это говорит только о том, что жабаскрипт крив.
M>Тонны существуют только в твоей голове.
Я тебе их показал.
Но ты тупо повторяешь, что ничего не видишь.
M>Почему невозможно реализовать библиотекой (на Java/C++/C#/Python/Ruby/хрен знает что там еще) то, что реализует Ur?
Повторяю для тех, кто не умеет читать: По тому, что это приведет к тоннам мусора в коде.
Если ты считаешь, что не приведет, то решение в студию.
Короче ты, как и анонимус тупо уперся рогом и не хочешь видеть факты.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>Нет. Сравнивать тебе. Ты тезис выдвинул, тебе и доказывать. WH>Выключи уже anonymous мод и разберись с матчастью.
Попрошу не поминать меня всуе.
M>>Дурака включаешь только ты. Ты выдвинул и постоянно выдвигаешь условия, которые в итоге приведут к Ur'у и только к Ur'у. То тебе не нравятся скобки, то тебе не нравится еще что-то. Понятно, что ты не примешь ни одного решения, которое будет отличаться от решения на Ur'е даже на один символ. WH>Ну что поделать, если в ур нет почти ничего лишнего. А то, что ты не можешь показать код, не страдающий описанными недостатками то это говорит только о том, что жабаскрипт крив.
В Ur/Web нет ничего лишнего лишь потому, что это DSL под конкретную задачу. А JavaScript — язык общего назначения. Сравнивать их по синтаксическому оверхеду некорректно.
Здравствуйте, WolfHound, Вы писали:
A>>А в веб-программировании, как правило, DSL достаточно. WH>ДСЛ они разные.
Спасибо, кэп. По делу-то есть что сказать?
WH>>>Какими? Что-то knockuot.js они не помогли. Куча мусора в коде. A>>Не заметил. WH>Например, все, что начинается с "ko.", скобки после вызова свойств.
Это не мусор.
A>>Только он мне не нагенерирует клиентов, поэтому пользы от написания клиента и сервера на одном языке никакой. WH>Да какая ему разница что генерировать?
Очевидно, разница есть, поскольку клиенты для разных платформ устроены совершенно по разному, да и интерфейс у них различается в общем случае.
M>>>Нет. Сравнивать тебе. Ты тезис выдвинул, тебе и доказывать. WH>>Выключи уже anonymous мод и разберись с матчастью.
A>Попрошу не поминать меня всуе.
M>>>Дурака включаешь только ты. Ты выдвинул и постоянно выдвигаешь условия, которые в итоге приведут к Ur'у и только к Ur'у. То тебе не нравятся скобки, то тебе не нравится еще что-то. Понятно, что ты не примешь ни одного решения, которое будет отличаться от решения на Ur'е даже на один символ. WH>>Ну что поделать, если в ур нет почти ничего лишнего. А то, что ты не можешь показать код, не страдающий описанными недостатками то это говорит только о том, что жабаскрипт крив.
A>В Ur/Web нет ничего лишнего лишь потому, что это DSL под конкретную задачу. А JavaScript — язык общего назначения. Сравнивать их по синтаксическому оверхеду некорректно.
Да ладно, вот тебе уровень аргументации Wolfhound'a:
— В JS ko.observable(val) — это оверхед, а вот в Ur <dyn signal="showRS rs"> — это не оверхед
— "Библиотеку, генерящую исходный HTML+JS и контролирующую все то же можно написать на любом языке программирования" — БРЕД! Нвозможно! Там будут тонны синтаксического оверхеда!
— Там скобки.
— Тонкий враппер написать невозможно потому что.
— Я не хочу видеть код с коллбэками только потому что я хочу видеть только код в стиле Объект.метод
Здравствуйте, anonymous, Вы писали:
A>Попрошу не поминать меня всуе.
Ну что поделать если паттерн поведения идентичный.
A>В Ur/Web нет ничего лишнего лишь потому, что это DSL под конкретную задачу. А JavaScript — язык общего назначения. Сравнивать их по синтаксическому оверхеду некорректно.
Ну то есть возражений о том что ур лучше для гуи чем жабаскрипт нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>Спасибо, кэп. По делу-то есть что сказать?
Я не понял, что ты услышать хочешь?
WH>>Например, все, что начинается с "ko.", скобки после вызова свойств. A>Это не мусор.
Без этого можно?
Да.
Значит мусор.
A>Очевидно, разница есть, поскольку клиенты для разных платформ устроены совершенно по разному, да и интерфейс у них различается в общем случае.
Если у нас есть ДСЛ, то сгенерировать из него мы можем что угодно. Уж поверь тому, кто на ДСЛ не одну свору собак съел.
Если у нам нужен разный ГУИ, то ничего не поделать. Нужно будет делать альтернативный ГУИ. Но при этом ничто не мешает для этого использовать ровно тот же ДСЛ.
Причем переделать скорей всего придется только View. Model и ViewMode скорей всего останутся те же.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Попрошу не поминать меня всуе. WH>Ну что поделать если паттерн поведения идентичный.
Помалкивать, я думаю.
A>>В Ur/Web нет ничего лишнего лишь потому, что это DSL под конкретную задачу. А JavaScript — язык общего назначения. Сравнивать их по синтаксическому оверхеду некорректно. WH>Ну то есть возражений о том что ур лучше для гуи чем жабаскрипт нет.
Есть, поскольку синтаксический оверхед далеко не единственный параметр и совсем не основной.
Здравствуйте, anonymous, Вы писали:
WH>>Ну то есть возражений о том что ур лучше для гуи чем жабаскрипт нет. A>Есть, поскольку синтаксический оверхед далеко не единственный параметр и совсем не основной.
По остальным параметрам ур тоже лучше.
Решение делается в точности в терминах предметной области (построение ГУИ).
Ур исключает несколько классов ошибок, которые жабаскрипт не ловит.
А какие еще ты знаешь параметры?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Интересует твое мнение насчет сильверлайт:
— пишем на клиенте и на сервере на одном и том же(C#, в перспективе nemerle),никакого или минимум жабаскрипта
— все строготипизировано, в том числе и "DOM"
— реактивность
Конечно не тотально кроссплатформенно, но на мой взгляд, для веб-приложений — самое то.
knockout.js и прочая.
, никто пока не догадался в .net поведение базовых типов из вне угробить 
А в чем именно проблема "работать с данными без плясок с бубном" из настоящего потока — worker-а, в котором я могу преспокойно выполнять AJAX-запросы синхронно безо всякой магии? 
