haskell jun2: упрощение

[antonkalinin-ml]

Спустя какое-то время после сдачи jun2 понимаешь, что многие темы оттуда или не пригодились, или пригодились в связи с другими темами на более высоких грейдах. Предлагаю их вырезать, переместить на грейды повыше или сделать опциональными.

Почти весь раздел по линуксу не пригодился. Хотя мне сложно оценить, я многие вещи оттуда знал, так что может и нужно оставить часть. Но вот в частности бесполезны:

• 15 способов поиска процесса. К тому же, легко гуглится и ищется в мане.
• curl (ищется в мане). Я на проекте использовал только постман, намного удобнее.
• inter-process communication. Но это хорошая теоретическая тема для общего развития, можно сделать опциональной.
• process supervising узкоспециализированная штука, не пригодилось. Все команды systemd вылетели из головы, кроме restart. Все это ищется в доках и статьях, ничего фундаментального тут нет, чтобы учить непременно на jun2.

Юзеры, группы, rwx, .profile, env vars, man - можно оставить, это базовые знания для работы в линуксе. Чтобы например настроить стек, добавить в PATH путь поиска бинарей. Однако половину этих вопросов добавлял я, так что конфликт интересов.

Про Haskell:

• Data.Either.Validation не понадобилось, хотя, кажется, один раз про него зашел разговор. Можно оставить в для ознакомления, можно убрать.
• законы Foldable & Traversable. Законы хороши, если пытаешься понять, каков их смысл. Я их скорее зазубривал, особенно это касается Traversable. Я бы или убрал, или добавил вопросы, почему законы именно такие и что они значат. Если же вам придет в голову написать необычный инстанс и не нарушить законы, вы знаете, где их найти.
• весь Traversable я бы перенес на мидла. Я проникся траверсаблом, почитав пейпер, но он сложноват для jun2, а без пейпера это, опять-таки, зубрежка какого-то мутного тайпкласса, который будешь применять максимум в рамках вызова mapM над списком/Maybe, но точно не реализацией нестандартного инстанса. На мидле начнутся линзы, и вот там Traversable точно пригодится. С траверсаблом можно унести DeriveTraversable.
• DerivingVia лучше учить вместе с Coercible и type roles, тема небольшая. Сделаем ее на мидле?
• многопоточку нам тимлид запрещает использовать :). Унести на мидла? forkIO и MVar это не вполне современный и безопасный подход для работы с многопоточкой, сюда надо и асинх. эксепшены, TVar, каналы, async package.

+ @olegromashin @olgaklimenko @kelizarov @stanislav-az @evgeny-osipenko @KateBushueva

[olegromashin]

Про Haskell: не соглашусь по поводу переносов на мидла. Traversable, DerivingVia и concurrency широко используются на проектах. Лучше получить хоть какое-то представление о них, пусть даже неполное, чтобы быть более подготовленным к работе и понимать, что и как загуглить в случае необходимости.
Про законы полностью согласен. Тоже зубрил. Предлагаю убрать и добавить простой вопрос: "Есть ли у Foldable и Traversable законы для инстансов?" Просто для того, чтобы обратить внимание на них.

Про Linux сложнее. Мне пригодилось знание по поиску процессов и я периодически пользовался curl. Изучение супервизоров тоже применилось. С IPC вообще не сталкивался в работе.

[antonkalinin-ml]

@olegromashin А в каком виде используете concurrency, прямо forkIO + MVar? Этого мало, да и небезопасно, надо знать про маски и эксепшены. У MVar есть свои приколы.

[olegromashin]

А в каком виде используете concurrency, прямо forkIO + MVar?

Да.

Этого мало...

Этого достаточно, чтобы хотя бы получить представление о том, что происходит и понимать код. От джуна это и требуется, таски на проектирование модуля с многопоточностью всё равно первому-второму джуну не достанутся.

[evgeny-osipenko]

Validation я вроде давно уже предлагал перенести на первого джуна. Там как раз же есть вопрос типа "чем различаются аппликатив и монада", и там эта штука как раз бы отлично подошла в качестве примера того, как у аппликатива может не быть инстанса монады.

Traversable, я считаю, должен идти вместе с Foldable - ибо описывают, в конечном счёте, одну абстракцию - "пройтись по всем элементам списка".

[stanislav-az]

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

Законы для Traversable можно и удалить, в принципе, для Foldable я бы оставил, там связь с моноидом понимается через законы отчасти.

[stanislav-az]

Coercible и type roles, тема небольшая. Сделаем ее на мидле

Это хорошее предложение

[antonkalinin-ml]

@stanislav-az а что думаешь про удаление узкоспециализированных вопросов про линукс (поиск процесса по тому-сему, systemd, супервайзинг, IPC)?

[stanislav-az]

Поиск процесса реально полезная штука, не раз использовал. Часто процессы пытаются использовать один порт и что-то падает с непонятной (если не знать эту тему) ошибкой. systemd, супервайзинг тоже в принципе полезны, не редко использовал. IPC широкая тема, согласен с тем что можно вынести в отдельную опциональную тему и расширить, но в текущей версии же не требуется слишком глубоких знаний?

[antonkalinin-ml]

Поиск процесса реально полезная штука, не раз использовал.

Я тоже, но всегда в одном варианте ps aux | grep строка, а мы учим много других опций у ps.

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

Глубоких не требуется, но это же не обоснование оставлять в обязательном списке. Оставлять нужно, если это знание приносит пользу. Мне не принесло (в работе, а не в качестве развлечения), но может кому-то из вас принесло.

Про systemd и супервайзинг, значит, нужно, ок.

[stanislav-az]

Глубоких не требуется, но это же не обоснование оставлять в обязательном списке.

Я считаю, что необходимы поверхностные знания IPC всё-таки. Они требуется когда сложный бекенд (для взаимодействия сервисов бека), или для взаимодействия фронта с беком (хотя такого я не встречал, но в принципе может и быть). Пример: у нас на блокчейн проектах взаимодейсвуют некоторые сервисы на беке (Plutus application backend) через сокеты.