Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка.
WH>Вот тебе демка покруче: http://www.impredicative.com/ur/more/dragList.html
Здравствуйте, Mamut, Вы писали:
M>1. Это чушь (потму что высказанно обобщение, в общем случае это неверно)
Назови мне другой источник "надежности" ерланга.
Ну, хоть один.
M>2. И что с того?
То, что это не надежность, а показуха.
M>Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо.
Это по тому, что среди их клиентов нет людей понимающих плюсы статической типизации.
Просто по тому, что такие люди ерланг не используют.
Но ты можешь повторить эксперимент только сделай опрос среди хаскелистов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>Можно подробнее рассказать, что здесь крутого,
Да много что.
Защита от кучи уязвимостей.
Реактивность.
Клиентская многопоточность.
Прозрачное взаимодействие с сервером.
A>почему вспотеешь это делать,
Ну покажи мне клиентскую многопоточность на жабаскрипте.
A>и вообще, зачем код смешан с разметкой?
По тому, что автор ученый.
Сам язык не мешет писать правильно.
А если над синтаксисом
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) А. Эйнштейн
Здравствуйте, anonymous, Вы писали:
A>>>почему вспотеешь это делать, WH>>Ну покажи мне клиентскую многопоточность на жабаскрипте.
A>В браузере клиентский код всегда выполняется в один поток. Можно создать лишь эмуляцию многопоточности, например, через setTimeout(), как это делается в примере. Ничего необычного и сложного.
Уже не так. Настоящая многопоточность в браузере есть, с момента появления Web Worker API в HTML5. Рядом я привел пример. И он выглядит попроще, чем этот ужас на мегаязыке.
Здравствуйте, WolfHound, Вы писали:
G>>Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка. WH> Ты что в самом деле думал что я не замечу такой дешёвой подтасовки? WH>Ты вызываешь функцию по таймеру. WH>А в оригинальном коде создается два потока.
У меня создается два настоящих потока через HTML5 Web Worker API (Видишь вызов new Worker? Это оно). Внутри каждого из потоков я использую таймер.
Позорище.
G>>Твоя шняга и JSONP-то поди делать не умеет. WH>Он ей не нужен.
Ну естественно. Про same origin security policy и JSONP ты, разумеется, тоже не в курсе.
Здравствуйте, 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'ы и прочая. Только в них можно сломать голову.
G>>Заработало с первого раза, сразу, как отпечатал со скоростью машинистки. Что-то не заметил, чтобы я "вообще вспотел". При том, что это голый HTML5, без какого-либо фреймворка. WH> Ты что в самом деле думал что я не замечу такой дешёвой подтасовки? WH>Ты вызываешь функцию по таймеру.
Если бы ты прочитал код, то увидел бы, что создается два потока и к ним привязывается хэндлер событий. В потоках по таймауту генерируются события. ТО есть не потоки якобы работают на таймаутах, а внутри самих потоков исполюзуются таймауты, чтобы генерировать события для этого синтетического примера.
Здравствуйте, 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>Ты всерьез считаешь, что ur генерирует два настоящих потока в генерируемом им HTML и JS? Извини, но это — бред, с реальностью не имеющий ничего общего. Там точно так же генерируются setTimeout'ы и прочая. Только в них можно сломать голову.
Ты пойми мне абсолютно пофигу что там генерируется.
Мне важно, что есть в исходном коде.
Языки высокого уровня для того и нужны чтобы на ассемблере не писать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Гы, а Wolfhound — неосилятор, оказывается.
Здравствуйте, Mamut, Вы писали:
M>1. Это — безусловно, возможность отловить ошибки в пдающих процессах и сделать им graceful рестарт
Быстренько перезапуститься и сделать вид что так и надо.
M>2. Async message passing и отсутсвие разделяемых данных (и bottlenck'ов', с этим связанных)
Типа этим можно когото удивить.
И причем тут кстати типизация?
M>3. Стабильность и устойчивость VM (в частности — в scheduler'е, gc и работе с сетью) Ну да, конечно.
Здравствуйте, Gaperton, Вы писали:
G>Я же сказал, чем это отличается. Не более слабым контролем, а возможностью произвольно варьировать силу этого контроля для каждого отдельного случая.
При развитой статике такая возможность тоже имеется. Утиная типизация та же — пример такой фигни. Принципиальное отличие статики одно — необходимость каких то метаданных для конкретного вызова, чтобы сгенерить машинный код. Но эти метаданные совершенно не обязаны быть жестко структурированными классами.
G> Что упрощает язык и проектирование на нем, делая ненужными многие языковые навороты, например, generic-и.
Дженерики как раз таки обеспечивают очень жесткий контроль, это не движение в направлении его ослабления. И замена дженериков на динамику, это не вопрос инструментария, это вопрос важности статического контроля. Т.е. в итоге все сводится к тому же, с чего начали.
НС>>Мне больше нравится вариант шарпа, когда весь динамический шит нужно вводить явно, если уж без него никак.
G>Если говорить о soft type system, то ты не можешь знать, нравится он тебе или нет, если не попробовал.
А чем шарповые динамики под такое не прокатывают? Где надо, легким движением руки можно перейти к статике. Взгляни пошире — упираться надо не в конкретные решения, а в исходно стоящие проблемы. Тебе пример Ur уже приводили — разберись, для общеобразовательных целей совсем не бесполезно будет.
Вообще, как раз таки баланс и гибкость статического контроля сейчас — острие прогресса в разработке инструментария. Почти все интересные новинки тем или иным способом с этим связаны. И сворачивать его до примитивного статика-динамика — дилетантизм.
Да, чтобы пресечь бесполезный флейм с переходом на личности — пробовал.
G> А рассуждать о (пред)убеждениях мне не интересно.
Здравствуйте, Mamut, Вы писали:
M>Скажи это клиентам Эрикссона. Думаешь, Эрикссон не хотел ввести в язык статическую типизацию? Провели опрос клиентов, они хором сказали: не надо.
1) Миллионы леммингов не могут ошибаться?
2) Клиенты вообще — весьма посредственные эксперты, если мы говорим не о зарабатывании бабала, а о чисто технических моментах. А в этом топике пока было именно так.
3) Клиенты, пишущие программы для железок — еще более фиговые эксперты, бо текущее состояние телекомовского софта, работающего близко к железу — ниже плинтуса. Примеров тому масса. Например — все производителеи смартфонов в итоге перешли на созданные чистым софтвером операционки, а не угробные поделия железного сектора.
Это, впрочем, никак не означает что ерланг плох. Но его хорошесть вряд ли определяется его динамикой.
Здравствуйте, Gaperton, Вы писали:
G>Девять девяток надежности по итогам эксплуатации AXD301 — это не надежность
Ты с этим AXD уже лет пять носишься если не больше, вот только надежность пока что это больше вопрос приоритетов разработки, а не языка программирования. Время полностью верифицируемых языков пока не настало.
Ты, должно быть, шутишь. 
Мне бы в портфолио такую показуху.
