Обновить
-1
1.8

Специалист по теории типов USB-кабелей

Отправить сообщение

А вот капиталист выжмет из тебя все соки за "конкурентную" зарплату, которой не факт что хватит для обеспечения благосостояния.

Это программистам не хватает для обеспечения благосостояния? Это программистов выжимают, и у них нет альтернатив? Лол.

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

Социалистические (коммунистические) идеи в США расцветают тогда и среди тех, кто для обеспечения базовых потребностей может реально работать где-то пару часов в день. Сегодня эти идеи — это что называется luxury beliefs.

Люди не на пособиях, мелкие самозанятые, и так далее, почему-то этот коммунизм в гробу видали.

Отпуска, пенсии и больничные тебя, мой 14-ти летний друг, ещё точно не волнуют.

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

А если серьёзно, отпуска, пенсии и больничные меня вполне волнуют. Пенсия у меня в 401k + личные инвестиции (я считал — это в разы, если не на порядки, эффективнее государственной пенсии), отпуска у меня между работами (занимают месяца, а иногда и год-другой) и по одному дню по пятницам каждый год с этак августа (и мне так удобнее, чем обязательные неделя-две), да и больничные тоже есть. Всё это — сильно выше того, что мне гарантирует весьма слабый трудовой кодекс Штатов.

Вы спросили в чем минусы, я ответил в том что это может стать таковым. Не станет - так и чудесно.

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

Например, отвечать «в чём минус доступности кофе без лицензии и ограничений?» чем-нибудь в духе «кофе — диуретик, поэтому если все начнут пить только его, то умрут от обезвоживани. а не умрут — так и чудесно» формально можно, но бессмысленно. Или там «разрешать аборты плохо, потому что если вдруг все будут делать аборты, то человечество вымрет. а не вымрет — так и чудесно».

И именно поэтому

Но забавно, что этот аргумент вам в голову не пришел.

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

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

Можно, кстати, посмотреть транзитивное замыкание этих вещей.

Для ИИ нужны видяхи. Следовательно, кранчи в nvidia оправданы. Для видях нужен платежеспособный спрос. Следовательно, кранчи в геймдеве оправданы. Для машинных обучателей нужна работа, следовательно, машинное обучение рекомендательных моделей жоп в инстаграме — общественно полезное дело, и кранчи там тоже оправданы.

Но это так, в порядке развития мысли.

Думаю очевидно, что такие законы прежде всего будут иметь слишком много побочных и сложнопредсказуемых эффектов. Надо ли дальше расписывать?

А с работой такого не будет?

Способность части людей работать по 12 часов в сутки неотличима с этой точки зрения от способности части людей работать 8 + самообразовываться 4 часа в сутки.

Могу привести простой пример - во всех развитых странах сейчас запрещено продавать ядовитую еду.

Неправда. Алкоголь разрешён и не имеет ограничений по объёму на продажу. Сладкая еда с сахаром разрешена и не имеет ограничений ни по объёму, ни по возрасту на продажу.

Конкретно ментоловые сигареты (известный общественный риск для здоровья) разрешены на федеральном уровне в тех же США. Но не потому, что «люди должны иметь право выбирать себя гробить как угодно» (с чем я бы согласился как анкап), а потому, что «ментоловые сигареты особенно любимы расовыми меньшинствами, поэтому запрет — это расизм», или чё-т такое.

Я могу собраться и привести пару десятков примеров ядовитой/вредной/связанной с раком еды и подобных продуктов, которые, однако, спокойно продаются.

Ни одно нормальное общество не полагается на то, что отравившиеся люди как вы говорили в другой ветке "сами виноваты"

Я говорил в другой ветке «сами виноваты» о слегка другом классе поведений. Вы это не заметили, или заметили, но на самом деле ведёте дискуссию недобросовестно и приписываете моим словам контекст, который сильно меняет их заряженность?

Реальная жизнь - это набор компромиссов и нейтрализации все тех же побочных эффектов.

Проблема в том, что невозможно централизованно просчитать все возможные компромиссы и их нейтрализовать. Из такой централизации получается ерунда. Единственный способ это сделать нормально — да-да, позволить рыночку решать. Ну или, в данном случае, мета-рыночку: чтобы в одном государстве был социализм и никому нельзя выделяться, а в другом — зубастый капитализм. Потом посмотрим, где больше открытий, где больше стартапов, где больше 1T-компаний, и куда больше люди иммигрируют (хинт: например, из стран Скандинавии в США, а не обратно, несмотря на существенно более наркоманскую визовую систему США).

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

