User avatar

Я думаю про обработку ошибок как объектов первого класса. Вообще надо избавляться от идеи "happy path". Кажется, надо эксплицировать управление длиной кода по Хэммингу — сейчас она имплицитно оптимизирована под тот самый happy path, в результате имеем — ... Вот что если бы например вместо исключений мы бы использовали анти-исключения, которые бы проталкивали успешный результат "вниз по стеку", мимо тектонических наслоений обработчиков ошибок?

Comment

Вторая тема — сейчас при композировании отдельных фрагментов кода, которые могут "вернуть ошибку" (то есть, всех фрагментов кода без исключения) код reduce Left-части монады Either, которая отвечает за ошибки, устроен понятным образом — взять первый элемент, остальное выбросить.

 ‎· псы в рапиде
Comment

Это я продолжаю думать о том, как бы я предотвращал бы эту историю про то, что обнуленный ключ переустанавливается при повторе. С одной стороны, кажется, что это от недостатка separation of concerns, и обнулять ключ должен некий ммм деструктор/finalizer. С другой стороны, как мы знаем, именно в ебучей крипте все без исключения вещи подобного рода должны быть эксплицированы, см. историю про оптимизируемый memset пароля нулём, ну и вот это.

 ‎· псы в рапиде
Comment

ну второе не всегда, типичный явский приём – заворачивать на каждом catch-е исключение в исключение, то есть такая рукотворная Writer-монада для лефтов (ну, пока не обрежут где-то)

 ‎· la France est en péril 1
Comment

Поможет ли нам добавить в FSM явный параметр "номер попытки"? Я продолжаю думать про этот "remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time." Ну то есть, как нам закодировать разницу между "installed for the first time" и "after first attempt to install"?

 ‎· псы в рапиде
Comment

Еще кажется где-то там есть разница между "нашим внутренним представлением" и "как про нас думают соседи"?

 ‎· псы в рапиде
Comment

@hotgiraffe: ну вот мне кажется, что у try/catch как раз есть эта семантика "ненормального code path", тогда как на самом деле ненормален happy path.

 ‎· псы в рапиде 1
Comment

В прекрасной статье "Paxos Made Live" https://research.google.com/archive/paxos_made_live.html ближе к концу рассказывается про то, как они дебаггили систему, и это становилось все сложнее и сложнее, потому что она рассматривала баги в реализации как outages и (как будто бы) успешно обходила их. Интересно как с тех пор продвинулась реализация Paxos.

 ‎· псы в рапиде 1
Comment

О, интересно, есть ли на эту тему исследования про Raft?

 ‎· псы в рапиде
Comment

^^^ ну да, по первому пункту try/catch как раз в полный рост, а писать код как FSM я как-то пока не вижу хороших вариантов

 ‎· la France est en péril
Comment

> After all, both have been formally proven as secure

 ‎· ^..^
Comment

^^^^^^ если я правильно понимаю, то суть атаки точно такая же, как и на брелки для автомобильных сигнализаций: десинк между источником (брелок|роутер) и приёмником (машина|клиент). Так что возможно вопрос даже не в коде, а в спецификации.

 ‎· ^..^
Comment

Да, конечно же, может очень помочь pattern matching, только надо как-то сделать чтобы второй путь нельзя было под ковер замести. То есть можно например думать как выглядел бы наш код если бы у нас не было null, а была бы только монада Maybe.

 ‎· псы в рапиде 2
Comment

http://ziglang.org/ seems relevant (http://ziglang.org/documentation/master/#errors in particular)

 ‎· jsn 3
Comment

@jsn: интересно, спасибо. Вообще конечно какой-то Парето-обусловленный язык, we could do better!

 ‎· псы в рапиде
Comment

@squadette: (я о нём ничего не знаю, встретил его впервые вчера на глагне hackernews, синхронно с твоим постом)

 ‎· jsn
Comment

^ вот кстати неясно, как этот defer не полебать и чем он лучше трейта Drop из раста с афинными типами?

 ‎· адский хардлайн в засаде
Comment

@larhat: деструкторы ваще не о том! У тебя половина ошибок не связаны с "ресурсами", а связаны например с переходами состояний в FSM.

 ‎· псы в рапиде
Comment

Ваще кстати я же пишу, что нет никакого "возврата вверх по стеку" — есть только бесконечное проталкивание значений вперед, в одно из возможных продолжений. Вообще в CSP кмк нет момента когда что-то "выходит из scope", оно это делает всегда перед передачей контроля (или же вообще — всегда в самом конце программы). Exceptions тоже отсутствуют, они просто одно из возможных продолжений.

 ‎· псы в рапиде
Comment

Из этого поста может получиться следующий рассказ Пелевина: бесконечное проталкивание значений вперед, мимо тектонических наслоений обработчиков ошибок и т.п.

 ‎· ^..^ 2

1 2 3 4 5 6 7 8 9 10