Нет. Именно про Java. Есть 2 подхода к обобщённым функциям: как на С++ и как на Java. В первом случае во время компиляции генерируются реализации для всех возможных типов, с которым может быть вызвана функция. Каждая вариация оптимизируется отдельно. Но их много, и они все лежат в результирующем бинарнике. На Java же происходит стирание типов. Как следствие виртуальные вызовы гарантированы. Подводя итог: с подходом, как у плюсов или раста, генерируется много кода, но это не приводит к накладным расходам. А на Java-like дженериках приходится платить отсутствием оптимизации и лишними виртуальными вызовами
Может потому что в айти уже не актуально то, что было 10 лет назад и те 20 лет опыта на половину бесполезны? Просто потому что эти 20 лет ты выжимал байтики памяти и наносекунды скорости, а сейчас надо писать поддерживаемый код(что зачастую диаметрально противоположно)
Звучит очень противоречиво. JS явно понятнее среднему человеку, чем очень редкие детали HTLM/CSS. Это сильно бьёт по поддерживаемости. Другой программист может не знать деталей и сделать много косяков или попросту потратить непропорционально много времени.
Пример из поста. Я могу очень логично и элегантно написать решение за квадрат(на вскмдку). Он излишен конкретно для этой задачи, но его потом можно будет переиспользовать в отличие от процедуры, заточенной под супер конкретную задачу. Чтобы оптимизировать решение больше, придётся жертвовать обобщенностью решения т. е. как-то тонко эксплуатировать условия. И чем больше оптимизация, тем больше конкретизация под задачу. Под конкретную сейчас. ТЗ имеет свойство меняться, и придётся всё переписывать с нуля на ровном месте.
Почему это разница в BigO определяет правильность? Отправлю вас на кодфорс. Там все задачи красиво решаются с произвольным О, но если надо максимально быстро, то выйдет что-то страшное. Не дай бог такое писать в продакшене. И написать это поддерживаемо просто невозможно, так как никто не будет понимать твой fast inverse square root. Подводя итог: оптимизация может очень портить код, когда в этом нет никакой необходимости: задача об этом не просит.
Знаете, а я бы не хотела работать у вас… Для вас человек, страдающий преждевременной оптимизацией вместо поддерживаемости кода, предпочтительнее. Задачи написать быстро не стояло. Если писать весь код так, то… мне страшно представить кодовую базу вашу. Не правильнее было бы ожидать поддерживаемый код, а не быстрый?
Да, простого "научного" способа сказать научен ли код нельзя, так же как и с романами, впрочем куда легче сказать, что тот или иной роман плох в некоторой степени. Я писала эту статью с целью сделать общее описание того, что вообще такое "хороший код". Если смотреть на код, как на текст, несущий идеи, то все паттерны проектирования, за которыми можно "фанатично гнаться" становятся лишь инструментами, которые вполне понятно, когда примять.
Следствием гибкости линукса является отсутствие какой-либо упругости. У него просто колоссальная фрагментация, ужасные пакетные менеджеры(они свою задачу на практике моей нормально пока ещё ни разу не решили)(которых столько, сколько пользователей линукс), которыми ты вынужден пользоваться, всё приходтся скачивать их сорцев, блютуз из коробки не работает(на 4 дистрибутивах, которые я пробовала)... и всё это потому что почти нет никакой централизованности. Линукс на столько гибок, что не существует в приемлемом виде.
Конечно, вам покажутся мои доводы смешными, но я даже пыталась со всем разобраться. Я только книжки наверное не читала(на сколько же хороший же линукс продукт, что, чтобы им пользоваться, надо читать целые книги). Я опытнее наверное 90% пользователей ПК. И мне ни для разработки, ни для чего-то другого не хочется возвращаться на линукс. У других осей графический интерфейс не забагован, диски работают нормально, всё работает само из коробки. Зачем мне пользоваться линуксом, если всё можно сделать на винде и это будет быстрее и просто приятнее?
Никогда не использовала recyclerview, поэтому ничего не могу сказать.
Не совсем представляю, как Modifier может что-то рисовать. В моём понимании он используется для настройки различных Composable. Можете привести пример, как Modifier что-то рисует?
Мне кажется, идея Воланда вами была понята несколько иначе, чем мной. Для меня это призыв к тому, чтобы, являясь слабее кого-то, не просить о чём-то, а обозначать свои потребности. Но, являясь сильным, по отношению к другому, стараться сделать жизнь слабых лучше.
Если перефразировать, то это полное исключение служению человеку, а не делу.
Никто не хочет отобрать у вас других людей. Как вы сами заметили, мы с вами не маугли, поэтому зависим от других. Мы всё ещё контактируем с другими и всё ещё получаем от них блага, как и они от нас. Это стиль общения высоких и разумных людей и не более. Как руководитель вы заботитесь, как подчинённый вы получаете.
Нет. Именно про Java. Есть 2 подхода к обобщённым функциям: как на С++ и как на Java. В первом случае во время компиляции генерируются реализации для всех возможных типов, с которым может быть вызвана функция. Каждая вариация оптимизируется отдельно. Но их много, и они все лежат в результирующем бинарнике. На Java же происходит стирание типов. Как следствие виртуальные вызовы гарантированы. Подводя итог: с подходом, как у плюсов или раста, генерируется много кода, но это не приводит к накладным расходам. А на Java-like дженериках приходится платить отсутствием оптимизации и лишними виртуальными вызовами
Может потому что в айти уже не актуально то, что было 10 лет назад и те 20 лет опыта на половину бесполезны? Просто потому что эти 20 лет ты выжимал байтики памяти и наносекунды скорости, а сейчас надо писать поддерживаемый код(что зачастую диаметрально противоположно)
Звучит очень противоречиво. JS явно понятнее среднему человеку, чем очень редкие детали HTLM/CSS. Это сильно бьёт по поддерживаемости. Другой программист может не знать деталей и сделать много косяков или попросту потратить непропорционально много времени.
Пример из поста. Я могу очень логично и элегантно написать решение за квадрат(на вскмдку). Он излишен конкретно для этой задачи, но его потом можно будет переиспользовать в отличие от процедуры, заточенной под супер конкретную задачу. Чтобы оптимизировать решение больше, придётся жертвовать обобщенностью решения т. е. как-то тонко эксплуатировать условия. И чем больше оптимизация, тем больше конкретизация под задачу. Под конкретную сейчас. ТЗ имеет свойство меняться, и придётся всё переписывать с нуля на ровном месте.
Почему это разница в BigO определяет правильность? Отправлю вас на кодфорс. Там все задачи красиво решаются с произвольным О, но если надо максимально быстро, то выйдет что-то страшное. Не дай бог такое писать в продакшене. И написать это поддерживаемо просто невозможно, так как никто не будет понимать твой fast inverse square root. Подводя итог: оптимизация может очень портить код, когда в этом нет никакой необходимости: задача об этом не просит.
Знаете, а я бы не хотела работать у вас… Для вас человек, страдающий преждевременной оптимизацией вместо поддерживаемости кода, предпочтительнее. Задачи написать быстро не стояло. Если писать весь код так, то… мне страшно представить кодовую базу вашу. Не правильнее было бы ожидать поддерживаемый код, а не быстрый?
Да, простого "научного" способа сказать научен ли код нельзя, так же как и с романами, впрочем куда легче сказать, что тот или иной роман плох в некоторой степени. Я писала эту статью с целью сделать общее описание того, что вообще такое "хороший код". Если смотреть на код, как на текст, несущий идеи, то все паттерны проектирования, за которыми можно "фанатично гнаться" становятся лишь инструментами, которые вполне понятно, когда примять.
Не только. Те же проблемы и на полноценном стационарном.
Следствием гибкости линукса является отсутствие какой-либо упругости. У него просто колоссальная фрагментация, ужасные пакетные менеджеры(они свою задачу на практике моей нормально пока ещё ни разу не решили)(которых столько, сколько пользователей линукс), которыми ты вынужден пользоваться, всё приходтся скачивать их сорцев, блютуз из коробки не работает(на 4 дистрибутивах, которые я пробовала)... и всё это потому что почти нет никакой централизованности. Линукс на столько гибок, что не существует в приемлемом виде.
Конечно, вам покажутся мои доводы смешными, но я даже пыталась со всем разобраться. Я только книжки наверное не читала(на сколько же хороший же линукс продукт, что, чтобы им пользоваться, надо читать целые книги). Я опытнее наверное 90% пользователей ПК. И мне ни для разработки, ни для чего-то другого не хочется возвращаться на линукс. У других осей графический интерфейс не забагован, диски работают нормально, всё работает само из коробки. Зачем мне пользоваться линуксом, если всё можно сделать на винде и это будет быстрее и просто приятнее?
Тогда мы даём модифаер столько раз, сколько есть разделителей. Это решение мало отличается от добавления их вручную после каждого ребёнка
Я не смогла найти модифаер, который даёт размеры всех детей контейнера. А без этого никак. Укажите если оный там есть
Никогда не использовала recyclerview, поэтому ничего не могу сказать.
Не совсем представляю, как Modifier может что-то рисовать. В моём понимании он используется для настройки различных Composable. Можете привести пример, как Modifier что-то рисует?
Мне кажется, идея Воланда вами была понята несколько иначе, чем мной. Для меня это призыв к тому, чтобы, являясь слабее кого-то, не просить о чём-то, а обозначать свои потребности. Но, являясь сильным, по отношению к другому, стараться сделать жизнь слабых лучше.
Если перефразировать, то это полное исключение служению человеку, а не делу.
Никто не хочет отобрать у вас других людей. Как вы сами заметили, мы с вами не маугли, поэтому зависим от других. Мы всё ещё контактируем с другими и всё ещё получаем от них блага, как и они от нас. Это стиль общения высоких и разумных людей и не более. Как руководитель вы заботитесь, как подчинённый вы получаете.
Всегда есть способ определить ответственность, кто «виновен» в панике. Либо это вина функции, которая запаниковала, либо вина вызывающей стороны.
Либо ОС вернула код ошибки 2 и никто не знает почему. То ли это код кривой, то ли вызов.
Потому что это подойдёт только для ТЗ тоже не длиннее 6 строчек.
А что бы вы хотели видеть в продвинутой статье? Как я для вас оборвала статью? Буду очень благодарна