Предложения на синиоров как бы намекают, что это всё не так. Смотрю по своей специализации на рынке США за последние лет 12.

а еще и ИИ подъедает часть работы.

Единственное, что ИИ подъедает — пайплайн обучения джунов в недальновидных компаниях. Так-то оно только работы подкидывает.

Так что ситуация будет возвращаться к норме например для врачей или юристов, ученых или конструкторов.

Врачи получают дохрена [в Штатах], юристы тоже неплохо, учёные… там отдельная история, настолько далёкая от айти, что на это можно забить.

Что же касается некого экономического кризиса - никто не застрахован от его перерастания в новый и крупный кризис, это опять же исторически вполне возможно.

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

И уж точно пузырь ИИ с очень высокой вероятностью сдуется

Как можно одновременно писать «ИИ подъедает часть работы» и «пузырь ИИ сдуется»? Это почти наверное следствия из сильно разных, несовместных мировоззренческих картин.

в духе пузыря доткомов (из чего не следует что ИИ бесполезен, гугл тоже доткомом был) и неизвестно насколько сильно это ударит по мировой экономике в целом.

А чё там после пузыря доткомов, айтишка откатилась на уровень «конструкторов»?

В чём смысл проводить аналогию с пузырём доткомов, если она опровергает ваш тезис?

Это откровенно странное высказывание. У огромного количества людей интересы лежат далеко не в тех областях, в которых можно стабильно заработать деньги на жизнь.

Я не против и их не критикую. Просто если вы начинаете рассматривать этих людей, то непонятно, какой вывод вы делаете. Надо ограничить овертаймы потому, что иначе им тяжко? Надо стремиться уравнять в зарплатах и условиях труда тех, кто пишет код с 10 лет и тех, кто впервые написал код на первом курсе специальности, выбранной по «бабок вроде норм платят и на ЕГЭ баллов хватило»?

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

Хорошие юристы любят свою работу и интересуются ей вне работы. Хорошие врачи читают статьи после работы (после того, как выжили в интернатуре). Хорошие учёные прошли через publish or perish.

Пришедшие тупо за баблом остаются paralegal'ами, или низкооплачиваемыми околоэйчарами в компаниях, или ассистентами ветеринаров, или публикуются в Вестнике Усть-Пердыщенска дважды (или сколько там для защиты диссера), защищают унылый диссер в 30, и больше про него никогда не вспоминают.

Так я и сужу на данный момент именно высказывания. И такие высказывания опасны для общества и как по мне должны вызывать общественное неодобрение.

Ну вот я общественно неодобряю гугл по этой и многим другим причинам (цензура интернета в американском инфопространстве, например — куда большая такая причина, чем визгливые CEOреканья, на которые уже давно никто не обращает внимания). Но я не требую от государства ничего зарегулировать и запретить.

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

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

Если hookup culture превращается в массовую практику, из-за чего какие-то дикие количества мужчин являются одинокими, что негативно влияет на здоровье, рождаемость, вовлёченность их в экономику, и так далее, то надо ли законодательно ограничить hookup culture и забанить тиндер?

(да, социалисты — это инцелы от экономики)

А вот где, кстати, про действия как first-class можно почитать?

В любой книжке по ФП :]

Это ж просто higher-order functions. Передаёшь функцию (олицетворяющую действие) в функцию, и всё. Вот тебе паттерн «стратегия».

Каррирование — это просто паттерн «фабрика». И всё.

Нет. Дело здесь не в наличии конкурентного общественного строя, а в том, что крутить гайки руками можно дольше, чем крутить коммутативные диаграммы башкой (я пробовал и то, и другое, это не элитизм).

То обе не годятся и сравнивать их бесполезно.

Да, если один программист за X времени починил 40% сломанных тестов, а другой — 90%, то они оба одинаково негодные программисты, их сравнивать нельзя. Надо починить 100%, и потом сравнивать.

Тем более, что на практике может встречаться эквивалентные 80%, скажем, которые реализацией A уже покрываются, а B — нет.

Возможно в варианте B намного более сложные задачи решены.

Как я и говорил выше, это для вас вопрос веры: вы, «не зная книг по которым я учился», делаете выводы.

