Там где студенту не хочется получать навык, он выучивает по минимуму, получает свой заслуженный тройбан
Во-первых, тройбан тройбану рознь, особенно если что-то отличное от тройбана способно получить только 2-3 человека с потока, и то обычно не с первой попытки)
У меня вот по матану был тройбан, четверку я смог получить только один раз, за второй семестр на втором курсе, но я хорошо знаю матан ;)
Во-вторых, 3 > 0.
или платит денег и получает 5-ку,
На матфаке? Предложить за экзамен деньги?) Хороший способ быть посланным на *уй прямым текстом, чо еще сказать :)
Так что в реальности всё зависит от человека и никак не зависит от системы обучения.
В реальности все и всегда зависит от человека, но есть определенные статистические корреляции, соответствующие общему здравому смыслу)
И при прочих равных, человек, который имеет образование, будет более подготовлен.
Не буду сразу утверждать, что такое невозможно, но как-то сложно сразу такое придумать.
Эм, ну практически любой метод без this)
В смысле, на 1 реальный статический метод таких десяток приходится. правда тут конечно еще у вас особенности шарпа — в шарпе нельзя в топлевеле ф-и объявлять (ну, недавно вроде разрешили), а в js статические методы обычно просто выносятся из класса.
тогда линтер ругается, и мы метим конкретно этот метод атрибутом SuppressMessage с комментарием (Justification = "..."), почему мы этот метод все-таки сделали нестатическим.
Так а зачем это делать, если можно просто нестатические методы делать нестатическими, без SuppressMessage?
Мой подход — думать над тем, над чем действительно надо мозгом думать, и сваливать по возможности все остальное на автоматизированные инструменты
Нет, еще раз. Ваш подход — делать неправильно.
Я тоже люблю использовать автоматизированные инструменты — но только в том случае, когда они работают правильно. А если они дают ошибочный результат, да еще и усложняют работу (в результате чего с автоматизацией трудозатраты выше, чем без них) — то нафига такая автоматизация нужна?
Какие нервы, какой рейт — у меня IDE сама все форматирует и отклонения от правил по шорткату исправляет
Далеко не все линт-рулзы исправляются. И, с-но, тем которые "больно" соблюдать как раз обычно не исправляются :)
Ну и да — как ваш шорткат исправляет замену обычного метода на статик? Вместе с фиксом всех call-site и диффом на сотню строк?
Но, если честно, то не могу вспомнить случая, чтобы пришлось переделывать статику на нестатику или наоборот — это какое-то слишком уж сильное изменение семантики самого метода требуется.
Ну так метод семантически либо сразу статический, либо нет (это понятно, когда ты его создаешь). Но при этом он может не иметь this и быть по смыслу нестатическим (что регулярно происходит) — тогда линтер ругается, и мы делаем его статическим (хотя понимаем, что статическим он быть не должен). После чего this предсказуемо появляется — и надо переделывать обратно :)
А, опять-таки, задумываться всякий раз делать ли мне метод статическим или экземплярным (когда можно и так и так) я не хочу — мне проще последовать совету линтера
Но линтер не знает, должен быть метод статическим или нет — вот в чем штука.
Т.е. ваш подход — не думать и делать неправильно, оправдываясь тем, что "это посоветовал линтер".
Еще меньше споров, недовольства, и стресса будет если не работать вообще :))
Вы зачем-то работу (которая приносит пользу кастомерам, за что эти кастомеры платят деньги) равняете со следованием дебильным линт рулзам (которое никому ничего не приносит кроме потраченных нервов и уменьшения часового рейта).
Шарповому линтеру по умолчанию не нравится, если ты делаешь экземплярный метод там где мог бы быть статический.
100% же в линтере есть правило которое говорит, что статический метод нельзя вызывать через экземпляр, с-но когда у вас статический метод становится обычным (или наоборот), то надо менять все call-site. Ну а при обратном изменении (если статический метод становится обычным) менять вызовы придется в любом случае. Типичный пример вредного правила, которое ведет к раздуванию диффа.
но никогда не имел проблем из-за его соблюдения
Так постоянно встречается. Стоит чуть поменять метод (вызвать в нем this) — и привет рефакторингу с заменой всех вызовов.
собственно, вот она проблема линтера — он смотрит только на синтаксис. Линтер не понимает смысла кода (а потому не может отличить "синтаксически статический" метод, в котором просто в силу случайности нету this, от "семантически статического", который должен быть статическим по задумке), не имеет никаких предположений о том, как будет изменяться и т.п.
Линтер банально не обладает (и не может обладать) информацией, которая необходима для принятия решений о том, каким должен быть код. Поэтому и решать он ничего не может. Ну или может, но ошибается регулярно.
Если я не сделал метод статическим, значит, он по смыслу не должен быть статическим. Вне зависимости от мнения линтера по этому поводу. Мне лучше знать, чем линтеру :)
Точно так же ты можешь всегда сам решать — работать за деньги в команде
Неисполнение дебильных линт-рулзов только помогает работать в команде)
Меньше споров и внутреннего недовольства, выше производительность — а значит ниже стресс :)
Неисполнение правил, которые мы обсуждаем, обычно упрощает code review. Например, то самое правило, которое было упомянуто в этой ветке (недопуск неиспользуемых переменных) ведет к ненужному раздуванию дифа.
Ну и да, на самом деле, даже если вообще никак за кодстайлом не следить, то ревью это сколько-нибудь существенно не усложняет. Так что "правила нужны ради упрощения ревью" — это не более чем распространенный миф. Кто-то сказал глупость — остальные бездумно за ним повторяют. обычное явление, впрочем.
А ты сам как думаешь?
Думаю, что лучше отключить.
Если в походе в лесу можно пользоваться для еды только одной ложкой, а то и вообще одними руками, то разве не лучше тогда просто делать это и в ресторане.
Это аналогия как раз в мою пользу. Я сам решаю прекрасно — чем и где мне есть, никакой линтер за этим не следит. И если я буду есть руками в ресторане — мне даже никто не сделает никакого замечания.
Ну я же приводил тут примеры со статическими методами и неиспользуемыми параметрами, когда общее правило, которое следует соблюдать, не только может, но и должно быть нарушено в отдельном случае.
Так в том и смысл, что не в отдельном. Наоборот — обычно как раз и надо эти правила нарушать (с неиспользуемыми переменными — точно, что за правило на счет статических методов — не уверен, уточните).
Затем, что в одном случае есть причины, чтобы его обходить, а в другом случае его лучше соблюдать.
Ну т.е. коммиты с ошибками линта блокируются не затем, чтобы в коммит не проходил код с ошибками линта, а затем, чтобы в коммит не проходил код с незаблоченными ошибками линта.
Но это же бессмыслица, т.к. делает ситуацию только хуже.
алсо, если правило надо то соблюдать, то не соблюдать — то разве не лучше тогда его просто отключить? И пусть каждый сам решает в каждом месте — надо это правило соблюдать или нет. Без дополнительных церемоний. Нет?
Причин может быть много и вполне обоснованных, а не таких как "да надоел мне уже этот ворнинг".
Я говорю не о причинах для обхода правила а о причинах его наличия. Зачем оно нужно в принципе, если его в итоге надо обходить? Я понимаю, что многие люди просто любят гордо преодолевать собственноручное созданные проблемы, но кроме этого?
Если при этом имитация не будет иметь субъективной квалитативности (что невозможно проверить), то в этом и будет заключаться отличие.
Но вы ведь не можете быть уверены, что она такого опыта не имеет. Т.е. проблема именно отсюда идет. Вы предполагаете, что нечто, с виду не отличающееся от объекта с наличием квалитативного опыта, но при том его не имеющее, может существовать.
Гораздо интереснее, кстати, рассмотреть другую сущность — камень, который неотличим от обычного камня, но при этом обладает квалитативным опытом. Эта сущность, кстати, не просто "мыслится", а логически непротиворечиво существует.
Я работаю на C# и там любое правило можно на время или вообще навсегда отключить аттрибутом SuppressMessage именно в том месте где это надо. Как в других языках не знаю.
Можно, конечно. Но возникает вопрос — зачем вводить правила, и тем более ставить проверку их исполнения во время коммита, чтобы потом их отключать?
Ну вон я выше приводил пример правила, которое вместо fun = () => { return something; } требует писать fun = () => something. Оно увеличивает дифф. Собственно, те правила, выполнение которых наиболее "больно", как раз и обладают следующим свойством: они вынуждают при небольших правках кода делать существенно большие правки, чтобы удовлетворить линтер. Именно такие правила людей и бесят. И, достаточно очевидно, что такие правила будут вести к росту диффа.
Если же правило не ведет к росту диффа — то оно обычно (хотя тут есть исключения — например правила по упорядочиванию методов и т.п.) не требует сколько-нибудь существенных затрат на свое соблюдение и, скорее всего, вообще работает через автомформат. Такие правила в данном контексте обсуждать нет смысла.
Вы не можете понять простую вещь, читать мне все равно, что атрибуты на новой строчке, что на разных. Бегло не бегло — ерунда какая-то. Мне главное надо, чтобы было одинаково у всех.
Вот я и говорю, с опытом вы просто перестанете замечать — одинаково у всех или нет. Код с разным форматированием будет восприниматься мозгом как код с одинаковым форматированием.
Чтобы автоматическое форматирование у меня и у моего коллеги работало одинаково
А это вообще совершенно отдельный вопрос, ни как не связанный с предметом обсуждения.
Алсо, проблема "мусора форматирования" в коммитах на самом деле сама тут в комментах сильно преувеличена.
А оппоненты, включая меня, пытаются объяснить, что правила эти введены не потому, что так правильно. А чтобы минимизировать diff при командной работе.
Есть огромная куча правил, которые не уменьшают, а увеличивают дифф!
А оппоненты, включая меня, пытаются объяснить, что правила эти
Не "эти". С необходимостью "этих" правил автор не спорил, он спорил с необходимостью дебильных правил, которые нужны исключительно из-за синдрома вахтера у их написавшего и, по факту, просто вредят. Посмотрите, например, на airbnb'шный сет рулзов, там полно откровенной наркомании.
А если бы исключил это правило, то вся команда, вместо значащих изменений в коде сидела бы изучала предпочтения каждого при написании тегов.
Это все исключительно от недостатка опыта. Если вы научитесь бегло читать код на разных синтаксически ЯП, то такие вещи просто перестанете замечать. И даже не сможете после прочтения ответить на вопрос: "а как были расставлены атрибуты в этом коде?"
В нормальных компаниях код просто не пройдет коммит если линт ругается.
Как раз недавно была ситуация — надо было заменить реализацию ф-и на заглушку (ну т.е. вместо того, что там было, возвращать некоторую константу, это было актуально, естественно, исключительно для дев-ветки). При этом было линт правило — никаких неиспользуемых аргументов в ф-и! Понятное дело, что замена на заглушку приводила к неиспользуемым аргументам. А удаление аргументов, в свою очередь, приводило к ошибкам типов при вызове этой ф-и (на вызове аргументы-то были). Исправление тех ф-й — опять-таки каскадно приводило к неиспользуемым аргументам и ошибкам типов, в итоге, чтобы удовлетворить линт, коммит на 1 строчку легким движением руки превращается в коммит на несколько сотен строк. Иначе — коммит НЕ ПРОХОДИТ, ведь "в нормальных компаниях код просто не пройдет коммит если линт ругается".
Большая польза от этого всего, действительно, превратить минутную работу в часовое ковыряние в коде.
С другой стороны — время оплатит заказчик, а потому любой подход, который раздувает трудозатраты, полезен.
Если есть возможность проект, который делается год, делать три года — то какой смысл от нее отказываться? Это же просто не выгодно! Так что больше линт-рулзов — хороших и разных! А когда заказчик спросит — чо так долго? можно ему популярно объяснить, что вот смотрите сколько у нас линт-правил, пока все выполнишь… ух!
А качество заложенных знаний и наработанный навык, зависит полностью от человека, независимо студент это или самоучка.
Кнут — всегда был неплохим дополнением в качестве мотивации. Там, где студент получает навык, т.к. "иначе отчислят", самоучка просто говорит "фу, это как-то скучно, я хочу более веселые обои" и забивает болт.
В результате у самоучки знания значительно более фрагментарны. Вплоть до того, что они просто вообще не будут собираться вместе в какую-то стройную структуру — набрал человек на курсере "интересных" курсов, "неинтересное" — пропустил, в итоге вместо фундаментальных знаний у него разрозненные обрывки, и нету общего представления о том, как все работает в целом.
Ну вы пропустили "в серьезном объеме", а то что по ссылке — это явно не оно. Это даже до "базовых вещей" сильно не дотягивает. Вы там доехали хотя бы до характеристического многочлена и собственных векторов?
Я, например, алгебру знаю в пределах вот этого: http://alexandr4784.narod.ru/leng.html и этого http://alexandr4784.narod.ru/kag1.html
плюс книжки по некоторым интересным мне отдельным разделам (теория Галуа, теория конечных полей, линейка и тензорное исчисление, конечно), при этом где-то 80% я изучал сам.
Но я сильно поостерегся бы это называть "серьезным объемом" и сравнивать со знаниями человека, который занимается непосредственно наукой в этой области. А учеба в универе по специальности (те самые 20%) мне по крайней мере помогла понять куда вообще тут можно копать.
Сохранить прибыль, снизив цену во времена когда спрос превышает предложение?
А по каким причинам прибыль упадет? Нвидия-то карточки будет отдавать по той же самой цене. Это у ретейлеров их будут дешевле брать.
И, да, вы смотрите на кратковременный результат, а крупные компании — в будущее. Классический рынок видеокарт умирает, он уже скукожился в разы. Если не снизить раздутые спросом майнеров цены — он в ближайшее время умрет окончательно. И нвидия официально превратится из производителя видеокарт в производителя оборудования для майнинга. А это весьма рискованный бизнес — т.к. крипта может в любой момент накрыться медным тазом. Естественно, менеджеры нвидии это все прекрасно понимают.
Т.е, понимаете, нвидия в обоих случая продаст одинаковое количество видеокарт по одинаковой цене. Только в одном случае они сохранят за собой рынок пк-гейминга (как сохранят и сам рынок), а в другом — отдадут своих покупателей конкурентам в виде консолей и облаков.
Есть, конечно, достаточно очевидный другой выход — просто производить больше видеокарт, чтобы хватило на всех. но это физически невозможно, т.к. производственные мощности не безграничны. В таких случаях продавцу важно понимать, кому он продает свой товар и с какими последствиями. Некое короткое время можно получать некоторый профит от пиления сука, на котором сидишь — но потом этот сук обламывается.
Вы пытаетесь нас убедить, что коммерческая помпания, ориентированная на получение прибли отказывается от получения прибыли? Что?
Я же выше вполне ясно объяснил, зачем это компании. Что вам там непонятно? Никто от прибыли не отказывается, наоборот — смысл-то как раз в том, чтобы эту прибыль сохранить. А для этого надо снизить цены на видеокарты. И единственный способ это сделать — снизить спрос со стороны майнеров.
Верно, это проблема майнеров. Если с их стороны так велик спрос — пускай они и платят.
Вы не совсем понимаете, в чем смысл подобного решения — компания в целом от него зарабатывать больше не станет, будет просто перераспределена структура выручки.
А надо это за тем, что текущий спрос майнеров на видеокарты из-за роста цен убивает обычный потребительский сегмент. Нвидия, конечно, не хочет терять рынок — а это в дальней перспективе случится, если ничего не предпринимать. Если цены останутся на текущем уровне, то геймеры просто перестанут покупать видеокарты. И заставить их потом начать покупать их снова — будет архисложная задача.
То есть вы обсираете не глобальные состояния как таковые, а подход где есть только глобальные состояния и нет локальных, и даже компонент с которым никто из вне не взаимодействует, обладающий каким-то состоянием и вот его состояние все равно выкинуто в глобальное, да?)
Мне казалось, что это совершенно ясно из контекста.
Все глобальные состояния должны хранится в специальной папке с глобальными состояниями, а локальные прямо рядом с компонентами, это вроде и так очевидно.
Я вообще не понимаю с какого перепуга вы думаете что глобальное состояние это значит что абсолютно всё состояние в приложении глобальное у такого понятия как локальный стейт компонента не существует, все глобальное
Это именно тот кейз, который мы обсуждали в данной ветке — "тащить все в глобальный стейт по дефолту".
Потому что это не правда, говнокод можно написать абсолютно всегда
Вопрос в сложности написания говнокода.
Это же очевидно. Но вы почему-то думаете если кто-то сказал «глобальный стейт», то этой значит локальных состояний у компонентов нет
Нет, я так не думаю. но некоторые люди предпочитают в принципе не использовать локальный стейт, а весь стейт делать глобальный. Именно недостатки этого подхода мы и обсуждали в данной ветке. А вы ворвались, не разобравшись :)
Во-первых, тройбан тройбану рознь, особенно если что-то отличное от тройбана способно получить только 2-3 человека с потока, и то обычно не с первой попытки)
У меня вот по матану был тройбан, четверку я смог получить только один раз, за второй семестр на втором курсе, но я хорошо знаю матан ;)
Во-вторых, 3 > 0.
На матфаке? Предложить за экзамен деньги?) Хороший способ быть посланным на *уй прямым текстом, чо еще сказать :)
В реальности все и всегда зависит от человека, но есть определенные статистические корреляции, соответствующие общему здравому смыслу)
И при прочих равных, человек, который имеет образование, будет более подготовлен.
Эм, ну практически любой метод без this)
В смысле, на 1 реальный статический метод таких десяток приходится. правда тут конечно еще у вас особенности шарпа — в шарпе нельзя в топлевеле ф-и объявлять (ну, недавно вроде разрешили), а в js статические методы обычно просто выносятся из класса.
Так а зачем это делать, если можно просто нестатические методы делать нестатическими, без SuppressMessage?
Нет, еще раз. Ваш подход — делать неправильно.
Я тоже люблю использовать автоматизированные инструменты — но только в том случае, когда они работают правильно. А если они дают ошибочный результат, да еще и усложняют работу (в результате чего с автоматизацией трудозатраты выше, чем без них) — то нафига такая автоматизация нужна?
Далеко не все линт-рулзы исправляются. И, с-но, тем которые "больно" соблюдать как раз обычно не исправляются :)
Ну и да — как ваш шорткат исправляет замену обычного метода на статик? Вместе с фиксом всех call-site и диффом на сотню строк?
Ну так метод семантически либо сразу статический, либо нет (это понятно, когда ты его создаешь). Но при этом он может не иметь this и быть по смыслу нестатическим (что регулярно происходит) — тогда линтер ругается, и мы делаем его статическим (хотя понимаем, что статическим он быть не должен). После чего this предсказуемо появляется — и надо переделывать обратно :)
Но линтер не знает, должен быть метод статическим или нет — вот в чем штука.
Т.е. ваш подход — не думать и делать неправильно, оправдываясь тем, что "это посоветовал линтер".
Вы зачем-то работу (которая приносит пользу кастомерам, за что эти кастомеры платят деньги) равняете со следованием дебильным линт рулзам (которое никому ничего не приносит кроме потраченных нервов и уменьшения часового рейта).
100% же в линтере есть правило которое говорит, что статический метод нельзя вызывать через экземпляр, с-но когда у вас статический метод становится обычным (или наоборот), то надо менять все call-site. Ну а при обратном изменении (если статический метод становится обычным) менять вызовы придется в любом случае. Типичный пример вредного правила, которое ведет к раздуванию диффа.
Так постоянно встречается. Стоит чуть поменять метод (вызвать в нем this) — и привет рефакторингу с заменой всех вызовов.
собственно, вот она проблема линтера — он смотрит только на синтаксис. Линтер не понимает смысла кода (а потому не может отличить "синтаксически статический" метод, в котором просто в силу случайности нету this, от "семантически статического", который должен быть статическим по задумке), не имеет никаких предположений о том, как будет изменяться и т.п.
Линтер банально не обладает (и не может обладать) информацией, которая необходима для принятия решений о том, каким должен быть код. Поэтому и решать он ничего не может. Ну или может, но ошибается регулярно.
Если я не сделал метод статическим, значит, он по смыслу не должен быть статическим. Вне зависимости от мнения линтера по этому поводу. Мне лучше знать, чем линтеру :)
Неисполнение дебильных линт-рулзов только помогает работать в команде)
Меньше споров и внутреннего недовольства, выше производительность — а значит ниже стресс :)
Неисполнение правил, которые мы обсуждаем, обычно упрощает code review. Например, то самое правило, которое было упомянуто в этой ветке (недопуск неиспользуемых переменных) ведет к ненужному раздуванию дифа.
Ну и да, на самом деле, даже если вообще никак за кодстайлом не следить, то ревью это сколько-нибудь существенно не усложняет. Так что "правила нужны ради упрощения ревью" — это не более чем распространенный миф. Кто-то сказал глупость — остальные бездумно за ним повторяют. обычное явление, впрочем.
Думаю, что лучше отключить.
Это аналогия как раз в мою пользу. Я сам решаю прекрасно — чем и где мне есть, никакой линтер за этим не следит. И если я буду есть руками в ресторане — мне даже никто не сделает никакого замечания.
Так в том и смысл, что не в отдельном. Наоборот — обычно как раз и надо эти правила нарушать (с неиспользуемыми переменными — точно, что за правило на счет статических методов — не уверен, уточните).
Ну т.е. коммиты с ошибками линта блокируются не затем, чтобы в коммит не проходил код с ошибками линта, а затем, чтобы в коммит не проходил код с незаблоченными ошибками линта.
Но это же бессмыслица, т.к. делает ситуацию только хуже.
алсо, если правило надо то соблюдать, то не соблюдать — то разве не лучше тогда его просто отключить? И пусть каждый сам решает в каждом месте — надо это правило соблюдать или нет. Без дополнительных церемоний. Нет?
Я говорю не о причинах для обхода правила а о причинах его наличия. Зачем оно нужно в принципе, если его в итоге надо обходить? Я понимаю, что многие люди просто любят гордо преодолевать собственноручное созданные проблемы, но кроме этого?
Но вы ведь не можете быть уверены, что она такого опыта не имеет. Т.е. проблема именно отсюда идет. Вы предполагаете, что нечто, с виду не отличающееся от объекта с наличием квалитативного опыта, но при том его не имеющее, может существовать.
Гораздо интереснее, кстати, рассмотреть другую сущность — камень, который неотличим от обычного камня, но при этом обладает квалитативным опытом. Эта сущность, кстати, не просто "мыслится", а логически непротиворечиво существует.
Можно, конечно. Но возникает вопрос — зачем вводить правила, и тем более ставить проверку их исполнения во время коммита, чтобы потом их отключать?
Ну вон я выше приводил пример правила, которое вместо fun = () => { return something; } требует писать fun = () => something. Оно увеличивает дифф. Собственно, те правила, выполнение которых наиболее "больно", как раз и обладают следующим свойством: они вынуждают при небольших правках кода делать существенно большие правки, чтобы удовлетворить линтер. Именно такие правила людей и бесят. И, достаточно очевидно, что такие правила будут вести к росту диффа.
Если же правило не ведет к росту диффа — то оно обычно (хотя тут есть исключения — например правила по упорядочиванию методов и т.п.) не требует сколько-нибудь существенных затрат на свое соблюдение и, скорее всего, вообще работает через автомформат. Такие правила в данном контексте обсуждать нет смысла.
Вот я и говорю, с опытом вы просто перестанете замечать — одинаково у всех или нет. Код с разным форматированием будет восприниматься мозгом как код с одинаковым форматированием.
А это вообще совершенно отдельный вопрос, ни как не связанный с предметом обсуждения.
Алсо, проблема "мусора форматирования" в коммитах на самом деле сама тут в комментах сильно преувеличена.
Есть огромная куча правил, которые не уменьшают, а увеличивают дифф!
Не "эти". С необходимостью "этих" правил автор не спорил, он спорил с необходимостью дебильных правил, которые нужны исключительно из-за синдрома вахтера у их написавшего и, по факту, просто вредят. Посмотрите, например, на airbnb'шный сет рулзов, там полно откровенной наркомании.
Это все исключительно от недостатка опыта. Если вы научитесь бегло читать код на разных синтаксически ЯП, то такие вещи просто перестанете замечать. И даже не сможете после прочтения ответить на вопрос: "а как были расставлены атрибуты в этом коде?"
Как раз недавно была ситуация — надо было заменить реализацию ф-и на заглушку (ну т.е. вместо того, что там было, возвращать некоторую константу, это было актуально, естественно, исключительно для дев-ветки). При этом было линт правило — никаких неиспользуемых аргументов в ф-и! Понятное дело, что замена на заглушку приводила к неиспользуемым аргументам. А удаление аргументов, в свою очередь, приводило к ошибкам типов при вызове этой ф-и (на вызове аргументы-то были). Исправление тех ф-й — опять-таки каскадно приводило к неиспользуемым аргументам и ошибкам типов, в итоге, чтобы удовлетворить линт, коммит на 1 строчку легким движением руки превращается в коммит на несколько сотен строк. Иначе — коммит НЕ ПРОХОДИТ, ведь "в нормальных компаниях код просто не пройдет коммит если линт ругается".
Большая польза от этого всего, действительно, превратить минутную работу в часовое ковыряние в коде.
С другой стороны — время оплатит заказчик, а потому любой подход, который раздувает трудозатраты, полезен.
Если есть возможность проект, который делается год, делать три года — то какой смысл от нее отказываться? Это же просто не выгодно! Так что больше линт-рулзов — хороших и разных! А когда заказчик спросит — чо так долго? можно ему популярно объяснить, что вот смотрите сколько у нас линт-правил, пока все выполнишь… ух!
Кнут — всегда был неплохим дополнением в качестве мотивации. Там, где студент получает навык, т.к. "иначе отчислят", самоучка просто говорит "фу, это как-то скучно, я хочу более веселые обои" и забивает болт.
В результате у самоучки знания значительно более фрагментарны. Вплоть до того, что они просто вообще не будут собираться вместе в какую-то стройную структуру — набрал человек на курсере "интересных" курсов, "неинтересное" — пропустил, в итоге вместо фундаментальных знаний у него разрозненные обрывки, и нету общего представления о том, как все работает в целом.
Ну вы пропустили "в серьезном объеме", а то что по ссылке — это явно не оно. Это даже до "базовых вещей" сильно не дотягивает. Вы там доехали хотя бы до характеристического многочлена и собственных векторов?
Я, например, алгебру знаю в пределах вот этого: http://alexandr4784.narod.ru/leng.html и этого http://alexandr4784.narod.ru/kag1.html
плюс книжки по некоторым интересным мне отдельным разделам (теория Галуа, теория конечных полей, линейка и тензорное исчисление, конечно), при этом где-то 80% я изучал сам.
Но я сильно поостерегся бы это называть "серьезным объемом" и сравнивать со знаниями человека, который занимается непосредственно наукой в этой области. А учеба в универе по специальности (те самые 20%) мне по крайней мере помогла понять куда вообще тут можно копать.
А чем имитация мышления отличается о тмышления?
А по каким причинам прибыль упадет? Нвидия-то карточки будет отдавать по той же самой цене. Это у ретейлеров их будут дешевле брать.
И, да, вы смотрите на кратковременный результат, а крупные компании — в будущее. Классический рынок видеокарт умирает, он уже скукожился в разы. Если не снизить раздутые спросом майнеров цены — он в ближайшее время умрет окончательно. И нвидия официально превратится из производителя видеокарт в производителя оборудования для майнинга. А это весьма рискованный бизнес — т.к. крипта может в любой момент накрыться медным тазом. Естественно, менеджеры нвидии это все прекрасно понимают.
Т.е, понимаете, нвидия в обоих случая продаст одинаковое количество видеокарт по одинаковой цене. Только в одном случае они сохранят за собой рынок пк-гейминга (как сохранят и сам рынок), а в другом — отдадут своих покупателей конкурентам в виде консолей и облаков.
Есть, конечно, достаточно очевидный другой выход — просто производить больше видеокарт, чтобы хватило на всех. но это физически невозможно, т.к. производственные мощности не безграничны. В таких случаях продавцу важно понимать, кому он продает свой товар и с какими последствиями. Некое короткое время можно получать некоторый профит от пиления сука, на котором сидишь — но потом этот сук обламывается.
Я же выше вполне ясно объяснил, зачем это компании. Что вам там непонятно? Никто от прибыли не отказывается, наоборот — смысл-то как раз в том, чтобы эту прибыль сохранить. А для этого надо снизить цены на видеокарты. И единственный способ это сделать — снизить спрос со стороны майнеров.
Верно, это проблема майнеров. Если с их стороны так велик спрос — пускай они и платят.
Вы не совсем понимаете, в чем смысл подобного решения — компания в целом от него зарабатывать больше не станет, будет просто перераспределена структура выручки.
А надо это за тем, что текущий спрос майнеров на видеокарты из-за роста цен убивает обычный потребительский сегмент. Нвидия, конечно, не хочет терять рынок — а это в дальней перспективе случится, если ничего не предпринимать. Если цены останутся на текущем уровне, то геймеры просто перестанут покупать видеокарты. И заставить их потом начать покупать их снова — будет архисложная задача.
Мне казалось, что это совершенно ясно из контекста.
Ну вот DmitryKazakov8 — не очевидно.
Это именно тот кейз, который мы обсуждали в данной ветке — "тащить все в глобальный стейт по дефолту".
Вопрос в сложности написания говнокода.
Нет, я так не думаю. но некоторые люди предпочитают в принципе не использовать локальный стейт, а весь стейт делать глобальный. Именно недостатки этого подхода мы и обсуждали в данной ветке. А вы ворвались, не разобравшись :)