Repository navigation
Упрощение карты на 3го джуна #287
Description
Есть запрос на то, чтобы пересмотреть вопросы по хаскелю на 3го джуна, т.к. уровень достаточно большой. Если решим, что это действительно нужно, можно сделать это такими способами:
- Перенести часть вопросов на 2го джуна и миддла. Тут есть несколько подвариантов:
- переносить целыми блоками, например взять целый блок экстеншенов по дерайвингу и унести на 2го джуна.
- оставить только простые вопросы по каждому из блоков, а более сложные и углубленные перенести на миддла.
- Добавить еще один, 4й уровень джуна.
Предлагаю обсудить, кто за и против упрощения 3го джуна и почему. И сразу подумать о вариантах выше или предложить еще способы :)
Activity
Znack commentedon Feb 24, 2021
Я точно как минимум за то, чтобы разбить самые сложные блоки из экстеншенов на две части: попроще и уже посложнее. Те что посложнее вынести на мидла, например. Ну и да, некоторые экстеншены либо полностью, либо частично, можно на второго джуна перенести.
Про 4-ый уровень я не уверен, так как сейчас 2-ой уровень достаточно маленький, он у нас обкусанный какой-то получился, и тут еще 4-ый уровень к этому добавлять пока что кажется рановато :)
vkpgwt commentedon Feb 25, 2021
Похоже, что основная тема на jun3 - это type-level programming, adnvanced types & type classes. Они близко связаны, поэтому вряд ли их стоит выносить. Все остальные темы почти не связаны:
Но не стоит оставлять в jun3 только сложное и концентрированное, а в jun2 объемное и несложное. Сложное лучше чередовать с несложным, чтобы дать сдающему передышку :). Поэтому я бы оставил laziness и/или эксепшены, положив их где-то между type families и DataKinds.
Если что-то выносить на мидл - разве что самые сложные темы: GADTs, TypeFamilies? DataKinds вроде не такие сложные, хотя без TypeFamilies они не очень полезны. ConstraintKinds узкоспециализированная штука, тоже можно вынести. Но я не вникал в программу мидла - возможно, там и без того хватает сложностей, чтобы еще добавлять.
Znack commentedon Feb 26, 2021
Про deriving согласен :)
Тайпклассы возможно тоже на мидла вынести, про перекрытие и поиск инстанса вопрсоы уже больше про то, как это устроено внутри и почему так устроено, а не как этим пользоваться, а значит это ближе к мидлу уже :)
Про то, чтобы разбавлять и чередовать согласен кстати, но этого непросто будет добиться, мне кажется, тут скорее всего вам самим надо к согласию прийти :)
vkpgwt commentedon Feb 28, 2021
В чеклисте по гиту тоже есть не очень практичные вопросы, которые больше про понимание принципов, или вопросы о редкоиспользуемых командах. Можно их передвинуть на мидла:
merge --squash, если только это не ежедневная операция. Сквошем легко злоупотребить и получить коммит на 20000 строк. С такими коммитами бисект бесполезен, и от истории коммитов толку мало.Что такое Git workflow, какие знаете примеры?- вопрос слишком обширный и неконкретный. Джун не выбирает воркфлоу, он пользуется принятым на проекте. Джун едва ли будет выпускать релиз или поставку, ему не нужно знать тонкости, когда мержить релиз с мастером, откуда отводить хотфикс, где ставить теги и т.п. Я бы включил сюда более конкретные вопросы:Znack commentedon Mar 1, 2021
Кстати про гит крутые замечания, согласен что многие темы можно вполне на мидла перенести 👍
kelizarov commentedon Mar 2, 2021
Я бы может добавил в гите вопрос про именование веток и как лучше их называть чтобы потом не потерять. Допустим как связать номер таски которую делаешь с веткой в гите.
vkpgwt commentedon Mar 2, 2021
Это можно прописать в гайдлайнах проекта. На разных проектах могут быть разные правила.
olgaklimenko commentedon Mar 3, 2021
Data.Either.Validationсовсем и положить ресурсы в Coda, куда мы просто складываем ссылки на интересные/полезные статьи. Штука интересная, но применяется редко и я думаю не обязательно знать про нее подробно заранее, тем более делать обязательный вопрос.IOвопросы можно отправить обратно на 1го джуна в разделMonad. Вопросы не такие уж сложные, но дают понимание как IO устроено.MultiParamTypeClasses, FD, TF, GADTs, Data Kinds, PolyKinds, ScopedTypeVariablesоставить на 3 джунеHigher ranked types, ExistentialQuantification- оставить тоже тут, хотя возможно можно было бы перенести на миддла. (Мне на миддла не хочется переносить что-либо, потому что там большой уровень, + SICP + linux + databases + networking + design.)ConstraintKinds- надо понять насколько это часто используемая штука с кучей теории под собой, может вообще не нужно включать это в карту развития.ExceptionsоставитьTesting,Debuggingоставить на 3м джуне, чтобы разбавить несложными темами.В итоге на 3м джуне останутся:
MultiParamTypeClasses, FD, TF, GADTs, Data Kinds, PolyKinds, ScopedTypeVariables, Higher ranked types, ExistentialQuantificationНа 2м джуне будут:
vkpgwt commentedon Mar 3, 2021
Ок, только я бы предложил оставить StandaloneDeriving на третьем. В доках по StandaloneDeriving упоминается дерайвинг GADTs и экзистенциалов, это важно. Пока не изучишь эти типы, информация про их дерайвинг в голове не задержится.
Мне показалось, там немного теории. Много примеров использования и всяких паттернов, это да. Штука нужная, она объединяет тайпклассы/контексты с типами и позволяет использовать переменные в контекстах - это самое важное, что нужно о ней знать. Может, она и редко используется, но то же можно сказать про другие продвинутые темы. Достаточно знать, что такая фича есть, а детали всегда можно уточнить по докам.
Можно ее вытащить на мидл. Чеклист хаскеля на мидле, по сравнению с jun3, какой-то мелкий :).
olgaklimenko commentedon Mar 3, 2021
Поняла, значит
ConstraintKindsтоже нужно оставить (я просто еще не читала их :( ), ну и если у нас только 1 тема на миддла перенесётся, я не против :) Там просто помимо хаскеля много всего на уровне есть, не хочется много тем туда тащить.При сдаче
StandaloneDerivingмы кажется и не рассказывали особо про дерайвинг гадт и экзистенциалов (ну или мб рассказывали, просто не достаточно осознанно, я думаю). Можно и перенести вопрос на 2го джуна чтобы не отделять от остальных дерайвингов и не требовать там правила для гадт, и добавить один вопрос на 3го джуна после изученных экстеншенов как раз.vkpgwt commentedon Mar 4, 2021
Согласен. Только вопрос вроде не требуется, про дерайвинг гадтов и экзистенциалов вопросы уже есть. Маленькое пожелание - хорошо бы добавить ссылку на нужный абзац доки StandaloneDeriving на jun3, чтобы сдающий обратил на это внимание. Но дока GHC не поддерживает ссылки на абзацы :(.
В данном случае не спорю, но вообще мне кажется, это не обоснование :). Ничего плохого, если одна тема изучается снова и снова на разных уровнях, с разным уровнем глубины и сложности.
olgaklimenko commentedon Mar 9, 2021
да, слабое обоснование) Так что соглашусь, давайте на третьем оставим
StandaloneDerivingolegromashin commentedon Mar 9, 2021
Я бы унёс все дерайвинги на второго. Включая StandaloneDeriving. В любом случае, когда читаешь про GADT и экзистенциальные типы - увидишь и про дерайвинг.
Лень хотелось бы оставить на третьем, чтобы первым джунам было легче разогнаться.
Validation тоже не хочется убирать. Знание того, как провалидировать несколько значений, а не вернуть одну первую ошибку довольно важно. Кроме этого, разбираясь с Validation лучше понимаешь разницу монад и аппликативов. Я на первом джуне чисто интуитивно что-то там рассказал до конца не осознавая, а здесь можно вспомнить и разобраться.
На счёт IO я против. Чтобы осмыслить ответы всё же надо углубиться. По крайней мере мне было сложно. Первому джуну это лишнее.
Т. к. тайпклассы у нас отдельная тема на третьем джуне, то может
FlexibleContextsиFlexibleInstancesтоже лучше было бы там оставить.kelizarov commentedon Mar 9, 2021
Насчет
Validationя думаю есть смысл убрать из карты, но оставить источник. По мне это знание из разряда "а вы знали, что ...", типа оно не совсем систематическое. Статья неплохая что может вбустнуть понимать различия Монады от Аппликатива и как одна и та же проблема реашется разными абстракциями.Я в большинстве согласен со всеми пойнтами что @olgaklimenko расписала в комментарии.
olgaklimenko commentedon Mar 9, 2021
@olegromashin получается ты хочешь почти полностью всё оставить на 3м джуне? Или есть какие-то другие предложения, что можно вынести? Вынос только дерайвингов мало поможет :)
Разницу монад и аппликативов мы спрашиваем на первом джуне, и лучше тогда расширить вопрос и ресурсы, чтобы было более понятно сразу, и не ждать до 3го джуна. Можно как опциональный ресурс добавить валидацию сюда, как пример, что может быть инстанс аппликатива без инстанса монады.
Тоже спорно, т.к. нас вроде как четверо (Стас, я, Кирилл, Вова), кто сдавал этот вопрос на 1 джуне. Вроде как не было сильно сложно, тем более в карте
IOпослеStateидет. И про IO сейчас всего один вопрос на первом джуне, это мало, надо также как и про State, Reader и тд. спросить как запустить монаду, чтобы наоборот было понимание почемуIOтакая особенная.3 remaining items
olgaklimenko commentedon Mar 10, 2021
Я вообще изначально была за то, чтобы не трогать ничего и не переносить темы, т.к. всё равно надо будет проходить их все. Но ребятам, кто сейчас только в начале карты развития, очень пригодилось бы такое распределение, и запрос был как раз от них. Позову тогда еще 2х джунов, узнать фидбек про то, насколько решение увеличить 2го джуна кажется им подходящим.
stanislav-az commentedon Mar 10, 2021
Сегодня на сдаче 3 джуна возникла идея перенести вопросы про monad unlift io & monad base control на мидла 1. На мидле как раз еще по эксепшенам вопросы и про
MonadMask, а это связанные темыstanislav-az commentedon Mar 10, 2021
Предлагаю еще на джуна 2 добавить вопросы про TypeApplications, а на 3 джуна добавить OverloadedLabels & OverloadedLists
vkpgwt commentedon Mar 10, 2021
Это наверное лучше указать в другой таске, а здесь обсуждаем только распиливание jun3, может потеряться. Для 3 джуна это #291, для второго нет таски.
catdarick commentedon Mar 11, 2021
Разбиение - круто, в принципе со всеми озвученными здесь предложениями согласен.
Но ещё бы хотел высказать своё мнение о сомнительной полезности некоторых вопросов, например набор вопросов
How to ...из блока Linux на втором джуне.По-моему это вопросы, с которыми человек либо регулярно сталкивается сам и знает решение, либо гуглит раз в год по мере необходимости и от дефицита знаний не страдает. От того, что к моменту сдачи я узнал набор флагов и команд для некоторых утилит, я особо профессиональнее не стал, а сейчас я их и вовсе уже не помню, так как не использую. Думаю заместо них стоит спрашивать более насущные и общие вопросы, про переменные окружения (как изменить
PATH, например), bash с его операторами, возможно grep.Также спорными мне кажутся вопросы про законы для представителей тайпклассов:
Foldable,Traversableи т.д. Как эти знания могут где-то помочь? Я думаю мало кто будет опираться на свою память, когда будет создавать нового представителя этих тайпклассов, проще и надёжнее просто зайти на хэкэдж.Znack commentedon Mar 11, 2021
Я кстати за то, чтобы мы не столько сами вопросы спрашивали, сколько "а почему законы именно такие" или скорее даже "в чем смысл именно таких законов"? Потому что законы не просто так придуманы и подобраны для каждого тайпкласса, жедательно понимать именно то, зачем на эти законы стоит чекать инстансы для кастомных типов данных
vkpgwt commentedon Mar 11, 2021
Видимо, когда писали вопросы, эти знания были нужны. В самом деле, может, выпилить вопросы про ключи
ps, или даже про всю командуps, легко гуглится же. "Как найти процесс в линуксе из командной строки".Это высокоуровневые абстракции, как монады или аппликативы. Здесь важно не запомнить информацию из хакаджа, а получить интуитивное понимание - как они себя ведут, где и зачем применять. А еще ghc умеет дерайвить их инстансы автоматически - бывает очень кстати.
С траверсаблом такое дело - его свойства описаны в пейпере, но он слишком сложен, чтобы требовать его на jun2. А без пейпера я заблуждался во многих вещах. Или выделять из пейпера главное в отдельную статью, или выносить пейпер по траверсаблу на мидла.
olegromashin commentedon Mar 19, 2021
Объясню почему я не хочу уносить много на второго джуна.
Хочется оставить второго джуна относительно лёгким, чтобы новеньким было легче разогнаться и сделать первый шаг в карте. Если второй джун будет занимать много времени, то это может увеличить кол-во времени, которое потребуется для того, чтобы начать сдавать третьего джуна. Не уверен, что это решает проблему застоя, но мне кажется так лучше.
Если мы решаем проблемы большого третьего джуна, то давайте подумамем не о том, куда можно всё распихать, а том правильно ли темы разделены в карте. Я думаю у нас сложные экстеншены не на своём месте просто от того, что первый мид слишком большой. От этого и страдает третий джун. Я считаю надо думать о том, чтобы нести сложное на мидла.
Была идея 4 джуна сделать, но звучит как какой-то костыль, потому что по сути ничего не меняется.
Какбы да, но здесь человек уже почуствовал вкус роста по карте, может дополнительная мотивация будет.
Znack commentedon Mar 19, 2021
Я предлагаю вместе jun-3 рассмотреть с mid-1 вынести на mid-2 и выше темы :)
vkpgwt commentedon Mar 19, 2021
Но в проекте эти экстеншены используются. Джуну нельзя будет поручить многие задачи, связанные с чтением или правкой кода, где используются экстеншешы, которые он еще не освоил. Не будет ли проблем с этим?
olegromashin commentedon Mar 19, 2021
Есть экстеншены, которые пригодятся только при построении сложных абстракций. Такое джуну вряд ли поручат. В крайнем случае, если потребуется работать на базе чего-то такого, можно посмотреть как сделано где-то рядом и сделать также, я так с DataKinds что-то делал, когда даже не знал такого расширения.
Ну и чатик всегда есть.
olegromashin commentedon Mar 22, 2021
По поводу Гита: ребейз надо оставить, у нас на проекте пользуемся им.
По остальным пунктам согласен с Антоном, можно унести на мидла. Но тогда 2 мини-раздела получится. Обычно у нас как-то сформированы разделы на одну итерацию минимум, а тут два по 0.5 итерации будет. Если не проблема, то я за.
Но готовиться на самом деле недолго, пару вечеров.
vkpgwt commentedon Mar 22, 2021
Разделение гита надо будет согласовывать с фронтендом, они используют тот же список вопросов.
Znack commentedon Mar 22, 2021
Тогда по гиту лучше отдельное ишью завести и туда фронтендеров позвать :)