Я не про то. Циркулярка может отпилить пальцы.

Да. Поэтому если что-то можно выпилить при помощи и циркулярки, и miter saw (хз как по-русски), то я предпочитаю miter saw, ровно потому что она от пальцев дальше.

Что самое странное (нет), чем мощнее инструмент, тем больше вреда он может долбоёбу нанести.

Из этого не следует, что любой инструмент, могущий нанести много вреда долбоёбу, заведомо более мощный.

Поэтому логика [...]

[...] хромает в вашем рассуждении выше, сорян.

У меня впечатление, что вам тяжело не переходить на личности.

Для протокола, переход на личности — это аргументация вида «ты неправ потому, что ты идиот и хочешь свою мамку» (хотя последнее скорее фрейдизм, но неважно). Высказывание «ты неправ потому, что A и A ⇒ B известно нам обоим, поэтому из этого следует B, но ты делаешь вывод ¬B» не является, например, переходом на личности. Кстати, переходом на личности не будет даже последующее высказывание «поэтому ты идиот». Вопрос исключительно в том, стоит характеристика личности слева или справа от значка ⇒.

Но это, впрочем, неважно, потому что апелляция к личности — это метод ведения спора, а спор — он вокруг потенциально обсуждаемых высказываний, а фраза «у хаскеля всё плохо с компилятором» поддающимся обсуждению высказыванием не является. У хаскеля всё плохо с компилятором. У C# всё плохо с компилятором. У C++ всё плохо с компилятором. Почему? Я художник, я так вижу.

Был бы другой разговор, если б вы сразу написали, скажем, что…

Ghc очень долго компилирует и жрёт много памяти. Я такую информацию слышал.

… но очень долго — это сколько? И сколько другие компиляторы языков с не менее слабыми по выразительной силе системами типов компилируют с -O0? (известные мне — дольше) Сколько компилируют компиляторы с -O3, которые выдают похожий по производительности код из похожего кода по высокоуровневости?

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

И судить о готовности языка к проду по скорости компиляции и потреблению памяти — плохая идея. У вас тогда и C++ не готов.

Может просто я привык к дотнету, где всё практически моментально.

Я привык к LSP, где всё практически моментально. Пишешь код, а тебе сразу красным подчёркивается, где ты неправ. С какой скоростью работает компилятор — совершенно неважно, потому что саму сборку нужно запускать очень редко.

Может стоило сказать, что ghc нормальный, а компилятор в dotnet - отличный. Да?

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

Ну серьёзно, вот посмотрите на уровень, за который то и то отвечает. Вот зачем нужна беготня по деревьям, когда нет гуя?

Ну, не знаю, когда вы компиляторы пишете, то за всем?

Мне вообще ни разу в жизни не платили за проекты, где был бы гуй (или где хотя бы пригодился бы гуй). Пет-проект у меня такой, с гуями, ровно один, и я его начал школотроном в 15 лет, когда не знал ничего лучше.

Ну допустим, в паре мест бы пригодилось. Но я и так дерево обойду, чай не на брейнфаке.

Ну да, выше уже обошли. 10 строк неподдерживаемого кода вместо одной.

И это я ещё не говорил о магии вроде uniplate.

Во первых это достаточно спорное заявление. Ну или как минимум это очень субъективно.

Безусловно. Вопрос личного опыта, который, однако, вполне себе может быть дополнительной точкой данных.

Объективных сценариев успешной счастливой жизни вообще нет.

А во вторых: так а мне то вы это зачем рассказываете?

Я рассказываю не вам, а в ветке с вашим участием. Потому что эта ветка релевантна.

Потому что лучше всего это получается, когда некоторое время (пару лет) работа — это жизнь (в понимаемом исходными комментаторами смысле, то бишь, когда на неё тратится «слишком много» времени).

Мне вот хочется отпуск на пару лет периодически, и в Европе он не очень достижим, а в Штатах — вполне. В итоге в Штатах получается работать меньше, а получать — больше.

С учетом среднего срока работы 2-3 года и непредсказуемости смены работы это букет не дом а общага.

Американцы вообще так в целом живут. ЕМНИП они переезжают в среднем около 12 раз за жизнь, и с 18 до 35 меняют съёмную квартиру как раз в 2-3 года.

для молодого холостяка

Ребенок

Кажется, вы обсуждаете слегка разные вещи.

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

Однако, не стало за многие десятки лет наличия таких компаний.

