И скажите, какой апи для получения комментов. И для вывода ошибок. Что это будет, вьюмодель, джсон или ещё что?
Если это какой-то бекенд, то давайте сначала ПОЛНЫЙ текст на хаскеле обработки апи. Вместе с загрузкой дерева, вместе с отправкой комментов. Вместе с сериализацией. А потом будем сравнивать именно полный текст.
У вас полная свобода, делайте как вам удобнее.
Я так и сделал. В чём проблема? Вы даже не потрудились сказать, где может ошибка возникнуть.
Всё ваше недовольство - это то, что сделано не по-вашему. Так по вашему и не надо. Надо, чтобы работало.
У меня есть, допустим, репозиторий, который вам очень сложно будет повторить. Потому что там нет места функциональщине. Там выключен Нейгл и включено на максимум байтоёбство. И даже если получится, в 1800 строк вы на хаскеле ну никак не уложитесь. Это не его.
Да, ещё раз скажу. 5000 строк - это даже не маленький проект. Это крохотный. Не надо говорить, что хаскель компактный. Это не так.
Мы с вами не сработаемся. Спасибо за уделённое время, можете не перезванивать.
Если серьёзно, то да, бывает что нужно так. Только вы забываете про одну мааааленькую деталь. Когда я работаю над проектом, я работаю на шарпе. И у меня нет деревьев хаскеля. У меня всё другое. И просить сделать c# метод по хаскель дереву - в высшей степени некорректно.
Выкинуть половину условия задачи и говорить, что сделали это специально
У вас условие притянуто за уши к функциональщине. Ошибки так не ловятся. Сове больно и обидно. Вы хотите что-то поймать, но сами не знаете, что и зачем.
Если надо задачку решить шарпом - не сомневайтесь, я её смогу решить. Надо насобирать либо коммент, либо почему айди коммента нет? Да не вопрос. Ещё пара строк. Всё равно меньше по строкам будет, чем у вас.
Где вы этот запрос делаете, кстати — не видно.
А давайте теперь поговорим о том, что у вас тоже нихрена не видно. Ни куда ошибки уходят, ни как они парсятся, ни как идёт запрос в базе. Тоже очень дохрена условностей.
У меня стандартный апи к Entity Framework, если что. Довольно узнаваемый.
Итого ошибки вы не обрабатываете, древообразную структуру комментариев потеряли, и, судя по форме запроса, потеряли даже порядок комментариев.
Можете всё-таки написать одну функцию целиком, которая это всё делает?
Ничего подобного. Структура на месте, ошибки наверху ловятся. Функция ради функции - ну определитесь с границами. Я не пойму, чего вы хотите. Доказать, что хаскель компактнее шарпа? Ну это, мягко говоря не так.
И я вам скажу, что ваш код нихрена не делает. Вы не разворачиваете дерево, вы не парсите ошибки, вы не запрашиваете комменты. А почему? Потому что я обвязки этого кода не вижу.
неверно, потому что код, который я вам покажу, когда вы всё-таки сделаете плюс-минус что-то, соответствующее предложенной задачке, будет иметь меньше строк, чем у вас уже написано.
Код делает больше, чем вы просили. Просто вы не можете его вставить в свою любимую парадигму. Он там работать не будет.
Проблема большого проекта зависит от большого проекта. Где-то это производительность, где-то надежность, где-то скорость разработки. Пользователю плевать сколько когнитивных усилий Вам нужно приложить чтобы добавить фичу или решить баг, это исключительно Ваша проблема.
Проблема большого проекта - в том, что он большой. Его тупо трудно удержать в голове и всё сложнее править. Пользователя в вопросах архитектуры никто спрашивать не будет. То, что это моя проблема - я хорошо знаю без ваших подсказок.
Собственно, я эту проблему и решаю. Для себя. И для меня хорошо себя зарекомендовали инструменты ООП, которыми я умею пользоваться и они мне приносят пользу.
ОРМ это костыль
Не костыль, а инструмент. Для связывания, да. Очень много разрабов считают, что в ООП работать проще, чем с плоскими данными. И я к ним тоже отношусь. И если вы предпочитаете кидаться чистым sql и выгребать каждый раз свой набор полей, то у меня в ORM синтаксис намного короче и я оперирую объектами, а не полями, что уже на одну абстракцию выше. Кроме того, у меня есть возможность одним кликом узнать, в каких частях проекта используется вот это поле.
За деревьями леса не видно?
А давайте нормально разговаривать? Без обвинений в недальновидности
Преимущество парадигмы в том что без нее не будет работать подходы основанные на этой парадигме?
А кто мне только что ставил в упрёк, что современные системы - это анемичная модель, а не ООП?
Окей, моё любимое упражнение. У вас есть дерево с интами и функция, которая по инту-айдишнику загружает по сети, скажем, комментарий с этим айди (ну или возвращает ошибку). Можете написать код на шарпе, который проходит по дереву, загружает эти комментарии, и либо собирает все ошибки (если была хотя бы одна), либо отдаёт дерево комментариев?
Оу. У нас хвостовая рекурсия и discrimination unit, судя по всему. Ну чтож, давайте сравнивать шарп с хаскелем на поле хаскеля. Я точно также сделаю, выборку айдишников отдельно, запрос отдельно.
Можно и одной строкой развернуть дерево. Вроде этого:
Просто чтобы можно было с любого уровня разобрать дерево.
Потом запрос:
var comments = context.Comments.Where(
c => node.AllChildIds.Contains(c.id))
Может чуть-чуть больше букв. Но в шарпе даже меньше строк. И для меня синтаксис хаскеля выглядит типичной ФП-сплющенной чёрной магией, где за смысл отвечают знаки препинания, а не слова. Это как раз то, что я не люблю в ФП. То, что мне не понравилось в котлине. То, за что я ненавижу регулярки. Оно на мой вкус не читается вообще. В шарпе - читается. В хаскеле - нет.
И да, я специально не стал отлавливать ошибки. Я знаю, что такое DU. Но ошибки надо понимать, где могут возникнуть. У меня запрос комментов идёт одним селектом в "IN" синтаксисе, он либо весь сработает, либо вообще не сработает. В дереве ошибок быть не может.
В шарпе я постоянно пользуюсь такими вещами, как Sum(i => vec[i]), Select/SelectMany, цепочки функций и другие элементы ФП. Так что в данном случае шарп с хаскелем будет 1:1. А вот специфичные для шарпа ситуации могут быть совсем не в пользу хаскеля. C# - очень насыщенный язык с огромным количеством синтаксического сахара, с ним мало кто может тягаться по выразительности и краткости. Не только лишь все это могут.
На C++ — маленький. На хаскеле — средний.
Мне это напоминает заявление представителя эппла, что их 8гб это как 16гб на "обычных" компьютерах. Настолько же голословное. У крестов есть мощная система шаблонов и если по шаблонам упороться, можно оставить любой фп язык позади без вариантов вообще. Я имею в виду по плотности смысла на строку кода.
Это хорошо, когда разработчики придерживаются старого правила "писать компилятор на компилируемом языке". Это как старая добрая традиция ставить архитектора под мост во время приёмки. Только это скорее необходимый минимум, proof-of-concept, чем пример реального проекта.
например, был у меня один проект на хаскеле, пять тыщ строк, написан в одиночку по большому счёту. Если бы я его переписал на C++, то там было бы по моим оценкам примерно на порядок больше
И что, это хорошо? Я могу сказать, в каком случае это хорошо. Когда в одном языке меньше бойлерплейт конструкций, чем в другом. А когда количество строчек сокращается за счёт повышения когнитивного порога восприятия кода - это плохо. Очень плохо.
Считать ли это «большим» [для одного разработчика] проектом? 50 тыщ строк
Во-первых это совершенно условные 50 тыс строк, которые вы вывели исходя из придуманного коэффициента. Вот передо мной проект ormfactory, который я пишу в одно лицо. Там 36kloc самого аппа, 6kloc тестов, 5 сайта, и ещё оракловый коннектор с бриджем ещё 5к. Питоногенераторы, батнички и доки я даже не считаю. Там ещё тулзы вспомогательные есть. 50 должно набраться. А это C#, который мультипарадигменный, и функциональщину там я не стесняюсь использовать, так что коэффициент 10 тут будет точно мимо.
Когда я писал erp-систему в течении 12 лет (не один), то там набралось более 200kloc. Вот это средне-большой проект. 50 - средний. А 5к - маленький, как ни крути.
На минуточку, проблема больших проектов вовсе не там, где вы их ищете. Вовсе не в быстродействии. А именно в своей сложности, в том, что нужно потратить очень много когнитивных усилий, чтобы понять, что откуда растёт и как нужно покрутить, чтобы поправить баг и не получить ещё новых десять.
Я не отрицаю, что бывают проблемы быстродействия, которые надо решать. Только они, как правило, затрагивают ну никак не больше 1% кода. Я так, навскидку. Бывает, что 0,1% кода выполняется 99% времени. Про микросервисы, где 80% времени и цпу уходит на сериализацию и ио, я не говорю. Ни к какому чёрту ООП не идёт. Как правило оптимизируется небольшая часть кода, которая тормозит. Без выхода из парадигмы. Напомню, что большинство игр написано на C++. Возможно, с привлечением низкоуровневых кусков сей или там ассемблера, но не факт.
Сюда же зачем-то примешали ОРМ, который тоже, блин, инструмент. И тоже для снижения когнитивной сложности проекта. И тоже в подавляющем большинстве случаев не является бутылочным горлышком для быстродействия.
ООП даёт инструменты абстракции. Без которых не будет работать DDD и анемичная модель тоже. Кстати, про то, что в большинстве больших проектов анемичная модель - это очень громкое заявление.
О том, что мейнстримовые языки становятся мультипарадигменными, я спорить не буду. Только по прежнему в проде я не вижу больших проектов на чисто фп, вроде F#/scala/haskell.
Давайте я. ООП - это в первую очередь инструмент. Инструмент управления сложностью. Его парадигма - скрытие деталей от тех кусков кода, которым это не надо знать. Если им пользоваться, то гораздо проще потом ориентироваться в своих же собственных абстракциях, тупо скоп меньше и понятнее.
По моему опыту все большие проекты написаны на ООП. Даже линукс, который на С и тот использует ООП-приёмы, когда в структурах пишутся колбеки на функции для этой структуры. А вот ФП-шных проектов, достаточно больших, я что-то не припомню.
Я, как древний программист, больше люблю читаемость. А вы предлагаете заменить неплохо читаемый OR на селект с тремя подзапросами. Под предлогом того, что у вас это сработало. Так это может и сработало, только на ВАШЕЙ базе, с вашей версией БД и с вашим тюнингом. И с вашими сценариями. Может внезапно так оказаться, что это database-specific поведение и в качестве общего совета ваш совет - так себе. То, что совет так себе с точки зрения поддержки кода - я уже не сомневаюсь.
Неправильно. Давайте ещё раз
Полный формат функции. Что принимает, что выдаёт, чем кидается.
Выходной формат, который от меня требуется. В каком виде это передаётся дальше.
Я очень рад, но проект на 5к строк нельзя назвать большим. И средне-большим. И даже средним. Никак.
Нет-нет. Шарпа. Мне же надо на шарпе сделать.
И скажите, какой апи для получения комментов. И для вывода ошибок. Что это будет, вьюмодель, джсон или ещё что?
Если это какой-то бекенд, то давайте сначала ПОЛНЫЙ текст на хаскеле обработки апи. Вместе с загрузкой дерева, вместе с отправкой комментов. Вместе с сериализацией. А потом будем сравнивать именно полный текст.
Я так и сделал. В чём проблема? Вы даже не потрудились сказать, где может ошибка возникнуть.
Всё ваше недовольство - это то, что сделано не по-вашему. Так по вашему и не надо. Надо, чтобы работало.
У меня есть, допустим, репозиторий, который вам очень сложно будет повторить. Потому что там нет места функциональщине. Там выключен Нейгл и включено на максимум байтоёбство. И даже если получится, в 1800 строк вы на хаскеле ну никак не уложитесь. Это не его.
Да, ещё раз скажу. 5000 строк - это даже не маленький проект. Это крохотный. Не надо говорить, что хаскель компактный. Это не так.
Мы с вами не сработаемся. Спасибо за уделённое время, можете не перезванивать.
Если серьёзно, то да, бывает что нужно так. Только вы забываете про одну мааааленькую деталь. Когда я работаю над проектом, я работаю на шарпе. И у меня нет деревьев хаскеля. У меня всё другое. И просить сделать c# метод по хаскель дереву - в высшей степени некорректно.
Давайте структуру шарпа, я сделаю.
А нахрена же вы комментарии по одному грузите? За это даже на собеседованиях на джуна руки отрывают.
У вас условие притянуто за уши к функциональщине. Ошибки так не ловятся. Сове больно и обидно. Вы хотите что-то поймать, но сами не знаете, что и зачем.
Если надо задачку решить шарпом - не сомневайтесь, я её смогу решить. Надо насобирать либо коммент, либо почему айди коммента нет? Да не вопрос. Ещё пара строк. Всё равно меньше по строкам будет, чем у вас.
А давайте теперь поговорим о том, что у вас тоже нихрена не видно. Ни куда ошибки уходят, ни как они парсятся, ни как идёт запрос в базе. Тоже очень дохрена условностей.
У меня стандартный апи к Entity Framework, если что. Довольно узнаваемый.
Ничего подобного. Структура на месте, ошибки наверху ловятся. Функция ради функции - ну определитесь с границами. Я не пойму, чего вы хотите. Доказать, что хаскель компактнее шарпа? Ну это, мягко говоря не так.
И я вам скажу, что ваш код нихрена не делает. Вы не разворачиваете дерево, вы не парсите ошибки, вы не запрашиваете комменты. А почему? Потому что я обвязки этого кода не вижу.
Код делает больше, чем вы просили. Просто вы не можете его вставить в свою любимую парадигму. Он там работать не будет.
Оно не нужно на практике. Если у вас в проекте тысячи крудов и ни одной логики - вы в дурке. Бегите.
Не может.
Вуаля. ООП как раз и предлагает модульность. На уровне классов.
Как ничего не является волшебной таблеткой.
Базы данных мы тоже сами себе придумали.
Это как вообще?
Всмысле? А профит фаундеру? Ну перегорят и перегорят, несите следующего.
Проблема большого проекта - в том, что он большой. Его тупо трудно удержать в голове и всё сложнее править. Пользователя в вопросах архитектуры никто спрашивать не будет. То, что это моя проблема - я хорошо знаю без ваших подсказок.
Собственно, я эту проблему и решаю. Для себя. И для меня хорошо себя зарекомендовали инструменты ООП, которыми я умею пользоваться и они мне приносят пользу.
Не костыль, а инструмент. Для связывания, да. Очень много разрабов считают, что в ООП работать проще, чем с плоскими данными. И я к ним тоже отношусь. И если вы предпочитаете кидаться чистым sql и выгребать каждый раз свой набор полей, то у меня в ORM синтаксис намного короче и я оперирую объектами, а не полями, что уже на одну абстракцию выше. Кроме того, у меня есть возможность одним кликом узнать, в каких частях проекта используется вот это поле.
А давайте нормально разговаривать? Без обвинений в недальновидности
А кто мне только что ставил в упрёк, что современные системы - это анемичная модель, а не ООП?
Оу. У нас хвостовая рекурсия и discrimination unit, судя по всему. Ну чтож, давайте сравнивать шарп с хаскелем на поле хаскеля. Я точно также сделаю, выборку айдишников отдельно, запрос отдельно.
Можно и одной строкой развернуть дерево. Вроде этого:
Только я сделаю рекурсивную проперть в ноде вроде такой:
Просто чтобы можно было с любого уровня разобрать дерево.
Потом запрос:
Может чуть-чуть больше букв. Но в шарпе даже меньше строк. И для меня синтаксис хаскеля выглядит типичной ФП-сплющенной чёрной магией, где за смысл отвечают знаки препинания, а не слова. Это как раз то, что я не люблю в ФП. То, что мне не понравилось в котлине. То, за что я ненавижу регулярки. Оно на мой вкус не читается вообще. В шарпе - читается. В хаскеле - нет.
И да, я специально не стал отлавливать ошибки. Я знаю, что такое DU. Но ошибки надо понимать, где могут возникнуть. У меня запрос комментов идёт одним селектом в "IN" синтаксисе, он либо весь сработает, либо вообще не сработает. В дереве ошибок быть не может.
В шарпе я постоянно пользуюсь такими вещами, как Sum(i => vec[i]), Select/SelectMany, цепочки функций и другие элементы ФП. Так что в данном случае шарп с хаскелем будет 1:1. А вот специфичные для шарпа ситуации могут быть совсем не в пользу хаскеля. C# - очень насыщенный язык с огромным количеством синтаксического сахара, с ним мало кто может тягаться по выразительности и краткости. Не только лишь все это могут.
Мне это напоминает заявление представителя эппла, что их 8гб это как 16гб на "обычных" компьютерах. Настолько же голословное. У крестов есть мощная система шаблонов и если по шаблонам упороться, можно оставить любой фп язык позади без вариантов вообще. Я имею в виду по плотности смысла на строку кода.
Это хорошо, когда разработчики придерживаются старого правила "писать компилятор на компилируемом языке". Это как старая добрая традиция ставить архитектора под мост во время приёмки. Только это скорее необходимый минимум, proof-of-concept, чем пример реального проекта.
И что, это хорошо? Я могу сказать, в каком случае это хорошо. Когда в одном языке меньше бойлерплейт конструкций, чем в другом. А когда количество строчек сокращается за счёт повышения когнитивного порога восприятия кода - это плохо. Очень плохо.
Во-первых это совершенно условные 50 тыс строк, которые вы вывели исходя из придуманного коэффициента. Вот передо мной проект ormfactory, который я пишу в одно лицо. Там 36kloc самого аппа, 6kloc тестов, 5 сайта, и ещё оракловый коннектор с бриджем ещё 5к. Питоногенераторы, батнички и доки я даже не считаю. Там ещё тулзы вспомогательные есть. 50 должно набраться. А это C#, который мультипарадигменный, и функциональщину там я не стесняюсь использовать, так что коэффициент 10 тут будет точно мимо.
Когда я писал erp-систему в течении 12 лет (не один), то там набралось более 200kloc. Вот это средне-большой проект. 50 - средний. А 5к - маленький, как ни крути.
Нет, не странно. Люди делают инкапсуляцию и наследования так, как могут. При отсутствии нормальных конструкций в самом языке.
На минуточку, проблема больших проектов вовсе не там, где вы их ищете. Вовсе не в быстродействии. А именно в своей сложности, в том, что нужно потратить очень много когнитивных усилий, чтобы понять, что откуда растёт и как нужно покрутить, чтобы поправить баг и не получить ещё новых десять.
Я не отрицаю, что бывают проблемы быстродействия, которые надо решать. Только они, как правило, затрагивают ну никак не больше 1% кода. Я так, навскидку. Бывает, что 0,1% кода выполняется 99% времени. Про микросервисы, где 80% времени и цпу уходит на сериализацию и ио, я не говорю. Ни к какому чёрту ООП не идёт. Как правило оптимизируется небольшая часть кода, которая тормозит. Без выхода из парадигмы. Напомню, что большинство игр написано на C++. Возможно, с привлечением низкоуровневых кусков сей или там ассемблера, но не факт.
Сюда же зачем-то примешали ОРМ, который тоже, блин, инструмент. И тоже для снижения когнитивной сложности проекта. И тоже в подавляющем большинстве случаев не является бутылочным горлышком для быстродействия.
ООП даёт инструменты абстракции. Без которых не будет работать DDD и анемичная модель тоже. Кстати, про то, что в большинстве больших проектов анемичная модель - это очень громкое заявление.
О том, что мейнстримовые языки становятся мультипарадигменными, я спорить не буду. Только по прежнему в проде я не вижу больших проектов на чисто фп, вроде F#/scala/haskell.
Давайте я. ООП - это в первую очередь инструмент. Инструмент управления сложностью. Его парадигма - скрытие деталей от тех кусков кода, которым это не надо знать. Если им пользоваться, то гораздо проще потом ориентироваться в своих же собственных абстракциях, тупо скоп меньше и понятнее.
По моему опыту все большие проекты написаны на ООП. Даже линукс, который на С и тот использует ООП-приёмы, когда в структурах пишутся колбеки на функции для этой структуры. А вот ФП-шных проектов, достаточно больших, я что-то не припомню.
Так и почему?
А, вот теперь стало сразу ясно!
Я всё жду, когда же завезут yield return IEnumerable. А то приходится форичами пробрасывать наверх )
Я, как древний программист, больше люблю читаемость. А вы предлагаете заменить неплохо читаемый OR на селект с тремя подзапросами. Под предлогом того, что у вас это сработало. Так это может и сработало, только на ВАШЕЙ базе, с вашей версией БД и с вашим тюнингом. И с вашими сценариями. Может внезапно так оказаться, что это database-specific поведение и в качестве общего совета ваш совет - так себе. То, что совет так себе с точки зрения поддержки кода - я уже не сомневаюсь.
Охлаждение экономики идёт с опережением графика (с)