А как вы там древообразные структуры представляете, что у вас там в стандартной библиотеке для этого есть? (ведь есть же? выразительный же язык, удобный?)
Ну вот так и представьте. У вас полная свобода, делайте как вам удобнее. Только, ну, чтобы дерево, конечно. Я не знаю C# достаточно хорошо (и вообще только читать на нём могу, считайте), чтобы вас ограничивать написанием структуры за вас.
На плюсах я бы предположил, что где-то ещё написано что-то вроде
template<typename V>
struct Tree
{
V value;
std::vector<Tree<V>> children;
};
А в чём минусы? Хотите — работаете в стартапе. Не хотите — работаете в крупной корпорации, четыре часа в день надувая щёки на митингах, ещё два часа ходя за кофе/социализацией/етц, и ещё два что-то вяло кодируя. Хотите чего-то ещё — идёте в такую компанию.
Вы ведь не понимаете, что такое модельная задача, да?
Я уже написал выше, нахрена. Например:
Вам API'шку дали, которая не умеет в запрос всех комментариев сразу, надо долбить по одному.
— и да, такие случаи бывали на практике. Сервис, реализующий апишку, чужой, а вы работаете в крупной копрорации, где добавление батчинга в чужой сервис займёт пару месяцев, а фичу неплохо бы деливерить поскорее. «$lang применим только к академически чистым ситуациям» шутят обычно как раз при $lang ≔ haskell, и получается смешно (метасмешно?), когда таким языком, похоже, оказывается C#.
Или, например:
Это, например, и backtracking-решение систем констрейнтов
где аналога «грузить все комменты сразу» просто нет.
Но вы уже третий комментарий уворачиваетесь от того, чтобы просто написать код на выразительном сишарпе, что, похоже, должно занять у вас меньше пяти минут (а на обсуждение, почему этого делать не надо, вы уже точно потратили больше). Кажется, что-то здесь нечисто!
У меня условие притянуто за уши к реальным задачам, которые приходится решать.
Причём это не только работа с тупыми апишками. Это, например, и backtracking-решение систем констрейнтов, но задачу в терминах апишек поймёт больше людей.
Ошибки так не ловятся. Сове больно и обидно. Вы хотите что-то поймать, но сами не знаете, что и зачем.
Почему не знаю? Знаю! Вон в типе функции написано, что она может дать NetworkError. А у вас в типе функции что написано? А ничего не написано, потому что и функции нет, есть какие-то обрывки кода, демонстрирующие LINQ.
Если надо задачку решить шарпом - не сомневайтесь, я её смогу решить.
Ну так решите уже, наконец, тем более, что по вашим словам это очень просто! Ещё раз на всякий: вам дан тип деревьев из стандартной библиотеки, и у вас есть функция загрузки одного комментария (её Вася написал, не вы), на C# будет выглядеть как-то так, наверное (не знаю, что у вас там вместо Either принято):
Вам нужно написать функцию, которая проходит по дереву интов, пытается все комменты, и либо возвращает дерево, где в узле вместо инта — коммент, либо список ошибок загрузки.
Всё равно меньше по строкам будет, чем у вас.
У меня будет одна строка на тип функции и одна-две строки на реализацию. Всё. У вас уже больше.
Структура на месте, ошибки наверху ловятся.
На каком верху? Где у вас все ошибки собираются в случае, если появляется хотя бы одна? Где это поведение видно в типах?
И я вам скажу, что ваш код нихрена не делает.
Использование в будущем времени слов «код, который я вам покажу» вам ни на что не намекает? Мой код — это условие задачи. Что дано. И парсинг ошибок, например, происходит в функции загрузки комментария.
Я просто не хочу портить своей непонятной функциональщиной ваш чистый сишарп — покажите ваше решение вы, и я потом покажу своё.
Выкинуть половину условия задачи и говорить, что сделали это специально — довольно странный флекс, но окей.
Но ошибки надо понимать, где могут возникнуть.
Они могут возникнуть при сетевом запросе. Где вы этот запрос делаете, кстати — не видно.
У меня запрос комментов идёт одним селектом в "IN" синтаксисе
Нельзя так. Вам API'шку дали, которая не умеет в запрос всех комментариев сразу, надо долбить по одному.
[...] Потом запрос:
Итого ошибки вы не обрабатываете, древообразную структуру комментариев потеряли, и, судя по форме запроса, потеряли даже порядок комментариев.
Можете всё-таки написать одну функцию целиком, которая это всё делает?
И при всём этом
Но в шарпе даже меньше строк.
неверно, потому что код, который я вам покажу, когда вы всё-таки сделаете плюс-минус что-то, соответствующее предложенной задачке, будет иметь меньше строк, чем у вас уже написано.
И для меня синтаксис хаскеля выглядит типичной ФП-сплющенной чёрной магией, где за смысл отвечают знаки препинания, а не слова.
Конечно, куда лучше, когда знаки препинания не отвечают вообще ни за что, зато(везде(понатыканы<(разные<скобочки>)>)), которые не несут вообще никакой смысловой нагрузки и являются просто визуальным шумом. Да и IEnumerable<int> читать куда проще, чем [Int]! Правда, создавать одноэлементный список всё равно приходится через [], но неважно.
Кстати,
У нас хвостовая рекурсия и discrimination unit, судя по всему.
хвостовой рекурсии здесь нет (и при обходе дерева быть не может, кажется, но мне лень это доказывать), а discriminated union из одного конструктора — это просто класс/структура, если в ваших терминах.
Мой исходный тезис был про плюсы, и конкретно этот пример был про то, что во втором случае надо знать, что такое accumulate, но код при этом проще. Но неважно, продолжим.
В шарпе я постоянно пользуюсь такими вещами, как Sum(i => vec[i]), Select/SelectMany, цепочки функций и другие элементы ФП.
Основной элемент ФП последние лет 15-20 — это выразительные типы (и про типы я писал в предыдущем комментарии). Глядя на один лишь тип функции на хаскеле, я знаю сильно больше, что она не может делать (при некоторых естественных дополнительных предположениях), чем в шарпе или в плюсах (а в последних версиях — что она обязана делать). И именно это сильно помогает читать код и поддерживать средние и большие проекты.
Так что в данном случае шарп с хаскелем будет 1:1.
Окей, моё любимое упражнение. У вас есть дерево с интами и функция, которая по инту-айдишнику загружает по сети, скажем, комментарий с этим айди (ну или возвращает ошибку). Можете написать код на шарпе, который проходит по дереву, загружает эти комментарии, и либо собирает все ошибки (если была хотя бы одна), либо отдаёт дерево комментариев?
На хаскеле данное по условию выглядит как
data Tree a = Node
{ value :: a
, children :: [Tree a]
}
loadComment :: Int -> IO (Either NetworkError Comment)
— на C# переведите по вашему усмотрению.
У крестов есть мощная система шаблонов и если по шаблонам упороться, можно оставить любой фп язык позади без вариантов вообще.
Я по шаблонам упарываюсь профессионально за деньги. Так вот, это — унылое костыльное подобие, в зависимости от конкретного применения, одного из:
нормального параметрического полиморфизма (есть в любом современном ФП-языке из ML-семейства)
метапрограммирования а-ля haskell generics или template haskell
попыток считать что-то на типах а-ля type families или зависимые типы в идрисе.
(и именно потому, что это костыльное подобие, за знание шаблонов C++ готовы платить сильно больше — правда, ощущаешь себя при этом экзотической проституткой с широким спектром услуг, не более)
Учитывая особенности плюсов, весь код с темплейтами должен быть в хедерах (если упрощать, опять же — частные случаи явного инстанциирования мы не обсуждаем), что делает их использование для DI или для гарантирования инвариантов запретительным для реальных проектов. Ну или, если очень надо, то одно TU компилируется по несколько минут (что действительно больше, чем ФП-языки, но не по тем метрикам, по которым хотелось бы).
Тайпклассы + type families + GADT'ы оставляют шаблоны далеко позади.
Только это скорее необходимый минимум, proof-of-concept, чем пример реального проекта.
Это уже какие-то апостериорные фильтры по непонятным критериям.
Proof-of-concept — это компилятор идриса на идрисе (потому что он не умеет ничего, по большому счёту, и потому что ему несколько лет, и пилится он автором языка и полутора энтузиастами). А ghc — это проект, которому уже третий десяток лет, в котором под миллион строчек кода, весьма нетривиальный фронтенд/тайпчекер, очень нетривиальный пайплайн оптимизации, и в котором регулярно допиливаются новые (и часто нетривиальные с точки зрения реализации) фичи языка. В моих определениях это каноничный «большой проект».
Когда в одном языке меньше бойлерплейт конструкций, чем в другом.
Бойлерплейта тоже меньше. Компилятор много чего сам выводит, от, не знаю, функций хеширования для нетривиальных типов до беготни по AST целевого языка (мой проект был его компилятором).
А когда количество строчек сокращается за счёт повышения когнитивного порога восприятия кода - это плохо. Очень плохо.
Что лучше,
int sum = 0;
for (int i = 0; i < vec.size(); ++i)
sum += vec[i];
или
const int sum = accumulate(vec, 0);
?
Есть разница между «когнитивным порогом восприятия кода при условии знания идиом языка, которые где-то примерно O(1) с точки зрения сложности изучения от числа проектов» и «когнитивным порогом восприятия кода потому, что код захламлен неважными деталями реализации с неверного уровня абстракции».
И по моему опыту, чем язык чище (в смысле, чем типы у него выразительнее), тем код читать проще. Код на идрисе или агде читать проще, чем на хаскеле, который, в свою очередь, читать проще, чем на окамле, который, в свою очередь, читать проще, чем на плюсах.
Во-первых это совершенно условные 50 тыс строк, которые вы вывели исходя из придуманного коэффициента.
Это основывается на опыте сравнения подобных проектов. Могло бы быть 40 тыщ, могло бы быть 60 — на суть это не влияет на этих масштабах.
50 - средний. А 5к - маленький, как ни крути.
На C++ — маленький. На хаскеле — средний. Потому что предметной сложности в нём будет как в проекте на 50к на плюсах.
Не ожидал увидеть в треде о Scrum и ООП [очередное] обсуждение коммунизма, но [в очередной раз] не могу пройти мимо.
Построенная чисто на рыночных принципах медицина в США
Медицина в США перестала быть чисто рыночной где-то между 1950-ми и 1970-ми (например, те же CON — очень рыночно), и исход немного предсказуем: количество проедающих деньги бюрократов попёрло вверх:
а вместе с проедающими деньги бюрократами попёрли вверх и косты:
При этом государственные траты на медицину растут почти так же, как частные:
При этом куда менее регулируемые частные косметические процедуры растут даже меньше инфляции:
хотя количество одних только косметических операций выросло (с 97-го, раньше статистику найти сложнее) в два раза, а всех вмешательств — в шесть раз.
по вполне объективным показателя построенной на социалистических принципах медицине тех же стран Европы
Не существует объективных показателей, способных сравнить существенно рыночные и существенно нерыночные системы. Вы можете спрашивать, например, «сколько трудового времени нужно потратить человеку из X-перцентиля по доходам для получения такого-то ухода, и как быстро он его получит», и Европа стремится, чтобы для всех X это было примерно одинаковым. Лично мне совершенно неважно, чтобы это было одинаковым, и лично мне важнее, чтобы лично мне услуги были доступны за малое количество моих усилий и быстро.
Про канадский хелскер, где для сокращения костов делают эвтаназию (или там умерших в очередях не считают на государственном уровне — так важно государству заботиться о людях) можно даже не вспоминать.
Но да, зато всем всё бесплатно (почти).
Не, спасибо, я лучше с осознаваемой ответственностью за свою жизнь, и в долгах, но живым. И, собсна, про NHS у меня куча ссылок, выше — так, мелкая выборка, и каждый раз, когда я их читаю, я вспоминаю, что коммунисты — не люди, а желающие власти без всякой ответственности упыри, и вспоминаю некоего
Rafał Gan-Ganowicz
When asked how it felt to take human life, I wouldn't know, I've only killed communists.
Банально тратят в разы больше денег и получают заметно худшие результаты типа продолжительности жизни.
Про деньги я уже написал выше, а про продолжительность жизни — на те же фентаниловые смерти [собственный выбор; сильно положительно коррелирует с социальностью штата] и ожирение [почти всегда собственный выбор] сделали коррекцию? Я коррекцию делал, и учёт одних только фентаниловых смертей резко бампал продолжительность жизни в Штатах на несколько лет.
Есть очень хороший показатель эффективности хелскера: отношение cancer incidence rate и cancer death rate. Вы хотите, чтобы это отношение было выше: тогда больше рака выявляется, и меньше людей от него умирает. И, сюрприз, США и тут впереди (если сравнить с Канадой, Францией и Германией, например) в полтора-два раза:
US: 367 / 181 = 2.03
Germany: 274 / 301 = 0.9
France: 339 / 288 = 1.17
Canada: 345 / 257 = 1.34
Организовывать работу полиции и армии по рыночным принципам по моему не пытается уже никто вообще в мире.
Лучший подход к полиции — это вооружённое население, конечно. Децентрализовано, рыночно, эффективно.
Да и к армии тоже. Попробуйте это в мичети.
Ну и это уже не говоря о том, что рынок без государственного присмотра практически неизбежно скатывается в монополизацию
Нет, конечно, но мой комментарий уже и так слишком длинный.
А вот ФП-шных проектов, достаточно больших, я что-то не припомню.
Компиляторы ФП-языков написаны на ФП-языках, как минимум, а это достаточно простые проекты. Тот же ghc, например.
Заодно отвечу на соседний комментарий:
Только по прежнему в проде я не вижу больших проектов на чисто фп, вроде F#/scala/haskell.
Регулярно видел большие проекты на хаскеле в проде. И сам делал лично в одну морду, и на последней работе, например, очередной компилятор/тайпчекер на хаскеле был написан, и мы даже начали его формально верифицировать на coq (тоже ФП).
Просто есть тут такой один нюанс… например, был у меня один проект на хаскеле, пять тыщ строк, написан в одиночку по большому счёту. Если бы я его переписал на C++, то там было бы по моим оценкам примерно на порядок больше. Считать ли это «большим» [для одного разработчика] проектом? 50 тыщ строк для одного разраба — это уже средне-большое, как по мне.
Я вас упрекаю не в этом. Я вас упрекаю в том, что польза от ваших комментариев в подавляющем большинстве случаев отрицательная, и они хуже шума, потому что ваша цель — это, как у вас в профиле написано, показать себя д'Артаньяном, и даже если никакого повода для этого нет, вы его выдумаете.
А когда шарящие люди вмешиваются в разговоры — это хорошо, и вообще причина использования публичной площадки.
Я смогу рассказать, что нет такого понятия «переродился»
В обсуждаемой статье нет «переродился» (да, я помню, что вам плевать на обсуждение, вы генерируете текст на отдалённо связанную тему).
то есть персонаж с самого начала неаккуратен в формулировках, а исправление каждой ошибки на Хабре превышает мои возможности
Нельзя одновременно требовать от окружающих читать только то, что написано, и не додумывать, но постоянно самому соскакивать на «персонаж неаккуратен в формулировках, на самом деле он имел в виду другое, и мне виднее, что».
Как я уже писал, возможно, что ковид мог дополнительно ослабить организм и тем самым промотировать рак, который до этого успешно сдерживала иммунная система.
Или, возможно, уже имеющийся, но недиагностированный рак оттягивает на себя ресурсы иммунной системы и приводит к симптоматическому, попадающему в статистику (или в госпиталь) ковиду. Норм вариант?
Но точно так же оппонент мог изнасиловать свою одноклассницу (аппарат-то имеется!) — доказательства нужны-с....
И поэтому, когда я написал, что этих доказательств нет, вы начали генерировать текст на отдалённо связанную тему «но аппарат имеется»!
Вообще, конечно, чем глубже я вчитываюсь в эту статью, тем она смешнее.
Например, чуваки пишут, что на фоне ковидной эпидемии уже в январе 2020-го было +8 кейсов относительно бейзлайна. Ужас! Одна проблема: первые кейсы в Италии были в феврале.
Или чуваки приводят этот график:
и говорят, что «серая линия показывает начало серьёзного роста тренда выявляемых случаев». Только, если судить по их же методике (сезонная ARIMA), которую они показывают как «ожидали синенькое, получили чёрненькое», никакого серьёзного тренда нет (и утверждаю, что несерьёзного тоже, но сырых данных прогнать статтесты нет) с января 2020-го. тренд есть только с августа 2021-го (красная линия у них на графике). Щито?
Дальше, я попытался сравнить эти данные с общим числом случаев ковида и его динамикой в Италии, а он начал серьёзно расти через этак 4 месяца после красненькой линии выше (и через пару месяцев после пика после неё):
Дальше, я из интереса попытался найти данные по cancer incidence rate за 2024-й (который они не анализируют) — ведь с таким-то графиком количества ковидных случаев при статистически значимом эффекте влияния ковида это самое incidence rate должно вообще взлететь в небеса в 2024-м! И в процессе поисков я как-то обнаружил, что общий cancer incidence rate по Италии в 2-4 раза меньше того, что они приводят: 370-390 тыщ случаев в год последние пару лет на 59 миллионов человек, что даёт нам ≤6-7 случаев на 1000 человеколет. Чуваки же говорят о доковидном бейзлайне в 14 случаев на 1000 человеколет. Что за фигня? А вот что за фигня:
Inclusion criteria: age >18-year-old; availability of information on cancer history for the 6 years; availability of clinical and demographic data at least for the 3 years before or the 3 years after the start of the COVID-19 outbreak.
For the period 2017–2022, baseline data were available for 239,189 individuals; 26,533 were excluded [...]. Out of the 212,656 participants followed [...]
То есть, у чуваков получилась заведомо нерепрезентативная выборка, они эту нерепрезентативность не объясняют вообще никак (хотя одни даже критерии отбора позволяют нагенерировать несколько гипотез) и даже не упоминают.
tl;dr — чуваки что-то измерили (непонятно что), что-то наавторегрессировали (непонятно что), сделали какие-то выводы (непонятно как относящиеся к их же результатам). Публикации крутятся, гранты мутятся. Правда, меня б за такое даже в качестве домашки на курсе прикладного анализа данных выше трояка бы не оценили, но куда уж мне со свиным рылом в калашный ряд медицинской статистики.
А, и да, судя по беглому гуглу, общие cancer incidence rate по Италии выглядят так (население особо не поменялось, поэтому можно не делить на него):
А это — отсутствие «исключения других возможных объяснений», как я уже писал выше. Статья просто показывает корреляцию (причём в однокогортном исследовании авторегрессией, что очень слабенько), а вы из неё делаете причинно-следственную связь.
Кстати, @Wesha, смогёте тут нам рассказать разницу между «после» и «вследствие», или не, как обычно в таких случаях бывает, когда это не в вашу пользу, вы отсидитесь тихонечко?
Не имею привычки уходить от рассматриваемого вопроса до завершения его рассмотрения (tl;dr: стрелки не переводите)
Вы сделали это в первом же ответе мне.
Но давайте упростим задачу, и я с вами соглашусь. Вы абсолютно правы, ковид может вызывать рак, и любой человек, который умер от рака после ковидной эпидемии, на самом деле умер от ковида, потому что у него ковид переродился в рак. Всё, обсуждение этой ветки зашло в тупик, я с вами согласился.
Следующая ветка: самоизолируемся ли каждый год с октября по март для избегания грипповых смертей (тем более, что грипп тоже может перерождаться в рак)?
А как вы там древообразные структуры представляете, что у вас там в стандартной библиотеке для этого есть? (ведь есть же? выразительный же язык, удобный?)
Ну вот так и представьте. У вас полная свобода, делайте как вам удобнее. Только, ну, чтобы дерево, конечно. Я не знаю C# достаточно хорошо (и вообще только читать на нём могу, считайте), чтобы вас ограничивать написанием структуры за вас.
На плюсах я бы предположил, что где-то ещё написано что-то вроде
а как там на шарпе — я хз.
Хорошо, я тогда за вами займу.
А в чём минусы? Хотите — работаете в стартапе. Не хотите — работаете в крупной корпорации, четыре часа в день надувая щёки на митингах, ещё два часа ходя за кофе/социализацией/етц, и ещё два что-то вяло кодируя. Хотите чего-то ещё — идёте в такую компанию.
Капитализм — это выбор. Не вижу проблем.
Вы ведь не понимаете, что такое модельная задача, да?
Я уже написал выше, нахрена. Например:
— и да, такие случаи бывали на практике. Сервис, реализующий апишку, чужой, а вы работаете в крупной копрорации, где добавление батчинга в чужой сервис займёт пару месяцев, а фичу неплохо бы деливерить поскорее. «$lang применим только к академически чистым ситуациям» шутят обычно как раз при $lang ≔ haskell, и получается смешно (метасмешно?), когда таким языком, похоже, оказывается C#.
Или, например:
где аналога «грузить все комменты сразу» просто нет.
Но вы уже третий комментарий уворачиваетесь от того, чтобы просто написать код на выразительном сишарпе, что, похоже, должно занять у вас меньше пяти минут (а на обсуждение, почему этого делать не надо, вы уже точно потратили больше). Кажется, что-то здесь нечисто!
У меня условие притянуто за уши к реальным задачам, которые приходится решать.
Причём это не только работа с тупыми апишками. Это, например, и backtracking-решение систем констрейнтов, но задачу в терминах апишек поймёт больше людей.
Почему не знаю? Знаю! Вон в типе функции написано, что она может дать
NetworkError. А у вас в типе функции что написано? А ничего не написано, потому что и функции нет, есть какие-то обрывки кода, демонстрирующие LINQ.Ну так решите уже, наконец, тем более, что по вашим словам это очень просто! Ещё раз на всякий: вам дан тип деревьев из стандартной библиотеки, и у вас есть функция загрузки одного комментария (её Вася написал, не вы), на C# будет выглядеть как-то так, наверное (не знаю, что у вас там вместо
Eitherпринято):Вам нужно написать функцию, которая проходит по дереву интов, пытается все комменты, и либо возвращает дерево, где в узле вместо инта — коммент, либо список ошибок загрузки.
У меня будет одна строка на тип функции и одна-две строки на реализацию. Всё. У вас уже больше.
На каком верху? Где у вас все ошибки собираются в случае, если появляется хотя бы одна? Где это поведение видно в типах?
Использование в будущем времени слов «код, который я вам покажу» вам ни на что не намекает? Мой код — это условие задачи. Что дано. И парсинг ошибок, например, происходит в функции загрузки комментария.
Я просто не хочу портить своей непонятной функциональщиной ваш чистый сишарп — покажите ваше решение вы, и я потом покажу своё.
Выкинуть половину условия задачи и говорить, что сделали это специально — довольно странный флекс, но окей.
Они могут возникнуть при сетевом запросе. Где вы этот запрос делаете, кстати — не видно.
Нельзя так. Вам API'шку дали, которая не умеет в запрос всех комментариев сразу, надо долбить по одному.
Итого ошибки вы не обрабатываете, древообразную структуру комментариев потеряли, и, судя по форме запроса, потеряли даже порядок комментариев.
Можете всё-таки написать одну функцию целиком, которая это всё делает?
И при всём этом
неверно, потому что код, который я вам покажу, когда вы всё-таки сделаете плюс-минус что-то, соответствующее предложенной задачке, будет иметь меньше строк, чем у вас уже написано.
Конечно, куда лучше, когда знаки препинания не отвечают вообще ни за что, зато(везде(понатыканы<(разные<скобочки>)>)), которые не несут вообще никакой смысловой нагрузки и являются просто визуальным шумом. Да и
IEnumerable<int>читать куда проще, чем[Int]! Правда, создавать одноэлементный список всё равно приходится через[], но неважно.Кстати,
хвостовой рекурсии здесь нет (и при обходе дерева быть не может, кажется, но мне лень это доказывать), а discriminated union из одного конструктора — это просто класс/структура, если в ваших терминах.
Мой исходный тезис был про плюсы, и конкретно этот пример был про то, что во втором случае надо знать, что такое
accumulate, но код при этом проще. Но неважно, продолжим.Основной элемент ФП последние лет 15-20 — это выразительные типы (и про типы я писал в предыдущем комментарии). Глядя на один лишь тип функции на хаскеле, я знаю сильно больше, что она не может делать (при некоторых естественных дополнительных предположениях), чем в шарпе или в плюсах (а в последних версиях — что она обязана делать). И именно это сильно помогает читать код и поддерживать средние и большие проекты.
Окей, моё любимое упражнение. У вас есть дерево с интами и функция, которая по инту-айдишнику загружает по сети, скажем, комментарий с этим айди (ну или возвращает ошибку). Можете написать код на шарпе, который проходит по дереву, загружает эти комментарии, и либо собирает все ошибки (если была хотя бы одна), либо отдаёт дерево комментариев?
На хаскеле данное по условию выглядит как
— на C# переведите по вашему усмотрению.
Я по шаблонам упарываюсь профессионально за деньги. Так вот, это — унылое костыльное подобие, в зависимости от конкретного применения, одного из:
нормального параметрического полиморфизма (есть в любом современном ФП-языке из ML-семейства)
метапрограммирования а-ля haskell generics или template haskell
попыток считать что-то на типах а-ля type families или зависимые типы в идрисе.
(и именно потому, что это костыльное подобие, за знание шаблонов C++ готовы платить сильно больше — правда, ощущаешь себя при этом экзотической проституткой с широким спектром услуг, не более)
Учитывая особенности плюсов, весь код с темплейтами должен быть в хедерах (если упрощать, опять же — частные случаи явного инстанциирования мы не обсуждаем), что делает их использование для DI или для гарантирования инвариантов запретительным для реальных проектов. Ну или, если очень надо, то одно TU компилируется по несколько минут (что действительно больше, чем ФП-языки, но не по тем метрикам, по которым хотелось бы).
Тайпклассы + type families + GADT'ы оставляют шаблоны далеко позади.
Это уже какие-то апостериорные фильтры по непонятным критериям.
Proof-of-concept — это компилятор идриса на идрисе (потому что он не умеет ничего, по большому счёту, и потому что ему несколько лет, и пилится он автором языка и полутора энтузиастами). А ghc — это проект, которому уже третий десяток лет, в котором под миллион строчек кода, весьма нетривиальный фронтенд/тайпчекер, очень нетривиальный пайплайн оптимизации, и в котором регулярно допиливаются новые (и часто нетривиальные с точки зрения реализации) фичи языка. В моих определениях это каноничный «большой проект».
Бойлерплейта тоже меньше. Компилятор много чего сам выводит, от, не знаю, функций хеширования для нетривиальных типов до беготни по AST целевого языка (мой проект был его компилятором).
Что лучше,
или
?
Есть разница между «когнитивным порогом восприятия кода при условии знания идиом языка, которые где-то примерно O(1) с точки зрения сложности изучения от числа проектов» и «когнитивным порогом восприятия кода потому, что код захламлен неважными деталями реализации с неверного уровня абстракции».
И по моему опыту, чем язык чище (в смысле, чем типы у него выразительнее), тем код читать проще. Код на идрисе или агде читать проще, чем на хаскеле, который, в свою очередь, читать проще, чем на окамле, который, в свою очередь, читать проще, чем на плюсах.
Это основывается на опыте сравнения подобных проектов. Могло бы быть 40 тыщ, могло бы быть 60 — на суть это не влияет на этих масштабах.
На C++ — маленький. На хаскеле — средний. Потому что предметной сложности в нём будет как в проекте на 50к на плюсах.
Не ожидал увидеть в треде о Scrum и ООП [очередное] обсуждение коммунизма, но [в очередной раз] не могу пройти мимо.
Медицина в США перестала быть чисто рыночной где-то между 1950-ми и 1970-ми (например, те же CON — очень рыночно), и исход немного предсказуем: количество проедающих деньги бюрократов попёрло вверх:
а вместе с проедающими деньги бюрократами попёрли вверх и косты:
При этом государственные траты на медицину растут почти так же, как частные:
При этом куда менее регулируемые частные косметические процедуры растут даже меньше инфляции:
хотя количество одних только косметических операций выросло (с 97-го, раньше статистику найти сложнее) в два раза, а всех вмешательств — в шесть раз.
Не существует объективных показателей, способных сравнить существенно рыночные и существенно нерыночные системы. Вы можете спрашивать, например, «сколько трудового времени нужно потратить человеку из X-перцентиля по доходам для получения такого-то ухода, и как быстро он его получит», и Европа стремится, чтобы для всех X это было примерно одинаковым. Лично мне совершенно неважно, чтобы это было одинаковым, и лично мне важнее, чтобы лично мне услуги были доступны за малое количество моих усилий и быстро.
В США они мне так доступны. В Европе — нет. В Европе я за полтора года не дождался очереди на очки. В Европе одна моя родственница умерла от рака, потому что ждала в очереди на обследование полгода и дождалась до неоперабельной стадии (но да, после постановки диагноза ей бесплатно соцработница носила продукты или чё-т такое). В Европе одна моя знакомая по работе стояла в очереди в больницу по ментальным вопросам, простояла два года, больница закрылась, пришлось перейти в другую больницу и стоять в очередь туда заново. В Европе NHS оценит вашу жизнь и решит, нужно ли вам делать операцию или нет. Или вы суициднитесь, пока будете ждать в очереди. Или будете выдирать сами себе зубы. Или г-во решит, что вам лучше умереть, чем собрать деньги себе на лечение заграницей (и взять государственные), и запретит про это рассказывать. Или вы с супругой выберете эвтаназию вместо того, чтобы ждать очереди в NHS. Или NHS решит, что ребёнку не надо ехать в Италию за лечением, хотя там всё готово, и ребёнок просто сдохнет.
Про канадский хелскер, где для сокращения костов делают эвтаназию (или там умерших в очередях не считают на государственном уровне — так важно государству заботиться о людях) можно даже не вспоминать.
Но да, зато всем всё бесплатно (почти).
Не, спасибо, я лучше с осознаваемой ответственностью за свою жизнь, и в долгах, но живым. И, собсна, про NHS у меня куча ссылок, выше — так, мелкая выборка, и каждый раз, когда я их читаю, я вспоминаю, что коммунисты — не люди, а желающие власти без всякой ответственности упыри, и вспоминаю некоего
Rafał Gan-Ganowicz
Про деньги я уже написал выше, а про продолжительность жизни — на те же фентаниловые смерти [собственный выбор; сильно положительно коррелирует с социальностью штата] и ожирение [почти всегда собственный выбор] сделали коррекцию? Я коррекцию делал, и учёт одних только фентаниловых смертей резко бампал продолжительность жизни в Штатах на несколько лет.
Есть очень хороший показатель эффективности хелскера: отношение cancer incidence rate и cancer death rate. Вы хотите, чтобы это отношение было выше: тогда больше рака выявляется, и меньше людей от него умирает. И, сюрприз, США и тут впереди (если сравнить с Канадой, Францией и Германией, например) в полтора-два раза:
US: 367 / 181 = 2.03
Germany: 274 / 301 = 0.9
France: 339 / 288 = 1.17
Canada: 345 / 257 = 1.34
Лучший подход к полиции — это вооружённое население, конечно. Децентрализовано, рыночно, эффективно.
Да и к армии тоже.
Попробуйте это в мичети.Нет, конечно, но мой комментарий уже и так слишком длинный.
Компиляторы ФП-языков написаны на ФП-языках, как минимум, а это достаточно простые проекты. Тот же ghc, например.
Заодно отвечу на соседний комментарий:
Регулярно видел большие проекты на хаскеле в проде. И сам делал лично в одну морду, и на последней работе, например, очередной компилятор/тайпчекер на хаскеле был написан, и мы даже начали его формально верифицировать на coq (тоже ФП).
Просто есть тут такой один нюанс… например, был у меня один проект на хаскеле, пять тыщ строк, написан в одиночку по большому счёту. Если бы я его переписал на C++, то там было бы по моим оценкам примерно на порядок больше. Считать ли это «большим» [для одного разработчика] проектом? 50 тыщ строк для одного разраба — это уже средне-большое, как по мне.
Проблема на вашей стороне: мне знакомые ссылки на вк-видео не присылают.
Значит, первый вариант.
Я пишу «в обсуждаемой статье», вы приводите скриншоты комментариев.
Почему? Вы умственно отсталый, или ориентируетесь, как вы писали, на эмоции умственно отсталых «хомячков», или по каким-то ещё причинам?
Я вас упрекаю не в этом. Я вас упрекаю в том, что польза от ваших комментариев в подавляющем большинстве случаев отрицательная, и они хуже шума, потому что ваша цель — это, как у вас в профиле написано, показать себя д'Артаньяном, и даже если никакого повода для этого нет, вы его выдумаете.
А когда шарящие люди вмешиваются в разговоры — это хорошо, и вообще причина использования публичной площадки.
В обсуждаемой статье нет «переродился» (да, я помню, что вам плевать на обсуждение, вы генерируете текст на отдалённо связанную тему).
Нельзя одновременно требовать от окружающих читать только то, что написано, и не додумывать, но постоянно самому соскакивать на «персонаж неаккуратен в формулировках, на самом деле он имел в виду другое, и мне виднее, что».
Или, возможно, уже имеющийся, но недиагностированный рак оттягивает на себя ресурсы иммунной системы и приводит к симптоматическому, попадающему в статистику (или в госпиталь) ковиду. Норм вариант?
И поэтому, когда я написал, что этих доказательств нет, вы начали генерировать текст на отдалённо связанную тему «но аппарат имеется»!
Логично, ничего не скажешь.
Вообще, конечно, чем глубже я вчитываюсь в эту статью, тем она смешнее.
Например, чуваки пишут, что на фоне ковидной эпидемии уже в январе 2020-го было +8 кейсов относительно бейзлайна. Ужас! Одна проблема: первые кейсы в Италии были в феврале.
Или чуваки приводят этот график:
и говорят, что «серая линия показывает начало серьёзного роста тренда выявляемых случаев». Только, если судить по их же методике (сезонная ARIMA), которую они показывают как «ожидали синенькое, получили чёрненькое», никакого серьёзного тренда нет (и утверждаю, что несерьёзного тоже, но сырых данных прогнать статтесты нет) с января 2020-го. тренд есть только с августа 2021-го (красная линия у них на графике). Щито?
Дальше, я попытался сравнить эти данные с общим числом случаев ковида и его динамикой в Италии, а он начал серьёзно расти через этак 4 месяца после красненькой линии выше (и через пару месяцев после пика после неё):
Дальше, я из интереса попытался найти данные по cancer incidence rate за 2024-й (который они не анализируют) — ведь с таким-то графиком количества ковидных случаев при статистически значимом эффекте влияния ковида это самое incidence rate должно вообще взлететь в небеса в 2024-м! И в процессе поисков я как-то обнаружил, что общий cancer incidence rate по Италии в 2-4 раза меньше того, что они приводят: 370-390 тыщ случаев в год последние пару лет на 59 миллионов человек, что даёт нам ≤6-7 случаев на 1000 человеколет. Чуваки же говорят о доковидном бейзлайне в 14 случаев на 1000 человеколет. Что за фигня? А вот что за фигня:
То есть, у чуваков получилась заведомо нерепрезентативная выборка, они эту нерепрезентативность не объясняют вообще никак (хотя одни даже критерии отбора позволяют нагенерировать несколько гипотез) и даже не упоминают.
tl;dr — чуваки что-то измерили (непонятно что), что-то наавторегрессировали (непонятно что), сделали какие-то выводы (непонятно как относящиеся к их же результатам). Публикации крутятся, гранты мутятся. Правда, меня б за такое даже в качестве домашки на курсе прикладного анализа данных выше трояка бы не оценили, но куда уж мне со свиным рылом в калашный ряд медицинской статистики.
А, и да, судя по беглому гуглу, общие cancer incidence rate по Италии выглядят так (население особо не поменялось, поэтому можно не делить на него):
2020 ↦ 376 тыщ
2021 ↦ не нашёл :'-(
2022 ↦ 392 тыщ
2023 ↦ 396 тыщ
2024 ↦ 390 тыщ
(последние три — https://www.aiom.it/tumori-nel-2024-in-italia-stimati-390-100-nuovi-casi-la-meta-guarira-in-15-anni-46-di-morti-per-cancro-del-polmone-nelle-donne-under-50/ ). Со вашей статьёй это не бьётся вообще никак.
Ну тут уж спорить не буду, вам виднее, конечно, как на эмоциях играть.
Или д'Артаньян!
А это — отсутствие «исключения других возможных объяснений», как я уже писал выше. Статья просто показывает корреляцию (причём в однокогортном исследовании авторегрессией, что очень слабенько), а вы из неё делаете причинно-следственную связь.
Кстати, @Wesha, смогёте тут нам рассказать разницу между «после» и «вследствие», или не, как обычно в таких случаях бывает, когда это не в вашу пользу, вы отсидитесь тихонечко?
Вы сделали это в первом же ответе мне.
Но давайте упростим задачу, и я с вами соглашусь. Вы абсолютно правы, ковид может вызывать рак, и любой человек, который умер от рака после ковидной эпидемии, на самом деле умер от ковида, потому что у него ковид переродился в рак. Всё, обсуждение этой ветки зашло в тупик, я с вами согласился.
Следующая ветка: самоизолируемся ли каждый год с октября по март для избегания грипповых смертей (тем более, что грипп тоже может перерождаться в рак)?
Меня это постоянно останавливает, увы.
Фейковое.
Интереснее тренироваться в своих?