И нормой даже не потому, что крупными корпорациями руководят злодеи, а потому что те, где работают меньше не будут выдерживать конкуренции.

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

Но поинт интересный, конечно. Давайте проведём мысленный эксперимент. Если бы это было реализуемо, то выступали ли вы бы за законодательный запрет, скажем, саморазвития по вечерам и выходным? Ведь те, кто не впахивает, и у кого семья-хобби-етц, может проиграть конкуренцию тем, кто впахивает, и впахивать в итоге придётся всем, разве нет?

Мы в айти как-то привыкли к благам узкого периода, когда айтишники были в остром дефиците и могли выставлять свои условия работодателям, но это время уходит в прошлое, статей про проблемы с наймом масса и на Хабре и в англоязычных источниках и дальше будет хуже.

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

Собственно называть Google стартапом несколько наивно - это та самая крупная корпорация и 60 часов там уже не пределом считаются, а "золотой серединой" судя по высказыванию их начальства.

Рекомендую судить не по высказываниям начальства, а по делам. Там работающие люди всё ещё не обязаны работать по 60 часов.

Я работал в одной похожей компании (и по объёму, и по позиции на рынке, и так далее). Ну, да, там был некий дискурс одобрения послеурочной работы и демонстрации впахивания, и CEO компании как-то разослал письмо с текстом вроде «Хотите знать, как я пришёл к успеху? Приходил на работу раньше всех и уходил позже всех.» Но собака лает — караван идёт, и можно было спокойно продолжать работать с 9 до 5 (ну или с 12 до 8, в моём случае). Не могу сказать, что на той работе я как-то выгорел.

А вот, кстати, когда пришлось с французами поработать, там было как-то на самом деле потогонненько местами, да. Хотя, казалось бы, евросоциализм, все дела.

Ваше представление о сопоставимости результата может сильно отличаться от реального. Утверждать не буду, надо знать детали.

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

Например, есть набор тестовых программ, которые компилятор (эта штука на 5к строк — компилятор для предметно-специфичного языка, да) должен успешно компилировать. Если реализация A компилирует, скажем, 90% набора в правильно исполняемый код, а реализация B — 40%, и на пересечении этих множеств исполняемый код от реализации A работает настолько-то быстрее, то вполне можно сказать, что результат не просто сопоставим, а кратно лучше.

Нет. Это ошибочная логика. Впрочем на вкус и цвет. Гугл создал Го, в котором не разгуляешься и не выстрелишь себе в ногу. Но в этом же его беда. Впрочем, гуглу виднее - наверное так быстрее набирать кодеров.

Я тоже не люблю го. Но да, задачи гугла го решает отлично: это хороший инструмент по критерию «можно взять вчерашнего выпускника и посадить писать микросервисы». Плюсы — хороший инструмент по критерию «широкая доступность работы и интеграция с легаси-системами». JS — хороший инструмент по критерию «работает в браузере». Хаскель — хороший инструмент по критерию «о коде легко рассуждать, глядя только на типы, код сразу работает после рефакторинга, поддерживается type-driven development, и так далее». Он не обязан при этом быть хорошим для использования вчерашними выпускниками, или работы в браузере, или интеграции с легаси-системами.

Инструментарий - это не только типы и конструкции языка. Это дебаггер, компилятор, это выбор гуя. Со всеми этими пунктами у хаскеля плохо.

У меня всё больше впечатление, что вы не знаете, о чём говорите. Почему с компилятором-то плохо, например? ghc — это лучшее, что у меня было.

Выбор гуя — да, здесь согласен. Гуй на хаскеле я бы делать не стал. Правда, я бы его ни на чём бы делать не стал, но это другой вопрос.

И вы говорите «гуй, авалония и хот релоад», а я говорю «репл, беготня по деревьям, и готовые алгоритмы унификации или монадический байесовский инференс».

Неужели вы хотите прожить жизнь, занимаясь неудовлетворяющей вас деятельностью? И вы готовы с этим мириться, если вам за это немного платят?

Нет. Я хочу проработать несколько лет, занимаясь неудовлетворяющей меня деятельностью, так как за неё достаточно платят, чтобы потом несколько лет не работать.

Счастье для человека - когда он за деньги делает то, что делал бы и бесплатно. А для компании счастливый сотрудник - это надёжное вложение, потому что он будет эффективно работать в компании до самой пенсии.

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

