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) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Так как результатом будет все равно JS, возникает вопрос. Что мешает сделать то же самое средствами самого JS?
Клиника.
... << 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) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А самое главное ты настырно пытаешься уйти от изначальной темы, ибо понял, что ур с ГУИ справляется лучше, чем жабаскрипт со всеми своими библиотеками и твои утверждения о том, что тут динамика рулит, рассыпались в пыль.
Ur в принципе не может ничего сделать лучше, чем JavaScript, поскольку транслируется в него. Единственное и несущественное его достоинство — он предоставляет привычные средства для некоторых разработчиков.
Здравствуйте, anonymous, Вы писали:
A>Ur в принципе не может ничего сделать лучше, чем JavaScript, поскольку транслируется в него. Единственное и несущественное его достоинство — он предоставляет привычные средства для некоторых разработчиков.
Конечно же, может.
Просто по тому, что в случае с ур нужно писать меньше.
Причем не за счет мутных сокращений, а за счет того что решение получается в терминах изначальной задачи (динамический ГУИ).
A>А динамика тут вообще не при чём.
Ну, так она вообще не нужна.
Ибо каждый раз, когда начинаешь разбирать задачу, начиная от изначальной постановки решение на статике, оказывается не хуже.
И эта ветка прекрасно это демонстрирует.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>То есть, отвечая на вопрос «Назови мне другой источник "надежности" ерланга.» я обязан оставаться только в рамках системы типов? ты сам не считаешь это идиотизмом?
M>>То есть, отвечая на вопрос «Назови мне другой источник "надежности" ерланга.» я обязан оставаться только в рамках системы типов? ты сам не считаешь это идиотизмом?
НС>Я считаю демагогией попытки ухода от темы.
Итак. Был задан вопрос: «Назови мне другой источник "надежности" ерланга.» . Что, по-твоему, я должен был на него ответить?
M>>Ты на РСДНе сколько? Два дня?
НС>В профиль заглянуть сил не хватило?
M>> Тут система форумов расчитана на то, чтобы вести рассуждения на несколько тем сразу.
НС>Демагогия.
M>>Но вы решили этого не делать.
НС>Не надо тут на WH ссылаться, я к нему отношения не имею.
Но мозгов спокойно начать параллеьную ветку с обсуждением именно системы типов, тебе не хватило. Более того, тебе не хватило мозгов задать именно Wolfhound'у вопрос: какое отношение система типов имеет к приведенному им примеру, примерам. Ты решил влезть только тогда, когда вопрос про якобы настоящую многопоточность Ur'а заеш в тупик (благодаря, кстати, Wolfhound'у).
A>>Ur в принципе не может ничего сделать лучше, чем JavaScript, поскольку транслируется в него. Единственное и несущественное его достоинство — он предоставляет привычные средства для некоторых разработчиков. WH>Конечно же, может. WH>Просто по тому, что в случае с ур нужно писать меньше. WH>Причем не за счет мутных сокращений, а за счет того что решение получается в терминах изначальной задачи (динамический ГУИ).
Борец с синтаксическим оверхедом детектед
A>>А динамика тут вообще не при чём. WH>Ну, так она вообще не нужна. WH>Ибо каждый раз, когда начинаешь разбирать задачу, начиная от изначальной постановки решение на статике, оказывается не хуже. WH>И эта ветка прекрасно это демонстрирует.
А в чем именно проблема "работать с данными без плясок с бубном" из настоящего потока — worker-а, в котором я могу преспокойно выполнять AJAX-запросы синхронно безо всякой магии? 
