Я смотрю с чисто практической стороны.
Хорошо когда компилятор может проверить, что в акторе сть обработчик нужного типа сообщения и соответсвенно дать гарантию, что именно этот тип может обработаться актором. Соответсвенно при рефакторинге он может указать на ошибку этого типа.
Другой вопрос, что на практике я даже теоретически не вижу, где это мне поможет. По одной простой причине. На обработку сообщений всегда пишется тест. Не для проверки типа, а для того что бы быть уверенным — актор корректно обработает сообщение. На этом этапе сразу отсекаются ошибки типов сообщений. При чем AkkaTest позволяет как раз описать поведение акторов, т.е. например актор обязан получить сообщение обработать его.
Не просто может, а именно обязан получить.
Но если не писать тестов вообще, то конечно типы помогут в таких случаях.
Опять же, я не могу представить себе ситуацию, что программист берет, выпиливает часть акторов, меняет сообщения и даже не проверят то что он сделал. Таких надо ссаными тряпками гнать из професии.
Умолчу уже о том, что писать систему (на важно на чем) без тестов это жесть и само по себе существенно снижает ценность типизации вызовов. Т.к. типизация сообщений (применительно именно к Акка конечно же) сама по себе может проверить лишь малую часть кода.
И она не стоит того, чтобы городить огород.
P.S. Прошу обратить внимание, что речь не про сферического коня «статика vs динамика». А конкретно про типизацию акторов в Акка. Потому что во всех других частях Акка с типами все отлично.
Еще раз повторю вопрос.
Как вы, с помощью статической типизации, интерфейсов и прочего сможете гарантировать, что актор послал сообщение тем, кому должен?
Вот по пунктам распишие.
Если конкретизировать, то выражение «Гарнтия того что актор послал сообщение тому кому должен», означает, что вы в компайл тайме проверили, что какое-то сообщение актор отправил и какое-то сообщение актор получил. Для этого компилятору необходимо знание о том, что вообще должно происходить.
Другими словами, компилятор должен знать, что если мы создали метод, то кто-то где-то должен его обязательно его «дернуть». Как вы себе представляете это решение использую статическую типизацию?
Статическая типизация поможет только провериь, что мы передаем конкретный тип сообщения, и этот тип может обработаться актором. Но никак не может гарантировать что мы вообще посылаем такое сообщение и уж тем более не может гарантировать доставку сообщений.
У вас все смешалось в кучу.
Если говорить про акторы в целом, то т.к. под акторам подразумевается распределенная система, говорят что нет гарантий доставки. Но не потому что это акторы, а потому что система распределенная. Это обычная для новичков подмена понятий. На классическом ООП с Future то же нет гарантий доставки.
В общем случае вообще нет гарантии доставки сообщений в распределенной среде. Это в принципе не решаемая сейчас проблема. Ее только можно минимизировать разными способами. Гуглите «Задача двух генералов».
В рамках же одного приложения, гарантия доставки сообщения ровно такая же как и при вызове обычного метода.
Т.е. единственная проблема акторов в Акка, это не забыть сделать обработку сообщения в акторе.
Но эту ошибку точно так же легко допустить в любом коде и без акторов, забыв дернуть нужный метод.
P.S. Интерфейс с типами, в который обернут актор не гарантирует, что сообщение именно будет отправлено. А только то, что оно может быть отправлено именно с таким типом.
Программист легко может забыть его отправить при рефакторинге)
А как вы планируете типами гарантировать, что актор послал сообщения тем кому «должен» послать и от кого «должен» принять? Может все таки не «должен», а «может»? )
Суть акторов, что любой актор может послать любое сообщение любому актору и только актор сам решает, может он обработать это сообщение или нет. Это позволяет строить очень гибкие решения.
Иначе у вас получится обычный ООП с дерганьем методов и сильной связанностью. Поэтому вам и Future больше подходит для задач чем акторы.
Собственно никто и никогда не обещал, что акторы везде хорошо подходят.
Писал несколько проектов на Akka, вообще ни разу не сталкивался с неправильной инициализацией акторв и всеми теми проблемами что вы описали. Даже новички так не ошибались в коде.
Все эти проблемы выглядят теоретиконадуманными или притянутыми за уши. И на практике возможны только у совсем пофигистов новичков, которые копипастят код со SO не понимаю что и как они делают…
Потому что ровно все те же проблемы есть у всех языков и всех фреймворков:
1. Более менее еще в тему, хотя проблема правильно иницализации пристутствует во многих фреймворках.
2. Таких гарантий нет ни в одном приложении. Это все зависит только от разработчика. Он может забыть что угодно. В одном месте добавил метод, в другом забыл его «дернуть».
3. Таких гарантий тоже нет ни в одном приложении, см п 2.
И да, на такие вещи помогут только тесты, нет других вариантов пока.
Вы хрень какую-то сказали…
У всех моих родственников стоит убунта. Вмешиваюсь только когда выходит новый LTS релиз и надо обновить систему. Т.е. раз в 2 года. Все это время пользователи зами жмут кнопку «обновить», когда она появляется в системе. Сами находят себе игрушки в стиме и устанавливают.
Есть так же знакомые с виндой, так вот у них постоянные проблемы. То заразу зацепят где-то, и это при установленном антивируснике. То после установки лицензионной игры в системе что-то ломается. То нахватают всяких амиго браузеров и т.д. и т.п.
Пользуясь вашей терминологией, винда постоянно требует вмешательства в работу.
А линух нет. И это мой пример из примерно пары десятков человек во круг, которым я «помогаю с компутером».
> «Лицензионная винда с легальным софтом не требует вмешательства годами.»
Все верно, ровно до тех пор пока они находятся на дисках, лежащих в шкафу)
Как только установишь все это, начинаешь удивляться, куда винда все время съедает диск, и над прочими приколами винды…
P.S. На последок разорву вам шаблоны в клочья) Линукс и весь открытый софт под него, тоже «Легальный софт»! Представляете?
Грим уже не идеальное решение, даже с накладками.
Расстояние между глаз им не изменить, как и другие праметры.
Походку контролировать, да еще и меняя постоянно это оооочень тяжкое занятие. Про пару уроков просто смешно)
Вы забываете одну очень важную вешь, информация накапливается и обрабатывается. Пара небольших проколов с походкой, пара небольших проколов с гримом и привет.
Не так давно показывали алгоритм, который определяет человека по 4-5 точкам (координаты мобильника) на маршруте в городе.
«Система очень стабильна, никаких глобальных проблем я не получил.»
Ох… Это конечно субъективно, но у меня на 3-х разных по железу компах неон так и не захотел нормально работать.
На всех трех одни и теже проблемы. Пробовал несколько раз, в разное время, с разными версиями неона.
Например, ставим дистриб, обновляем систему, прилетает новое ядрышко и привет черный экран с глухим зависанием. Лечится только удалением nvidia драйверов. Т.е. c ppa:graphics-drivers оно каким-то магическим образом не совместимо что ли…
Очень много артефактов на экране: кнопки меню и т.д. покрываются квадратами, остаются неочищеные области экрана после закрытия формы и т.д.
При этом в убунте и кубунте (и винде) все Ок работает, никаких проблем.
В общем дистриб оставил ощущения очень сырой поделки…
В еве никогда небыло официального вывода денег.
Незнаю примера, чтобы в ММО был официальный вывод денг…
А по поводу «возможен», он в любой игре возможен. Даже в танках, в которых как таковой экономики нет, выводят деньги))
Другими словами:
1. Вы получили документ, распечатали, подписали и отослали не глядя.
2. «Округление не туда пошло» отличное описание бабушки бухгалтера, которая комп 2-й раз в жизни видит. Опять же, отправили не глядя на результат?
3. «каким-то макаром размер страницы стал Letter», но никто конечно же не проверял печать на таком важном бланке? (везде где видел такие важные бланки, девочки даже на МСО сначала проверяют на чистой бумаге печатая. Потому что всякое случается и с МСО и с техникой)
А виноват в этом всем конечно же офисный пкает?
Ну да, ну да…
Так простая же логика у тех, кто привык получать деньги ни за что.
Если есть прецедент получения денег за копеечный ущерб и суд разрешил ущерб не учитывать, то можно нагибать вообще всех, кто хоть как-то попался. В том числе и рядовые граждане.
Другими словами, можно брать статистику торрентов и названий файлов у провайдера, говорить что вот этот пользователь скачал за последний год дохрена фильмов, а значит он злостный нарушитель.
А раз он злостный нарушитель, то пусть выплачивает дофига денег. Обвинительный привор почти гарнатирован. А по нашим законам, выигравшая сторона может повесить расходы юристов на проигравшую. Т.е. еще и судиться будет не выгодно, потому что выиграть будет практически невозможно.
В общем копирасты добились чего хотели, осталось только отработать техническую часть, чтобы пройтись по головам людей и настричь еще денег. И делать это в дальнейшем.
Зачем огромный дом для получения отдельной комнаты? Чем просто наличие отдельной комнаты в обычной квартире не решение?
Я в свое время решил этот вопрос очень просто. Снял однушку рядом с квартирой) Получилось очень не дорого, и в шаговой доступности.
А вы держите на каждой карте приличную сумму или каждый раз перед оплатой мечетесь перекидывая деньги с карты на карту? Как с коммисиями за перевод? Что делаете если деньги не переводятся на нужную карту быстро?
P.S. Ну и просто и нтересно, почему рокетом можно оплачивать только смузи?
Это первое, что я сделал.
И вы не поверите, в выписке вообще не было этих операций. Ни списания, ни возврата.
А сотрудник банка на это ответил, что они удаляют такие операции. Типа плюс на минус дает ноль))
При чем я общался не с рядовой техподдержкой, меня переключили на какого-то менеджера.
И вот собственно это утверждение, о том что банк удаляет транзакции из выписки, и было последней каплей. Стало понятно, что это за шарашкина контора…
Если очень коротко, то
1. Карта. Списали деньги за операцию которая была год назад. https://habrahabr.ru/company/chronopay/blog/280480/#comment_10067346
2. Счет на организацию. В летом 2016г была смена бик у банка. В то же время было выставлено требование от налоговой. Требование выписано на одни реквизиты, оплата прошла после смены бика. В налоговой сказали, что банк не прислал (ил не корреткно прислал) какой-то там электронный квиток в их системе обмена.
Поэтому система автоматически не закрыла требование по новым реквизитам. В результате в системе налоговой счет висит как «есть проблемы с налоговой», хотя по факту их нет. На данный момент нельзя ни новый счет открыть, нифга сделать, пока налоговая с банком это не разрулит. Т.к. другие банки проверяют этот статус и не могут открыть счет, пока все проблемы не урегулированы.
В общем отличный вышел «год пробы с банком тинькова» ))
Поздно конечно отвечаю. Но у меня не так давно была ситуация с Тинькоф банком.
В августе 2016 пришла СМС вида «в августе 2015 вы сняли деньги в банкомате».
Т.е. прошло больше года (если считать по дням), и у меня Тинькоф списал деньги со счета. При чем у этого банка такой идиотский кабинет, в котором операции снятия отображаются в истории, а операции возврата нет. И банк меня убеждал, что они типа возвращали мне деньги на карту, просто я не помню. Память короткая у меня, всего год прошел)) И типа для разборок с ними надо хранить всю историю СМС приходящих от банка.
Хорошо когда компилятор может проверить, что в акторе сть обработчик нужного типа сообщения и соответсвенно дать гарантию, что именно этот тип может обработаться актором. Соответсвенно при рефакторинге он может указать на ошибку этого типа.
Другой вопрос, что на практике я даже теоретически не вижу, где это мне поможет. По одной простой причине. На обработку сообщений всегда пишется тест. Не для проверки типа, а для того что бы быть уверенным — актор корректно обработает сообщение. На этом этапе сразу отсекаются ошибки типов сообщений. При чем AkkaTest позволяет как раз описать поведение акторов, т.е. например актор обязан получить сообщение обработать его.
Не просто может, а именно обязан получить.
Но если не писать тестов вообще, то конечно типы помогут в таких случаях.
Опять же, я не могу представить себе ситуацию, что программист берет, выпиливает часть акторов, меняет сообщения и даже не проверят то что он сделал. Таких надо ссаными тряпками гнать из професии.
Умолчу уже о том, что писать систему (на важно на чем) без тестов это жесть и само по себе существенно снижает ценность типизации вызовов. Т.к. типизация сообщений (применительно именно к Акка конечно же) сама по себе может проверить лишь малую часть кода.
И она не стоит того, чтобы городить огород.
P.S. Прошу обратить внимание, что речь не про сферического коня «статика vs динамика». А конкретно про типизацию акторов в Акка. Потому что во всех других частях Акка с типами все отлично.
Как вы, с помощью статической типизации, интерфейсов и прочего сможете гарантировать, что актор послал сообщение тем, кому должен?
Вот по пунктам распишие.
Если конкретизировать, то выражение «Гарнтия того что актор послал сообщение тому кому должен», означает, что вы в компайл тайме проверили, что какое-то сообщение актор отправил и какое-то сообщение актор получил. Для этого компилятору необходимо знание о том, что вообще должно происходить.
Другими словами, компилятор должен знать, что если мы создали метод, то кто-то где-то должен его обязательно его «дернуть». Как вы себе представляете это решение использую статическую типизацию?
Статическая типизация поможет только провериь, что мы передаем конкретный тип сообщения, и этот тип может обработаться актором. Но никак не может гарантировать что мы вообще посылаем такое сообщение и уж тем более не может гарантировать доставку сообщений.
У вас все смешалось в кучу.
Если говорить про акторы в целом, то т.к. под акторам подразумевается распределенная система, говорят что нет гарантий доставки. Но не потому что это акторы, а потому что система распределенная. Это обычная для новичков подмена понятий. На классическом ООП с Future то же нет гарантий доставки.
В общем случае вообще нет гарантии доставки сообщений в распределенной среде. Это в принципе не решаемая сейчас проблема. Ее только можно минимизировать разными способами. Гуглите «Задача двух генералов».
В рамках же одного приложения, гарантия доставки сообщения ровно такая же как и при вызове обычного метода.
Т.е. единственная проблема акторов в Акка, это не забыть сделать обработку сообщения в акторе.
Но эту ошибку точно так же легко допустить в любом коде и без акторов, забыв дернуть нужный метод.
P.S. Интерфейс с типами, в который обернут актор не гарантирует, что сообщение именно будет отправлено. А только то, что оно может быть отправлено именно с таким типом.
Программист легко может забыть его отправить при рефакторинге)
Суть акторов, что любой актор может послать любое сообщение любому актору и только актор сам решает, может он обработать это сообщение или нет. Это позволяет строить очень гибкие решения.
Иначе у вас получится обычный ООП с дерганьем методов и сильной связанностью. Поэтому вам и Future больше подходит для задач чем акторы.
Собственно никто и никогда не обещал, что акторы везде хорошо подходят.
Писал несколько проектов на Akka, вообще ни разу не сталкивался с неправильной инициализацией акторв и всеми теми проблемами что вы описали. Даже новички так не ошибались в коде.
Все эти проблемы выглядят теоретиконадуманными или притянутыми за уши. И на практике возможны только у совсем пофигистов новичков, которые копипастят код со SO не понимаю что и как они делают…
Потому что ровно все те же проблемы есть у всех языков и всех фреймворков:
1. Более менее еще в тему, хотя проблема правильно иницализации пристутствует во многих фреймворках.
2. Таких гарантий нет ни в одном приложении. Это все зависит только от разработчика. Он может забыть что угодно. В одном месте добавил метод, в другом забыл его «дернуть».
3. Таких гарантий тоже нет ни в одном приложении, см п 2.
И да, на такие вещи помогут только тесты, нет других вариантов пока.
У всех моих родственников стоит убунта. Вмешиваюсь только когда выходит новый LTS релиз и надо обновить систему. Т.е. раз в 2 года. Все это время пользователи зами жмут кнопку «обновить», когда она появляется в системе. Сами находят себе игрушки в стиме и устанавливают.
Есть так же знакомые с виндой, так вот у них постоянные проблемы. То заразу зацепят где-то, и это при установленном антивируснике. То после установки лицензионной игры в системе что-то ломается. То нахватают всяких амиго браузеров и т.д. и т.п.
Пользуясь вашей терминологией, винда постоянно требует вмешательства в работу.
А линух нет. И это мой пример из примерно пары десятков человек во круг, которым я «помогаю с компутером».
Все верно, ровно до тех пор пока они находятся на дисках, лежащих в шкафу)
Как только установишь все это, начинаешь удивляться, куда винда все время съедает диск, и над прочими приколами винды…
P.S. На последок разорву вам шаблоны в клочья) Линукс и весь открытый софт под него, тоже «Легальный софт»! Представляете?
Просто пальцем заткнули дырку…
Расстояние между глаз им не изменить, как и другие праметры.
Походку контролировать, да еще и меняя постоянно это оооочень тяжкое занятие. Про пару уроков просто смешно)
Вы забываете одну очень важную вешь, информация накапливается и обрабатывается. Пара небольших проколов с походкой, пара небольших проколов с гримом и привет.
Не так давно показывали алгоритм, который определяет человека по 4-5 точкам (координаты мобильника) на маршруте в городе.
Это независимые вещи. А глобальное меню экономит место по высоте.
Ох… Это конечно субъективно, но у меня на 3-х разных по железу компах неон так и не захотел нормально работать.
На всех трех одни и теже проблемы. Пробовал несколько раз, в разное время, с разными версиями неона.
Например, ставим дистриб, обновляем систему, прилетает новое ядрышко и привет черный экран с глухим зависанием. Лечится только удалением nvidia драйверов. Т.е. c ppa:graphics-drivers оно каким-то магическим образом не совместимо что ли…
Очень много артефактов на экране: кнопки меню и т.д. покрываются квадратами, остаются неочищеные области экрана после закрытия формы и т.д.
При этом в убунте и кубунте (и винде) все Ок работает, никаких проблем.
В общем дистриб оставил ощущения очень сырой поделки…
Незнаю примера, чтобы в ММО был официальный вывод денг…
А по поводу «возможен», он в любой игре возможен. Даже в танках, в которых как таковой экономики нет, выводят деньги))
1. Вы получили документ, распечатали, подписали и отослали не глядя.
2. «Округление не туда пошло» отличное описание бабушки бухгалтера, которая комп 2-й раз в жизни видит. Опять же, отправили не глядя на результат?
3. «каким-то макаром размер страницы стал Letter», но никто конечно же не проверял печать на таком важном бланке? (везде где видел такие важные бланки, девочки даже на МСО сначала проверяют на чистой бумаге печатая. Потому что всякое случается и с МСО и с техникой)
А виноват в этом всем конечно же офисный пкает?
Ну да, ну да…
Если есть прецедент получения денег за копеечный ущерб и суд разрешил ущерб не учитывать, то можно нагибать вообще всех, кто хоть как-то попался. В том числе и рядовые граждане.
Другими словами, можно брать статистику торрентов и названий файлов у провайдера, говорить что вот этот пользователь скачал за последний год дохрена фильмов, а значит он злостный нарушитель.
А раз он злостный нарушитель, то пусть выплачивает дофига денег. Обвинительный привор почти гарнатирован. А по нашим законам, выигравшая сторона может повесить расходы юристов на проигравшую. Т.е. еще и судиться будет не выгодно, потому что выиграть будет практически невозможно.
В общем копирасты добились чего хотели, осталось только отработать техническую часть, чтобы пройтись по головам людей и настричь еще денег. И делать это в дальнейшем.
Я в свое время решил этот вопрос очень просто. Снял однушку рядом с квартирой) Получилось очень не дорого, и в шаговой доступности.
P.S. Ну и просто и нтересно, почему рокетом можно оплачивать только смузи?
И вы не поверите, в выписке вообще не было этих операций. Ни списания, ни возврата.
А сотрудник банка на это ответил, что они удаляют такие операции. Типа плюс на минус дает ноль))
При чем я общался не с рядовой техподдержкой, меня переключили на какого-то менеджера.
И вот собственно это утверждение, о том что банк удаляет транзакции из выписки, и было последней каплей. Стало понятно, что это за шарашкина контора…
1. Карта. Списали деньги за операцию которая была год назад. https://habrahabr.ru/company/chronopay/blog/280480/#comment_10067346
2. Счет на организацию. В летом 2016г была смена бик у банка. В то же время было выставлено требование от налоговой. Требование выписано на одни реквизиты, оплата прошла после смены бика. В налоговой сказали, что банк не прислал (ил не корреткно прислал) какой-то там электронный квиток в их системе обмена.
Поэтому система автоматически не закрыла требование по новым реквизитам. В результате в системе налоговой счет висит как «есть проблемы с налоговой», хотя по факту их нет. На данный момент нельзя ни новый счет открыть, нифга сделать, пока налоговая с банком это не разрулит. Т.к. другие банки проверяют этот статус и не могут открыть счет, пока все проблемы не урегулированы.
В общем отличный вышел «год пробы с банком тинькова» ))
У банка все ровно, деньги к деньгам…
А я вот накушлася с ними (и карта и счет организации там были). Спасибо. Больше не хочу.
В августе 2016 пришла СМС вида «в августе 2015 вы сняли деньги в банкомате».
Т.е. прошло больше года (если считать по дням), и у меня Тинькоф списал деньги со счета. При чем у этого банка такой идиотский кабинет, в котором операции снятия отображаются в истории, а операции возврата нет. И банк меня убеждал, что они типа возвращали мне деньги на карту, просто я не помню. Память короткая у меня, всего год прошел)) И типа для разборок с ними надо хранить всю историю СМС приходящих от банка.