Тут нет противоречий. Код должен быть ПОНЯТЕН даже идиоту, а Rust из-за своих тупых ограничения понять в разы сложнее, чем тот же C++. Rust для программистов-идиотов, к тем, кто код читает и понимает это не относится. Программисты-идиоты с идиотскими ограничениями языка физически не могут сделать код понятным. Куча семантического сахара, решения специфичные только для Rust, из-за которых приходится адаптировать алгоритмы... Даже в статье приводили примеры библиотек, что нарушают принципы Rust но от этого более понятные, удобные и приятные в работе... Если принципы языка вредят принципу "понятен даже для идиотов", то язык плохой.
Да, например в наших довольно больших проектах - сервера для онлайн-игр нет new/delete вообще, работы с буферами тоже нет, соответственно и ссылок почти нет, только локальные.
А проблема есть так же как и можно обжечься кипятком, но никто в здравом уме не запрещает находиться в одной комнате с кипящим чайником.
Страшно то, что это ограничение для тупых... И Rust развивается как раз в сторону отупления программистов. Из-за этого сильно страдают алгоритмы. В этой же статье сказано про двойную вложенную итерацию по одному контейнеру для поиска пересечений, которая уже просто так работать не будет и придётся извращаться.
И дело даже не в изменении, а в хранении двух ссылок на объект в разных местах.
Ну да, это как выкинуть из дома все ножи и вилки чтобы нечайно не воткнуть их себе в глаз :) Для тупых это сделано, нормальные умные программисты и так никогда такого не сделают, плюс sanitizer-ы сразу покажут проблему, или тесты на худой конец... За 29 лет опыта программирования я такой глупости не совершал ни разу, поэтому для меня Rust - язык для идиотов :)
Rust неудобный и некачественный язык. Разработка на нём не уменьшает количество ошибок при увеличении времени разработки раз в 5 и ухудшения читаемости кода.
Тот же современный C++ намного более безопасный, удобный и быстрый во всех смыслах язык. Одно только правило "не больше 1 изменяемой ссылки на объект" - страшная тупость. Для этого правила нет никаких логических и разумных причин. Это как правило "не больше 1 грязной кружки в квартире" И не важно сколько людей хотят пить, 1 или 10 и как удобнее их мыть - по 1 или по 10 за раз.
Даже если вы доказали, что useCallback не ускоряет код, то он ее минимум его и не замедляет… А значит лучше использовать везде на случай каких-либо модификаций.
Питон вообще как язык не очень. Я программирую на всех популярных языках. Отступы в пробелах ужасны в любых языках, кстати, но в питоне пробелами грешат почти все… У меня широкоформатный монитор 37’’ вроде, а ширина пробела не регулируется :)
Писать сайты на питоне - ужас ужасный, питон подходит для задач аналитики и анализа, нейронов, научных вычислений и так далее, но не для веба
Тут и без статического анализатора все очевидно и код просто ужасный везде. Естественно, там есть ошибки. Сам весь такой код уже одна большая ошибка.
Чего стоят только вложенные if, макросы, лучше бы показывали примеры ошибок в красивом идеальном коде. Где кроме найденной ошибки нет ни одной проблемы из разряда «так делать нельзя».
Мне ответит кто‑нибудь? Наставники, алло! - «Уак освободятся, тогда и ответят, жди!»
Я уже третий раз переделываю домашку! Сколько можно? - «Пока не сделаешь нормально, столько и будешь делать, до бесконечности, пока не бросишь или не умрешь!»
Вы всё-равно бросили эту работу, так стоило это всё терпеть? Уважать себя нужно независимо от того «кто платит».
Вы меня, конечно, простите, но любой опытный программист читает любую техническую литературу на английском лучше, чем на русском. Так что этот перевод ориентирован на неопытных как раз, которые предпочтут русский. Я, например, всегда выбираю Английский для технических книг, статей, документации, потому что перевод на русский в 100% случаях корявый..
Кстати да, для designated initializers лучше подходит перевод «именованные инициализаторы», но тут косяк скорее в самом стандарте, в других языках такой тип инициализации называется как раз named initialization.
Нет, я специально ее перед тем как писать комментарий перечитал и как раз почему я ее считаю справочником - последовательность изложения материала как у справочника. Я даже сейчас по подобной книге не эффективно бы язык изучал, имея за плечами 27 лет опыта на C++… Область знаний должна расширяться от одной точки по окружности равномерно, а не сначала чутка теории из самых разных областей языка, потом про ввод/вывод немного, потом циклы и условия - база базовая, но уже 200! страниц! Для новичка!
Берем КОНКРЕТНУЮ программу начального уровня, тот же факториал циклом и факториал рекурсией, кратко про базу по этим темам, пара задач на изменение примера, сложная задача - написать самому что-то, все надо уместить в 20 страниц, потом пример сложнее, где раскрывается чуть больше то, что было в предыдущих страницах + часть нового материала и так далее.
Их можно начать читать выбирая интересные темы и суть как раз в том, что выбираешь главу/раздел, который тебя вот прям сейчас заинтересовал. Не дочитал и стало неинтересно - выбираешь новый. Интерес дает +100% к мотивации и +500% к запоминанию.
Ваша проблема с книгой Лафоре а том, что это справочник, такие книги не читают «просто так», а читают адресно когда выполняют какую-нибудь практическую задачу или когда становится интересной какая-то конкретная тема.
Это как читать словарь Даля. Для простого чтения есть специальные книги, которые не объясняют что такое C++, а рассказывают, например, про типичные ошибки, как делать хорошо а как плохо с примерами и так далее.
Самый простой и действенный способ научиться программировать - открыть сайт с задачами (типа написать расчет факториала и так далее) и делать их. Мне в детстве купили книгу по C++, я открывал окончания разделов - где было примеры и перепечатывал программы в блокноте и пытался их скомпилировать. Диск от книги потерялся :( Я запомнил весь синтаксис языка на раз, под конец я уже не по буквам печатал а писал выражениями. А когда запрещали пользоваться компьютером - зачем-то переписывал код в тетрадку :) В кайф было просто…
Потом старался внести в эти программы какие-то изменения от себя.
Алгоритмов там на 2407 строк C++ кода (расширение для PHP) + 3570 строк кода сам PHP скрипт, функционал - динамическое сравнение групп AB-тестов.
До перевода кода на C++ в расширение этот же функционал рендерил страницу около минуты и потреблял больше 2 ГБ памяти. Сейчас - меньше секунды.
Как можно поменять ваш алгоритм - самое простое - вместо внутреннего цикла берите данные из map-а, а сам внутренний цикл вынесите наружу и поменяйте код на заполнение этого map-а. Получится O(n * log2n), если map будет hash_map, то получится O(n). Осталось придумать что в хэше будет ключом.
Отрисовка должна быть однопроходной в принципе. Все алгоритмы должны быть не в отрисовке, а в формировании данных так, чтобы отрисовка была однопроходной.
Данных не может быть СТОЛЬКО. У меня на миллионах строк на клиенте алгоритмы отрабатывают быстрее секунды, а тут фильтры… O(n^2) - это значит что вы не заморачивались с алгоритмом, я на 100% уверен, что там можно сделать как минимум O(n*log2n) и процентов на 50, что можно и O(n).
Там просто незачем проходить что-то в двух циклах, при этом не используя ни деревья ни хэш-таблицы…
Я могу вам показать тоже внутренний проект, где тоже много фильтров и они тоже пересекаются и даже пользователь сам может создавать свои фильтры на псевдо-SQL языке и они применяются к набору данных в 70 миллионов строк меньше чем за секунду :)
Ничего не тормозит нигде, без всяких шаманств с браузером.
Я за 28 лет опыта уже такого повидал выше крыши, даже похожие алгоритмы с «маппингом» исправлял. Такие проблемы - как минимум повод пересмотреть архитектуру проекта.
P.S.: Про доморощенного программиста - это не оскорбление, а предположение. Или у вас есть профильное математическое образованием знание базы в виде как минимум программы матфака, устройства ПК и опыта разработки на ассемблере и C/C++ и я не прав? Опять же, по характеру «проблемы» и выбранному способу её «решения» я предположил то, что написал.
У вас, блин, какие-то КЛИЕНТСКИЕ расчеты занимают секунду и вас это не беспокоит, но беспокоит когда и что рисовать?? Вот она - проблема доморощенных программистов без базовых знаний.
Всегда поражало как люди, которые ничего, по факту, не понимают в настоящем программировании пишут всякие статьи на тему «как лучше». Основное правило программирования - код должен быть понятен даже идиоту и даже идиоты должны быть способны его поддерживать.
Все эти for_each, как, кстати, и написано в документации должны УЛУЧШАТЬ читаемость кода, а не использоваться только из-за идиоматичности.
Если не улучшают - нафиг. Все примеры высосаны из пальца, рекурсия вообще не рекомендуется по множеству причин.
В реальных рабочих задачах вас любой лид бы заставил все переписывать и не выпендриваться больше. А дублирование кода в Point это нормально вообще? Хоть бы примеры подобрали адекватные.
Тут нет противоречий. Код должен быть ПОНЯТЕН даже идиоту, а Rust из-за своих тупых ограничения понять в разы сложнее, чем тот же C++.
Rust для программистов-идиотов, к тем, кто код читает и понимает это не относится.
Программисты-идиоты с идиотскими ограничениями языка физически не могут сделать код понятным. Куча семантического сахара, решения специфичные только для Rust, из-за которых приходится адаптировать алгоритмы... Даже в статье приводили примеры библиотек, что нарушают принципы Rust но от этого более понятные, удобные и приятные в работе... Если принципы языка вредят принципу "понятен даже для идиотов", то язык плохой.
Ну да, поэтому посмотрите на популярность Haskell... :)
Вы ещё brainfuck приведите как пример :)
Да, например в наших довольно больших проектах - сервера для онлайн-игр нет new/delete вообще, работы с буферами тоже нет, соответственно и ссылок почти нет, только локальные.
А проблема есть так же как и можно обжечься кипятком, но никто в здравом уме не запрещает находиться в одной комнате с кипящим чайником.
Я вам больше скажу, сейчас нет ни одной задачи, которую можно быстрее, красивее и эффективнее решить с помощью Rust нежели с помощью C++26.
Единственный плюс Rust в унификации и каталогизации библиотек.
Страшно то, что это ограничение для тупых... И Rust развивается как раз в сторону отупления программистов. Из-за этого сильно страдают алгоритмы.
В этой же статье сказано про двойную вложенную итерацию по одному контейнеру для поиска пересечений, которая уже просто так работать не будет и придётся извращаться.
И дело даже не в изменении, а в хранении двух ссылок на объект в разных местах.
Ну да, это как выкинуть из дома все ножи и вилки чтобы нечайно не воткнуть их себе в глаз :) Для тупых это сделано, нормальные умные программисты и так никогда такого не сделают, плюс sanitizer-ы сразу покажут проблему, или тесты на худой конец...
За 29 лет опыта программирования я такой глупости не совершал ни разу, поэтому для меня Rust - язык для идиотов :)
Rust неудобный и некачественный язык. Разработка на нём не уменьшает количество ошибок при увеличении времени разработки раз в 5 и ухудшения читаемости кода.
Тот же современный C++ намного более безопасный, удобный и быстрый во всех смыслах язык. Одно только правило "не больше 1 изменяемой ссылки на объект" - страшная тупость. Для этого правила нет никаких логических и разумных причин. Это как правило "не больше 1 грязной кружки в квартире" И не важно сколько людей хотят пить, 1 или 10 и как удобнее их мыть - по 1 или по 10 за раз.
Даже если вы доказали, что useCallback не ускоряет код, то он ее минимум его и не замедляет… А значит лучше использовать везде на случай каких-либо модификаций.
Питон вообще как язык не очень. Я программирую на всех популярных языках. Отступы в пробелах ужасны в любых языках, кстати, но в питоне пробелами грешат почти все… У меня широкоформатный монитор 37’’ вроде, а ширина пробела не регулируется :)
Писать сайты на питоне - ужас ужасный, питон подходит для задач аналитики и анализа, нейронов, научных вычислений и так далее, но не для веба
Тут и без статического анализатора все очевидно и код просто ужасный везде. Естественно, там есть ошибки. Сам весь такой код уже одна большая ошибка.
Чего стоят только вложенные if, макросы, лучше бы показывали примеры ошибок в красивом идеальном коде. Где кроме найденной ошибки нет ни одной проблемы из разряда «так делать нельзя».
Не вижу причин отвечать так, как хотелось бы.
Мне ответит кто‑нибудь? Наставники, алло! - «Уак освободятся, тогда и ответят, жди!»
Я уже третий раз переделываю домашку! Сколько можно? - «Пока не сделаешь нормально, столько и будешь делать, до бесконечности, пока не бросишь или не умрешь!»
Вы всё-равно бросили эту работу, так стоило это всё терпеть? Уважать себя нужно независимо от того «кто платит».
Просто сотрудники Яндекса срать хотели с высокой колокольни на ваши проблемы… :(
Вы меня, конечно, простите, но любой опытный программист читает любую техническую литературу на английском лучше, чем на русском. Так что этот перевод ориентирован на неопытных как раз, которые предпочтут русский. Я, например, всегда выбираю Английский для технических книг, статей, документации, потому что перевод на русский в 100% случаях корявый..
Кстати да, для designated initializers лучше подходит перевод «именованные инициализаторы», но тут косяк скорее в самом стандарте, в других языках такой тип инициализации называется как раз named initialization.
Нет, я специально ее перед тем как писать комментарий перечитал и как раз почему я ее считаю справочником - последовательность изложения материала как у справочника. Я даже сейчас по подобной книге не эффективно бы язык изучал, имея за плечами 27 лет опыта на C++… Область знаний должна расширяться от одной точки по окружности равномерно, а не сначала чутка теории из самых разных областей языка, потом про ввод/вывод немного, потом циклы и условия - база базовая, но уже 200! страниц! Для новичка!
Берем КОНКРЕТНУЮ программу начального уровня, тот же факториал циклом и факториал рекурсией, кратко про базу по этим темам, пара задач на изменение примера, сложная задача - написать самому что-то, все надо уместить в 20 страниц, потом пример сложнее, где раскрывается чуть больше то, что было в предыдущих страницах + часть нового материала и так далее.
Их можно начать читать выбирая интересные темы и суть как раз в том, что выбираешь главу/раздел, который тебя вот прям сейчас заинтересовал. Не дочитал и стало неинтересно - выбираешь новый. Интерес дает +100% к мотивации и +500% к запоминанию.
Ваша проблема с книгой Лафоре а том, что это справочник, такие книги не читают «просто так», а читают адресно когда выполняют какую-нибудь практическую задачу или когда становится интересной какая-то конкретная тема.
Это как читать словарь Даля. Для простого чтения есть специальные книги, которые не объясняют что такое C++, а рассказывают, например, про типичные ошибки, как делать хорошо а как плохо с примерами и так далее.
Самый простой и действенный способ научиться программировать - открыть сайт с задачами (типа написать расчет факториала и так далее) и делать их. Мне в детстве купили книгу по C++, я открывал окончания разделов - где было примеры и перепечатывал программы в блокноте и пытался их скомпилировать. Диск от книги потерялся :( Я запомнил весь синтаксис языка на раз, под конец я уже не по буквам печатал а писал выражениями. А когда запрещали пользоваться компьютером - зачем-то переписывал код в тетрадку :) В кайф было просто…
Потом старался внести в эти программы какие-то изменения от себя.
Алгоритмов там на 2407 строк C++ кода (расширение для PHP) + 3570 строк кода сам PHP скрипт, функционал - динамическое сравнение групп AB-тестов.
До перевода кода на C++ в расширение этот же функционал рендерил страницу около минуты и потреблял больше 2 ГБ памяти. Сейчас - меньше секунды.
Как можно поменять ваш алгоритм - самое простое - вместо внутреннего цикла берите данные из map-а, а сам внутренний цикл вынесите наружу и поменяйте код на заполнение этого map-а. Получится O(n * log2n), если map будет hash_map, то получится O(n). Осталось придумать что в хэше будет ключом.
Отрисовка должна быть однопроходной в принципе. Все алгоритмы должны быть не в отрисовке, а в формировании данных так, чтобы отрисовка была однопроходной.
Данных не может быть СТОЛЬКО. У меня на миллионах строк на клиенте алгоритмы отрабатывают быстрее секунды, а тут фильтры… O(n^2) - это значит что вы не заморачивались с алгоритмом, я на 100% уверен, что там можно сделать как минимум O(n*log2n) и процентов на 50, что можно и O(n).
Там просто незачем проходить что-то в двух циклах, при этом не используя ни деревья ни хэш-таблицы…
Я могу вам показать тоже внутренний проект, где тоже много фильтров и они тоже пересекаются и даже пользователь сам может создавать свои фильтры на псевдо-SQL языке и они применяются к набору данных в 70 миллионов строк меньше чем за секунду :)
Ничего не тормозит нигде, без всяких шаманств с браузером.
Я за 28 лет опыта уже такого повидал выше крыши, даже похожие алгоритмы с «маппингом» исправлял. Такие проблемы - как минимум повод пересмотреть архитектуру проекта.
P.S.: Про доморощенного программиста - это не оскорбление, а предположение. Или у вас есть профильное математическое образованием знание базы в виде как минимум программы матфака, устройства ПК и опыта разработки на ассемблере и C/C++ и я не прав? Опять же, по характеру «проблемы» и выбранному способу её «решения» я предположил то, что написал.
У вас, блин, какие-то КЛИЕНТСКИЕ расчеты занимают секунду и вас это не беспокоит, но беспокоит когда и что рисовать?? Вот она - проблема доморощенных программистов без базовых знаний.
Какой у вас там алгоритм для «расчетов»? O(n^10)?
Всегда поражало как люди, которые ничего, по факту, не понимают в настоящем программировании пишут всякие статьи на тему «как лучше». Основное правило программирования - код должен быть понятен даже идиоту и даже идиоты должны быть способны его поддерживать.
Все эти for_each, как, кстати, и написано в документации должны УЛУЧШАТЬ читаемость кода, а не использоваться только из-за идиоматичности.
Если не улучшают - нафиг. Все примеры высосаны из пальца, рекурсия вообще не рекомендуется по множеству причин.
В реальных рабочих задачах вас любой лид бы заставил все переписывать и не выпендриваться больше. А дублирование кода в Point это нормально вообще? Хоть бы примеры подобрали адекватные.