Не существует компаний, которые могли бы конвертировать, скажем, моё желание читать книжки, изучать теоркат и писать всякий код по фану (до уровня proof of concept, не доводя до продакшена), в деньги, которые они бы могли бы потом мне платить.

Пример худшего - плохой вариант.

Это пример, показывающий, почему «крупные проекты» по вашим определениям вам не видно.

У меня есть ещё одно объяснение, но оно вам не понравится. Я промолчу, потому что не знаю деталей.

Мне скоро спать пора, а как я уснуть смогу, не зная, что там за объяснение такое?

Пример худшего - плохой пример. ООП - инструмент. Им можно хорошо уметь пользоваться, можно пользоваться во вред себе.

Если инструмент устроен так, что им легко отрезать себе пальцы, то это плохой инструмент. Если в инструмент добавлены защиты, чтобы обе руки не попадали в рабочую зону при работе — это хороший инструмент.

Говорите, как будто это что-то плохое.

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

У чистого ФП гораздо хуже инструментарий управления сложностью.

Потому что ведь нельзя, чтобы просто в типах всё было видно, да? Надо, чтобы мышкой надо было поелозить в IDE, и чтобы комментарии были устаревшие. Ведь основная сложность для нас — это поиск работы, соответственно борьба со сложностью — это обеспечение job security.

Там низкий порог входа за счёт отсутствия ограничений по типам, необязательного структурирования данных. Что вижу - о том и пою. Шарп, java - это языки другой весовой категории, где есть продвинутый инструментарий для управления сложностью.

Кажется, вы начинаете до чего-то догадываться.

Потому что 5 и 50 - это цифры разного порядка. Я смотрю сейчас на свой проект. Вот основная часть, где 36к без тестов. Вы её никогда в жизни не уложите в 3600 строк.

А я смотрю на свой проект, где 5к делало больше, чем несколько десятков к соседней команды. И? Какой вывод?

Иначе мы бы видели засилие ФП в больших и сверхбольших проектах. А там традиционно ООП.

Если под «традиционным ООП» понимать «нафигачили паттернов по книжкам, в итоге вообще ничего не понятно», то да, с таким я встречался.

Если чуть серьёзнее, то разгадка одна: на мейнстримных императивных языках можно быстрее выдать что-то, как-то более-менее работающее. Разработка софта — это жадный алгоритм, поэтому имеем то, что имеем.

А где и зачем здесь наследование типов?

Да и как явное преобразование типов — результат эволюции идей ООП, непонятно. Это вообще частный случай функции из одного типа в другой.

Потому что это характеристика личных качеств людей, работающих в парадигме ООП.

«Не принято воспринимать X как Y» — это не характеристика личных качеств.

Равно как и пример про кошечек и собачек. Вам откуда знать, по каким книгам я учился?

Где я написал про книги, по которым вы учились?

То, что ваш проект на 5к строк хоть немного близок по объёму к моему на 50к - это, мягко говоря, неправда.

Почему? Практика показывает, что это достаточно точная оценка.

Я вот читаю весь этот снисходительный пафос и не пойму... А где решение в 10 раз короче?

Сразу после списка.

То, что я написал - работает.

Не работает, и я написал, почему, в половине пунктов списка.

И не работает с точки зрения поддерживаемости крупных проектов в долгосрочной перспективе, и об этом вторая половина списка.

У вас loadComments использует готовые структуры языка/библиотек и выдаёт данные, подогнанные к условиям задачи.

А если бы там хэшмапы ещё участвовали, то вы бы сказали, что пример подогнан под хэшмапы? Или хэшмапы типа можно, потому что они в C# есть из коробки?

Ну возьмите готовую библиотеку с реализацией деревьев, я разве против?

Вот так говорить вообще не надо. Это в крайней степени некорректно.

По причинам несоответствия этого утверждения объективной реальности, или потому, что звучит неприятно?

Если второе, то я-то думал, что мы тут с вами открыто и смело и прямо в лицо, 359!

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

Демонстрационный пример про выразительность языка.

Говоришь про примеры из практики (которые в комменты не влезают) — не подходит. Приводишь примеры, которые в комменты влезают — не подходит. Ну вы скажите, что это всё для вас вопрос веры, и я отстану тогда, ё-моё.

Это тоже некрасивый приём. В моём коде таких конструкций нет. Вы её сами продумали.

