я читал статью, в которой всерьез втиралось, что питон более строго типизирован, чем джава

больше вообще или на 100 строчек кода?

я не помню уже, конечно

они вроде семантику как-то по-хардкору препарировали

а не тупо скобочки считали

я читал статью, в которой всерьез втиралось, что питон более строго типизирован, чем джава

А я вот даже не удивился.

Наверное, так и есть.

я читал статью, в которой всерьез втиралось, что питон более строго типизирован, чем джава

ты сейчас не путаешь строгую со статической, точно?

ты сейчас не путаешь строгую со статической, точно?

насколько помню - нет

http://degoes.net/articles/easy-monads

Замануха какая-то небось, этот лысый только и ждёт, чтоб сделать с моим мозгом то, что его коллега из бразерс делает с женщинами

дехус шкварыць

https://neoeinstein.github.io/monads-are-not-burritos/images/what-is-monad.jpg

https://camo.githubusercontent.com/2a4d9287a3990bfcee878f32e588b4a69aed61d2/68747470733a2f2f636c6475702e636f6d2f53357443313841625f782d3230303078323030302e6a706567

чтобы понять монады - надо понять монады

тут люди списки складывают, а им в лицо монадами швыряются :(

нутакчО!? var - evil ??

можно но чтобы никто не видел

нутакчО!? var - evil ??

Если в монаде - нет

observable nondeterminism по научному

можно но чтобы никто не видел

Чтобы было сюрпризом для тех, кто потом будет поддерживать?

ок.....еще бы монаду понять.....надо монаду понять ?

я про инкапсуляцию мутабельности :)

нутакчО!? var - evil ??

у каждого свой монастырь и свой устав)

https://www.fpcasts.com/

у каждого свой монастырь и свой устав)

ну....я вот по учебнику старенькому изучаюсь, видимо сой устав будет как там + курсера

https://www.fpcasts.com/

Чего-нибудь посоветуешь, или только нашел?

Чего-нибудь посоветуешь, или только нашел?

Наткнулся в твиттере

The Type Theory Podcast

звучит прикольно

Ты через 5 месяцев попробуй свой изящный код почитать :)

обычно небольшие функции с рекурсией пишутся, с ними проблем не бывает

обычно небольшие функции с рекурсией пишутся, с ними проблем не бывает

У человека опыт - написал функцию рекурсивную, через 5 месяцев не може прочитать. Всякое бывает

на reddit-е кинули https://github.com/Tenchi2xh/Scurses хорошо выглядит

на reddit-е кинули https://github.com/Tenchi2xh/Scurses хорошо выглядит

красотень

на reddit-е кинули https://github.com/Tenchi2xh/Scurses хорошо выглядит

Кайф.

юбиленый scalalaz - http://scalalaz.ru/series-10.html

почему недостаточно? берем и решаем что отправлять будем используя JSON подобной структуры: { "type":"example", "data": { .... } } Дальше просто проверяем что находится в type и на основе этого уже проводим десериализацию.... Или можо проще и без этой обертки?

Не забывай про одинаковые запросы с разными параметрами. Например, как я выше писал, запросили двух юзеров с разными айди. Клиент асинхронный, такие ситуации нужно обрабатывать.

Не забывай про одинаковые запросы с разными параметрами. Например, как я выше писал, запросили двух юзеров с разными айди. Клиент асинхронный, такие ситуации нужно обрабатывать.

конечно нужно, но на каждого клиента свой актор, я просто знаю откуда и что пришло, зачем мне еще дополнительно пометку делать?

конечно нужно, но на каждого клиента свой актор, я просто знаю откуда и что пришло, зачем мне еще дополнительно пометку делать?

Канал то один. И я про клиент

Твой клиент А сделал 2 запроса getUser. Как понять, какой из ответов вернул какого юзера?

понять на клиенте А

конечно нужно, но на каждого клиента свой актор, я просто знаю откуда и что пришло, зачем мне еще дополнительно пометку делать?

Он верно тебе говорит) При хттп запросах - у тебя каждый запрос изолируется в отдельный канал и нет проблем. А здесь иначе, причем даже в случае если обеспечиваешь синхронность очереди ( запрос Б не отправится на сервер до тех пор пока не будет получен ответ А ) - не исключена ситуация, что ответ на А придет после истечения таймаута и ты можешь подумать, что пришел ответ на Б

юбиленый scalalaz - http://scalalaz.ru/series-10.html

Закрепите?

Твой клиент А сделал 2 запроса getUser. Как понять, какой из ответов вернул какого юзера?

То есть такое бывает что у вас на клиенте в двух разных местах посылается запросы на один урл с разными параметрами и нужно получить в двух разных местах ответы на свои запросы?

причем тут один урл?

> Юрий Твой клиент А сделал 2 запроса getUser.

Ну как бы стоило сначало прочитать в чем суть беседки была) Запросы отправляются в контексте websocket

я как бы читал еще со вчера > @rudogma При хттп запросах - у тебя каждый запрос изолируется в тут сравнивали с http - и пишите это в достоинства - это конечно достоинство но как это использовать можно

