Эм, простите, а вы нарочно взяли малое кол-во элементов childs? Просто если их увеличивать, то производительность резко падает вниз. Причем на большом кол-ве элементов, как вы и хотели, где это важно.
И возвращаясь к читаемости кода, вы 3 раза так или иначе правили функцию, но который раз оставляете
if (!childIds.includes(child.Id)) continue;
Из-за которой, у вашего решения производительность ЗНАЧИТЕЛЬНО хуже на большом кол-ве данных чем у "freakSolution", о которых вы говорили. Причем опять же, из-за большого кол-ва визуального шума, эта деталь сразу в глаза может и не броситься.
На фактической реализации языка. Если вдруг в хроме по любой причине так произойдет, что JS будет вести себя не по стандарту ECMA, он не перестанет быть JS. Собственно как и нарушающее стандарт поведение CSS в WebKit, автоматически не значит, что там другой язык.
Неожиданное возвращение к теме, мне стало интересно сможет ли оптимизировать данный код js рантайм bun, и насколько он по скорости сравняется с первой версией данной функции.
По итогу, первая функция не соответствует второй, тк в итоговом результате должно быть поле Group, что не выполняется в первом варианте. Мало говорящая деталь, но забавная учитывая тезис о том, что данный код легче читать и рефакторить.
Но забавней оказался факт, что функция которая заявляется как самая медленная, работает быстрее, чем та что заявляется оптимизированной. Я использовал библиотеку benny для замеров, так и онлайн сервисы. И везде вариант функции flatMap, filter и groupBy оказывался быстрее.
Тесты делал на ноутбуке с процессором Intel(R) Core(TM) i5-6200U и 16гб оперативной памяти
Сейчас - частично предпринимателю, частично владельцам? частично рабочим
Прошу прощения, но с каких пор эта часть начала распределяться рабочим? Рабочие как получали фиксированную зп (в большинстве своем). Опять же, доход предприятий при СССР це то что осталось уже за вычетом ЗП сотрудникам. Тч ваша фраза звучит как оксюморон.
все эти группы в результате могут купить себе дома
Не все. Ну те буквально, есть огромный пласт рабочих людей, которые не могут себе позволить купить квартиру, и это касается не только Постсовка.
Но зато не может купить дом рабочий говновыпускающего завода, который на работу даже отмечаться не ходит и отношения к доходам не имеет. Мне кажется сейчас справедливей.
Так может, аналоги подобных людей работают в крупных фирмах, и могут там буквально сидеть и ничего не делать за высокие ЗП. Опять же, таких историй на хабре много. Причем самое забавное, что при этом люди на более низкооплачиваемых работах квартиру себе позволить в отличии от них не могут, хотя трудятся явно не меньше.
Прошу прощения, какая часть налога шла на постройку домов в СССР? Просто спойлер, в основном средства брались не с налогов рабочих, а с доходов/налогов(как хотите называйте) предприятий.
Ну ради справедливости иммутабельное изменение поля в ЖС без линз выглядит реально не приятно, и требует больших когнитивных усилий чтоб понять, что там происходит.
Ну да, нужно определить уровень знаний, чтобы понимать какие таски может закрывать кандидат. Иль как вы хотите узнавать это? Путем проб и ошибок, которые в копеечку влетят компании?
Пригодность языка, в широком понимании (да и любой технологии) - это способность принести business value
Так компании которые берут деньги с конечного пользователя за ОС, как раз внедряют раст в ядро см Windows. Проблемы как раз с опенсорс проектами, ибо там все строится не на том что приносит наибольшее "business value".
Что конкретно там write-only? Типы? Просто они описывают и гарантируют то, что возвращает функция и их не поддерживать надо, а соблюдать. Разница с Си тут в том, что разработчики свойства типов которые тут прописаны явно, держат в голове и компилятор их не проверяет.
И кстати, еще одно преимущество синтаксиса Go - в том, что в нем лямбда-функции объявляются в точности также как и "обычные.
Что делает из го просто месиво при использовании лямбд, тк куча визуального шума который тебе не нужен. В случае C# имеешь короткий понятный синтаксис, который мало с чем спутаешь.
Зачем мне в го лямбде писать типы, когда функция в которую я передаю эту самую лямбду уже объявила типы? Это просто двойная работа, которая создает визуальный шум.
А вот что действительно рак мозга и паскальная живопись - так это мусорные стрелочки и двоеточия при объявлении функций и переменных, которые выполняют чисто декоративную роль и визуально засоряют код.
В некоторых языках, це частично способ отделить принимаемые значения от возвращаемых, тк в таких языках запись по типу (value1: i32, value2: i32), может являться вполне себе валидный кодом.
В скала это нужно, тк там с помощью этого записывают каррирование функции
Хотя в целом вкусовщина, и вопросов бы не возникало, если бы вы до этого не приводили в пример го как образец, где буквально такая же проблема, когда нужно делать полную декларацию всех типов принимаемых и возвращаемых значений в любом случае.
Прошу прощения, но машина даже если сломается, останется вашей. Как и мертвое тело лошади. Если принять это во внимание, то аргументы вашего оппонента выглядят значительно хуже.
А второй как? Снизу вверх и обрабатывает данные не по очереди, а в хаотичном порядке?))
Вы наверное имели ввиду первый. Если так, то да, он буквально перепрыгивает в начало цикла пока итерируется по данным, тч да исполнение тут не сверху вниз. Кроме того есть еще ключевое слово continue, которое так же заставляет сделать переход в начало цикла. И из-за всего этого опять же, я не могу знать на каждой строчке кода какое состояние имеют данные. Я только знаю, что цикл еще не окончен. Все. Из-за этого с этим кодом дальше и работать будет сложнее, но это уже тема отдельная.
хоспадя, ещё как назовете простую вещь чтобы она казалась сложнее?)
Ну так они из-за этого становится сложнее, тк надо держать доп условия выполнения в голове.
Кошмар, мы мутировали данные! Такой говнокод точно нельзя писать!
Я не давал оценку "можно"/"нельзя" к коду, ну и опять же, вы вырезаете из контекста. Сама мутация не ведет к усложнению, но когда у нас есть участок нелинейного кода который множество раз исполняется, то это уже будет усложнять чтение кода. Опять же, спор не о том сложный или легкий код для чтения, а какой код легче читать. Это разные темы.
Как насчет того, мутация данных удобнее, намного быстрее и намного меньше оперативной памяти съедает? Или это всё не важно, важна типичная мнимая отмазка
Во-первых, вы уже выдумываете темы, мы не спорили какой код лучше, мы спорили какой код лучше читается. Ну и то что мутация удобней крайне спорная тема, я описал почему в данном случае это усложняет чтение.
Ну пожалуй если ты вообще не в адеквате и не ведаешь что делаешь, то да, но этот "довод" в 99.9999% не состоятельный.
Этот тезис не относится конечно к теме спора, но это литерали "чтобы не совершать ошибки, не совершай ошибки".
Да так, за 12 лет перевидал огромное кол-во проектов и разработчиков и знаю какой код для большинства людей быстрее и лучше воспринимается(кроме индивидуумов конечно).
Нет, вы знаете какой код воспринимается легче в вашем окружении(и то даже это под вопросом). А ваше окружение дай бог 1% от всех разработчиков пишущих на этом языке.
И не забывайте, вариант 1 и вариант 2, это варианты очень простой логики, когда речь заходит о реальной логике которая посложнее чем 2 + 2,
Ну вот тогда и давайте примеры посложнее. Правда даже в данном случае, при модификации первого варианта шанс допустить ошибку больше, банально из-за нелинейности обработки данных.
т.к. это тоже элементарный пример, но он всё равно значительно медленнее императивного аналога и жрёт памяти сильно больше, и когда мы оперируем исключительно очень малым объемом данных, то разницы нет, я предпочти например для такого кейса вариант с map => filter, т.к. читаемость не страдает, а экономия на ресурсах тут мизенрая, но если данных не мало и весь код соткан из такой функиональной фигни(я имею ввиду не этот детский сад аля map => filter, а конкретные такие цепочки), то суммарно приложение начинает тормозить и есть оперативку как не в себя
Я искренни рад, что вы думаете о производительности. Но спор был о другом.
Увы, вы её не достигли. Если быть максимально честным, то как минимум >90% людей поймут значительно быстрее что делает вот этот код
А откуда у вас статистика? Мне лично читать второй вариант значительно легче, чем первый. Как минимум, из названия функций я сразу понимаю, что они делают, в то время как цикл for не дает мне такой информации, пока я не загляну в тело. Кроме того, второй вариант кода просто идет сверху вниз, обрабатывая данные по очереди, в то время как первый имеет условия, которые влияют на поток исполнения и мутирует данные.
Эм, простите, а вы нарочно взяли малое кол-во элементов childs? Просто если их увеличивать, то производительность резко падает вниз. Причем на большом кол-ве элементов, как вы и хотели, где это важно.
И возвращаясь к читаемости кода, вы 3 раза так или иначе правили функцию, но который раз оставляете
Из-за которой, у вашего решения производительность ЗНАЧИТЕЛЬНО хуже на большом кол-ве данных чем у "freakSolution", о которых вы говорили.
Причем опять же, из-за большого кол-ва визуального шума, эта деталь сразу в глаза может и не броситься.
https://stackblitz.com/edit/vitejs-vite-duy2xi?file=main.js&terminal=dev
На фактической реализации языка. Если вдруг в хроме по любой причине так произойдет, что JS будет вести себя не по стандарту ECMA, он не перестанет быть JS. Собственно как и нарушающее стандарт поведение CSS в WebKit, автоматически не значит, что там другой язык.
Неожиданное возвращение к теме, мне стало интересно сможет ли оптимизировать данный код js рантайм bun, и насколько он по скорости сравняется с первой версией данной функции.
По итогу, первая функция не соответствует второй, тк в итоговом результате должно быть поле Group, что не выполняется в первом варианте. Мало говорящая деталь, но забавная учитывая тезис о том, что данный код легче читать и рефакторить.
Но забавней оказался факт, что функция которая заявляется как самая медленная, работает быстрее, чем та что заявляется оптимизированной.
Я использовал библиотеку benny для замеров, так и онлайн сервисы. И везде вариант функции flatMap, filter и groupBy оказывался быстрее.
Тесты делал на ноутбуке с процессором Intel(R) Core(TM) i5-6200U и 16гб оперативной памяти
В TS статическая типизация, мне было бы интересно услышать аргументы против этого.
Простите, то что у вас есть весомый возраст должно дать вам поблажку по сравнению с другими, как и опыт сам собой гарантирует ваши знания.
Прошу прощения, но с каких пор эта часть начала распределяться рабочим? Рабочие как получали фиксированную зп (в большинстве своем). Опять же, доход предприятий при СССР це то что осталось уже за вычетом ЗП сотрудникам. Тч ваша фраза звучит как оксюморон.
Не все. Ну те буквально, есть огромный пласт рабочих людей, которые не могут себе позволить купить квартиру, и это касается не только Постсовка.
Так может, аналоги подобных людей работают в крупных фирмах, и могут там буквально сидеть и ничего не делать за высокие ЗП. Опять же, таких историй на хабре много. Причем самое забавное, что при этом люди на более низкооплачиваемых работах квартиру себе позволить в отличии от них не могут, хотя трудятся явно не меньше.
Так этот доход сейчас уходит предпринимателю, а тогда частично шел на дома рабочим, тч разница значительная.
Прошу прощения, какая часть налога шла на постройку домов в СССР? Просто спойлер, в основном средства брались не с налогов рабочих, а с доходов/налогов(как хотите называйте) предприятий.
Забавно это читать от человека, у которого сгорела жопа от самого факта, что ему задают вопрос по SQL.
Ну ради справедливости иммутабельное изменение поля в ЖС без линз выглядит реально не приятно, и требует больших когнитивных усилий чтоб понять, что там происходит.
Ну да, нужно определить уровень знаний, чтобы понимать какие таски может закрывать кандидат. Иль как вы хотите узнавать это? Путем проб и ошибок, которые в копеечку влетят компании?
Я знаю человека, который за 3.5 года коммерческого опыта(и еще кучу времени на самообучение) вышел не в тимлиды но в сеньоры.
Так компании которые берут деньги с конечного пользователя за ОС, как раз внедряют раст в ядро см Windows. Проблемы как раз с опенсорс проектами, ибо там все строится не на том что приносит наибольшее "business value".
Если уж приводить примеры ужаса, то можно ссылку на макрос скинуть.
Что конкретно там write-only? Типы? Просто они описывают и гарантируют то, что возвращает функция и их не поддерживать надо, а соблюдать. Разница с Си тут в том, что разработчики свойства типов которые тут прописаны явно, держат в голове и компилятор их не проверяет.
Что делает из го просто месиво при использовании лямбд, тк куча визуального шума который тебе не нужен. В случае C# имеешь короткий понятный синтаксис, который мало с чем спутаешь.
Зачем мне в го лямбде писать типы, когда функция в которую я передаю эту самую лямбду уже объявила типы? Это просто двойная работа, которая создает визуальный шум.
В некоторых языках, це частично способ отделить принимаемые значения от возвращаемых, тк в таких языках запись по типу (value1: i32, value2: i32), может являться вполне себе валидный кодом.
В скала это нужно, тк там с помощью этого записывают каррирование функции
Хотя в целом вкусовщина, и вопросов бы не возникало, если бы вы до этого не приводили в пример го как образец, где буквально такая же проблема, когда нужно делать полную декларацию всех типов принимаемых и возвращаемых значений в любом случае.
Можете подтвердить статистикой?
Прошу прощения, но машина даже если сломается, останется вашей. Как и мертвое тело лошади. Если принять это во внимание, то аргументы вашего оппонента выглядят значительно хуже.
Вы наверное имели ввиду первый. Если так, то да, он буквально перепрыгивает в начало цикла пока итерируется по данным, тч да исполнение тут не сверху вниз. Кроме того есть еще ключевое слово continue, которое так же заставляет сделать переход в начало цикла. И из-за всего этого опять же, я не могу знать на каждой строчке кода какое состояние имеют данные. Я только знаю, что цикл еще не окончен. Все. Из-за этого с этим кодом дальше и работать будет сложнее, но это уже тема отдельная.
Ну так они из-за этого становится сложнее, тк надо держать доп условия выполнения в голове.
Я не давал оценку "можно"/"нельзя" к коду, ну и опять же, вы вырезаете из контекста. Сама мутация не ведет к усложнению, но когда у нас есть участок нелинейного кода который множество раз исполняется, то это уже будет усложнять чтение кода. Опять же, спор не о том сложный или легкий код для чтения, а какой код легче читать. Это разные темы.
Во-первых, вы уже выдумываете темы, мы не спорили какой код лучше, мы спорили какой код лучше читается. Ну и то что мутация удобней крайне спорная тема, я описал почему в данном случае это усложняет чтение.
Этот тезис не относится конечно к теме спора, но это литерали "чтобы не совершать ошибки, не совершай ошибки".
Нет, вы знаете какой код воспринимается легче в вашем окружении(и то даже это под вопросом). А ваше окружение дай бог 1% от всех разработчиков пишущих на этом языке.
Ну вот тогда и давайте примеры посложнее. Правда даже в данном случае, при модификации первого варианта шанс допустить ошибку больше, банально из-за нелинейности обработки данных.
Я искренни рад, что вы думаете о производительности. Но спор был о другом.
А откуда у вас статистика? Мне лично читать второй вариант значительно легче, чем первый. Как минимум, из названия функций я сразу понимаю, что они делают, в то время как цикл for не дает мне такой информации, пока я не загляну в тело. Кроме того, второй вариант кода просто идет сверху вниз, обрабатывая данные по очереди, в то время как первый имеет условия, которые влияют на поток исполнения и мутирует данные.