Конечно, лучше писать «типичной ФП-сплющенной чёрной магией, где за смысл отвечают знаки препинания, а не слова».

Меня это не оскорбляет, я вообще так-то матершинник, вырос на двач-adjacent-культуре, и кожа у меня толстая. Единственное, что оскорбляет и задевает лично меня — это двойные стандарты, поэтому я оставляю за собой право отвечать в том же стиле, в котором говорит мой собеседник. Есть шанс, конечно, что я интерпретирую стиль неправильно, но тогда уж прошу простить. Искренне.

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

Любое предметное обсуждение — задетое самолюбие и потребность в доказательстве чего-то там? Лол.

Вот это мне вообще не понравилось. Прямо какой-то дон в белом плаще смотрит, как там крестьяне палкой землю ковыряют.

Есть удачные базисы, по которым можно раскладывать сложность, и неудачные. Если обсуждение и сравнение этих базисов для вас выглядит как вот описанная сцена, то это, конечно, печально, я бы так относиться к этому не стал.

Идёт?

Нет, это скучно :(

Причём тут кошечки и собачки, когда это просто система типов, а ООП до потери смысла нетипизирован [по замыслу создателей smalltalk]?

Сначала по коду — это, конечно, лол. Код превзошёл мои ожидания, но не в ту сторону, в которую вы думаете.

  • У вас почему-то связана концепция «рекурсивная структура данных такой-то формы» и «что может лежать в каждом узле этой структуры»: Node (в ваших ООПных терминах) сильно связано и с хранением детей, и с хранением конкретных данных в узле.
    Сравните с определением Tree/Node, которые я давал выше.

  • Концепция «обойти дерево» тоже связана с содержимым этого дерева.
    Но я всё эти связности могу понять: книги по ООП учат разделять кошечек, собачек, квадратики и прямоугольнички, а не действия. В ООП вообще не принято думать в терминах действий, потому что действия не являются first-class. Чтобы выразить действие, апологет ООП (ООПологет?) навернёт десяток паттернов из фабрик визиторов стратегий.

  • У вас никак не выражаются инварианты на уровне типов (да и типов нет, stringly-typed комментарий и ошибка не считаются). Комментарий может быть, а может и не быть. Ошибка может быть, а может и не быть. Они могут не быть оба сразу. Они могут быть оба сразу. По чтению определения данных ничего непонятно, надо читать алгоритм, чтобы понять, что происходит. И в вызывающем коде надо проверять явно их наличие (забыл проверить ошибку — твоя проблема).
    Сравните с Either NetworkError Comment — там всё сразу видно, и обратиться к комментарию, если его нет, невозможно.

  • Собсна, дерево до загрузки комментов и дерево после загрузки комментов на уровне типов тоже никак не отличаются.
    Сравните с Tree Int и Tree Comment (или Tree (Int, Comment), если вашей душе так угодно). Type-driven development? Не, не слышали.

  • LoadComments почему-то является нестатическим членом класса, хотя к полям экземпляра класса никак не обращается. Как читающему только тип функции понять, как связана та Node, которая this, и та Node, которая передана как node?

  • Func<int, string>, конечно, понятнее и синтаксически чище, чем Int -> String (который у меня с лигатурами выглядит как Int → String) Читать Func<int, List<int>, string> тем более легче, чем Int → [Int] → String — заодно глаза тренируются скобочки считать и различать, в старости пригодится как защита от Альцгеймера.

  • Кстати, как у вас выражается rank-n-полиморфизм? Как будет выглядеть тип функции, который на хаскеле выражается как forall a. Show a => a -> a -> String, скажем? Ну, то есть, функция, которая принимает два аргумента (одного и того же) любого типа, реализующего интерфейс IShow(и возвращает строку). Что нужно будет написать вместо ... в Func<...>?
    Ой, я по ассоциациям ещё про multiparam typeclasses вспомнил, но не стоит вскрывать эту тему, это уже будет просто избиение младенцев.

  • Я не могу посмотреть на результат LoadComments и понять, произошла хотя бы одна ошибка в дереве или нет (это вообще было одним из условий, про которые я регулярно говорил). Мне после вызова LoadComments надо будет обойти дерево ещё раз. И чтобы собрать ошибки в список, его тоже надо будет обойти.

  • try/catch ловит все ошибки и теряет информацию о типе, тупо записывая Message. Я просил весь тип ошибки целиком.
    Олсо, это совершенно неподдерживаемый код: если раньше loadComment по каким-то причинам не кидала ошибок (например, потому что разработчик как настоящий фанат OOP, TDD, SOLID, CBT и SPH сначала всё мокал, а моки ничего не кидали, скажем), и поэтому вы не написали try/catch, то после того, как loadComment таки начнёт кидать ошибки, вы, конечно, свой код не обновите, потому что компилятор вам про это не скажет.
    Зачем так жить в 2025-м году?

  • Что-то ещё было, но пока я мучался с интерфейсом firefox'а, чтобы отделить вкладку и перенести её на второй вертикальный экран, потому что на моём горизонтальном экране список вытеснил ваш комментарий с кодом, я это что-то забыл, но, думаю, и так хватит. И так уже число комментариев совпало с числом непустых и не-чисто-синтаксических строк вашего кода.

Сравните с моим вариантом, который я себе позволю одной строкой, раз цепочки функций вам норм:

loadComments :: Tree Int → IO (Validation (NonEmpty NetworkError) (Tree Comment))
loadComments = fmap sequenceA . traverse (fmap (liftError pure) . loadComment)

Всё. Дерево (Tree, это тип из стандартной либы) обходится (в traverse, это стандартная функция). Ошибки собираются (в sequenceA, это стандартная функция). Разделение на ошибки, комментарии и структуру есть. Validation (единственная не оч стандартная, но достаточно известная штука, которую я подключил: вопрос дописывания validation в package.yaml) гарантирует семантику «либо ошибки, либо дерево комментов». NonEmpty (тоже тип из стандартной либы) гарантирует, что есть хотя бы одна ошибка.

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

Если не наглеть и сделать, как я бы сделал для прода, то я вынес бы обёртку для loadComment отдельно, и всё вообще читабельно без лишних скобочек:

loadComments :: Tree Int → IO (Validation (NonEmpty NetworkError) (Tree Comment))
loadComments = fmap sequenceA . traverse loadCommentValidating
  where loadCommentValidating = fmap (liftError pure) . loadComment

Современные IDE показывают, какие эксепшены может кинуть та или иная функция.

Это алгоритмически неразрешимая задача. И я обычно пулл-реквесты, например, ревьювлю в интерфейсе гитхаба, и диффы смотрю там же (или в консоли c git show / git diff). Там IDE как-то не оч работает.

В каких-то языках в комментах пишут.

Комменты-то у нас, конечно, не устаревают и проверяются компилятором при каждой сборке.

Ещё в комментариях можно типы переменных писать (как в старом JS или во Flow, только без запуска тайпчекера Flow). Можно даже имена там писать, как в ассемблере!

mov ecx, [ebx] ; в cx счётчик цикла

В java принудительно нужно указывать в сигнатуре, какие эксепшены можешь кинуть.

Да, checked exceptions — самая близкая из упомянутых вами вещей к Either. Правда, костыльная, без полиморфизма по экзепшонам, и так далее, поэтому на практике малоюзабельная.

Всмысле перевести? Мне функцию дали. По условию. Где сигнатура?

А тут вам в условии дали фору: сигнатуру можете выбрать как вам удобнее.

Если по своему, то во-первых, возвращение NetworkError - чушь собачья. При живых эксепшенах.

Это чтобы потом вместо того, чтоб просто посмотреть на тип функции, ходить спрашивать «а что функция кидает?», как вы уже сделали выше?

Но, впрочем, я и про это написал! Во:

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

Во-вторых, запрос коммента по сети по одному - чушь собачья.

Вы реально по кругу ходите. Мы с вами это уже обсудили.

Например ошибка кредов - вот зачем дальше выбирать эти комменты?

Вы точно не понимаете, что такое модельная задача.

Решите уже эту, наконец, и обсудим границы применимости, усложнения и прочее.

Никак. Это не хаскель.

ФП что-то быстро сдулось. А аналог уже даже в плюсы завезли в виде std::expected.

И шарп статически типизированный. Там нельзя инт поменять на коммент.

Ну хаскель-то известен своей динамической типизацией, конечно.

В данном случае это значит «вернуть такое же по форме дерево, но в котором на данной позиции вместо инта лежит соответствующий этому инту комментарий». Сорян за функциональный жаргон.

Информация

В рейтинге
1 553-й
Зарегистрирован
Активность