Собственно из этого утверждения «кортеж — это структура времени компиляции» и исходят все ваши рассуждения в статье.
Это утверждение изначально неверное, даже в той же вики вы можете прочитать «Ordered pairs are also called 2-tuples», а уж пара никак не структура времени компиляции.
В оригинале (для примера возьмем любой) multi-process, multi-process = многопроцессный, а не «многопроцессорный» ваш заголовок звучит как будто добавили какую-либо оптимизацию специально для поддержки нескольких процессоров.
склеивать числа в строку крайне неэффективно, почему бы их прямо из функции не печатать?
Вот как раз «печатать» и есть очень недешевая операция, если будем говорить о перфомансе рекурсивных решений, то лучше прокинуть StringBuilder аргументом и распечатать буфер один раз.
Итого, учитывая то, что вы так и не смогли предоставить никаких аргументов, мы выяснили, что вы пытаетесь влезть в сферу в которой, мягко говоря, экспертом не являетесь, тем не менее настойчиво пытаетесь продавить свое мнение.
А я вот посоветую хотя бы посмотреть в сторону clojurescript + reagent, код получается чертовски простым и прекрасным (хотя для незнакомых с lisp непривычным поначалу)!
React по сути своей очень функционален и его пересечение с функциональным clojure дает поразительный результат. Надеюсь, когда-нибудь соберусь таки написать об этом обзорную статью на хабр.
Отлично, со всеми пунктами разобрались, остался последний, «транзитивные зависимости» (заметим, что ее автор даже не упомянул, хотя это как раз и есть может стать проблемой). Билд система вам, конечно, не решит эту проблему, однако просигнализирует и предложит попытку решить «ту легкую ситуацию».
Предположим, что у нас действительно «нерешаемая зависимость», тогда вы, как инженер, стоите на распутье — можете либо пересобрать либу как shade-jar и нести в дальнейшем груз поддержки, либо отказаться от ее использования в пользу своего кода.
Что лучше — зависит от ситуации, а вам, как инженеру, платят за решение этой проблемы.
Небольшой комментарий из мира Java, почему я считаю, что вышеперечисленное не актуально для нас:
1) VCS для сорцев, а не для бинарников, все бинарники хранятся в бинарном репозитории.
2) Время компиляции увеличивается несущественно
3) Не актуально для 95% библиотек, билд системы полностью решают эту проблему
4) Библиотеки хотя бы исправляют, а у вас "security through obscurity", для настоящего злоумышленника — не помеха
5) Binary compatibility
6) Binary compatibility
7) JVM везде JVM
8) Ни разу не встречал подобную проблему в языках с явными импортами и корректной статической типизацией
9, 10) Отвечу одно — библиотека — 150+ коммитов исправлений, накопленный опыт, ваш велосипед — 1 коммит…
Поэтому статья актуальна не для хаба «разработка», а для «c++»
В общем, библиотечная функция это всегда трейдоф, на то мы инженеры, чтобы его решать в зависимости от контекста, а не слепо следовать «рекоммендациям».
В целом согласен, но вообще можно попробовать провести параллели между телеграфистами и теми, кто клепает сайтики, а программисты того времени — это те, кто создали и телеграф, и телефон.
Это утверждение изначально неверное, даже в той же вики вы можете прочитать «Ordered pairs are also called 2-tuples», а уж пара никак не структура времени компиляции.
Сходу источник не смог нагуглить.
Вот как раз «печатать» и есть очень недешевая операция, если будем говорить о перфомансе рекурсивных решений, то лучше прокинуть StringBuilder аргументом и распечатать буфер один раз.
1. Создаем в проекте модуль D, D зависит от C
2. Собираем D как shade-jar
3. Делаем главный модуль зависимым на артефакте D
4. ???
5. PROFIT
React по сути своей очень функционален и его пересечение с функциональным clojure дает поразительный результат. Надеюсь, когда-нибудь соберусь таки написать об этом обзорную статью на хабр.
Предположим, что у нас действительно «нерешаемая зависимость», тогда вы, как инженер, стоите на распутье — можете либо пересобрать либу как shade-jar и нести в дальнейшем груз поддержки, либо отказаться от ее использования в пользу своего кода.
Что лучше — зависит от ситуации, а вам, как инженеру, платят за решение этой проблемы.
Пролистайте чуть выше, я там перечислил почему не верны, прямо по пунктам
И исправляют их, а в вашем коде никто не исправляет не баги, не уязвимости
Да, я выше и написал, трейдоф, однако правильные билд-системы предоставляют мощнейшие тулы чтобы решить эту проблему
1) VCS для сорцев, а не для бинарников, все бинарники хранятся в бинарном репозитории.
2) Время компиляции увеличивается несущественно
3) Не актуально для 95% библиотек, билд системы полностью решают эту проблему
4) Библиотеки хотя бы исправляют, а у вас "security through obscurity", для настоящего злоумышленника — не помеха
5) Binary compatibility
6) Binary compatibility
7) JVM везде JVM
8) Ни разу не встречал подобную проблему в языках с явными импортами и корректной статической типизацией
9, 10) Отвечу одно — библиотека — 150+ коммитов исправлений, накопленный опыт, ваш велосипед — 1 коммит…
Поэтому статья актуальна не для хаба «разработка», а для «c++»
В общем, библиотечная функция это всегда трейдоф, на то мы инженеры, чтобы его решать в зависимости от контекста, а не слепо следовать «рекоммендациям».
Про Катю то допишете, это же еще не конец?
В целом согласен, но вообще можно попробовать провести параллели между телеграфистами и теми, кто клепает сайтики, а программисты того времени — это те, кто создали и телеграф, и телефон.
Это какие-такие права предоставляет твиттеру правительство РФ? Право давать нам пользователям им пользоваться?