то есть http - обеспечивает идентификацию запроса а ws идентификацию вида сообщения(что бы обеспечить идентификацию запроса предлагали использовать requestId) - так я и спрашиваю реально нужна идентификация запроса где то?

ws не обеспечивает идентификацию сообщения

оно позволяет тебе пихать туда сюда сообщения в рамках одного постоянного соединения

в сокетах нет понятия запрос-ответ. есть просто сообщение в ту или иную сторону

никто не спорит

и до сих пор непонятно почему требуется id для сообщений?

То есть такое бывает что у вас на клиенте в двух разных местах посылается запросы на один урл с разными параметрами и нужно получить в двух разных местах ответы на свои запросы?

Конечно бывает. Без этого придется делать передачу сообщений по вебсокету синхронными.

Конечно бывает. Без этого придется делать передачу сообщений по вебсокету синхронными.

Синхронность очереди по сокету не отменяет исходной проблемы

ну да, это правда

> Юрий Конечно бывает. а можно пример для глупых? хотя бы наивный

дашборд - кидаешь на него два юзера. по каждому одновременно запрашивается инфа

на одном клиенте два юзера?

еще раз - представь себе гуи дашборд(сводка, как хочешь назови) - кидаешь на него два виджета и говоришь им, что один должен показать инфу про пользователя id=1, второй по пользователю id=2. Естественно, что каждый из них инициирует свой запрос

ERROR: S client not available

замени "пользователь" на "проект" - если тебя смущает и возникает когнитивный диссонанс

ок такой пример понятен

приходящие сообщения о разных юзерах будут содержать в себе напрмер userId и можно будет узнать в какой виджет сообщение сунуть ну ладно я попросил пример для глупых

Хорошо, закроем глаза еще на пачку проблем которые ты поимеешь при таком подходе. Но ответь на следующее - если ты получил сообщение с ошибкой и там естественно не будет id юзвера, как ты теперь будешь разбираться к какому виджету оно относится?

если в сообщении нет инфы по какой причине оно произошло - то это хреновое сообщение) - посылай в сообщении userId В общем да получится что userId будет requestId для этого конкретного случая Просто вот это решение с requestId слишком начинает превращать общение в запрос/ответ а ws мне кажется не про это - разве нет?

приведенную задачу не нужно решать чисто вебсокетами

если в сообщении нет инфы по какой причине оно произошло - то это хреновое сообщение) - посылай в сообщении userId В общем да получится что userId будет requestId для этого конкретного случая Просто вот это решение с requestId слишком начинает превращать общение в запрос/ответ а ws мне кажется не про это - разве нет?

Мы использовали вс как единственный транспорт и для запрос/ответ общения и для пушинга с сервера. Но да, приходится вот так поприседать, чтобы сделать нормальный запрос/ответ.

можно в принципе использовать два транспорта - http и web-socket

это просто другое решение

а почему отказались от http?

да как-то хз, не помню уже. Просто нужен был пушинг с сервера, значит надо юзать вебсокеты. Ну и завернули всё в одном слое. Может @fomkin меня поправит.

> Просто вот это решение с requestId слишком начинает превращать общение в запрос/ответ а ws мне кажется не про это - разве нет? да не, тут же двухсторонняя коммуникация, sse не про это, а ws вполне

да как-то хз, не помню уже. Просто нужен был пушинг с сервера, значит надо юзать вебсокеты. Ну и завернули всё в одном слое. Может @fomkin меня поправит.

1) Мобильное приложение. Интернет плохой, делать SSL-хэндшейки каждый раз когда хочется чего-нибудь дернуть -- не очень круто. 2) Если мы уже сапортим вебсокет-хозяйство, то почему бы не сделать поверх него запрос ответ 2.1) Не надо матчить HTTP-сессию с вебсокетом.

можно в принципе использовать два транспорта - http и web-socket

а можно не ограничивать себя и использовать один транспорт для req/resp & signal

Ну вот кстати про пример с дашбордом. Оно вроде и так... Но всегда стараюсь строить приложение так, чтобы не надо было приседать. Решается просто, каждый виджет знает юзера с каким ID он показывает. Тебе "из трубы" прилетают 2 юзера, у них ID есть и приложение знает на каком виджете какого отобразить. Привязка к запросам уже не нужные приседания.

Просили простой случай - дал простой случай. Пожалуй перечислять все возможные случаи на которые натолкнешься, если для реализации семантики "запрос-ответ" не будешь использовать req-id - мне лень и нет никакого желания)

Так id юзера это и есть reqid в этом просто случае

Не считаю идентификатор запроса "приседаниями"

Разве нет?

Нет, так не должно быть

Мдя

Aleksey ну что, будешь вписываться за скалу?)

Не считаю идентификатор запроса "приседаниями"

Не сам идентификатор, а бизнеслогика заявязанная на него

Aleksey ну что, будешь вписываться за скалу?)

Я написал Баруху, он не против, но сказал, что им надо обсудить мое участие.

Жду в общем.

Я написал Баруху, он не против, но сказал, что им надо обсудить мое участие.

Ок)

А что за чел то против будет

а про что вообще речь?

Или они все будут против?