С очевидным ответом не спорю, но аналогия неверная: что происходит именно с процессором мы и так знаем. Тут вопрос скорее об отдельной программе (ядро ОС, например).
Вы выложили целый перевод статьи на Хабре, в котором один из тезисов звучит так:
Вместо того, чтобы наклеивать ярлыки, типа "лучший" или "худший", лучшим способом увеличить среднюю производительность будет увеличить производительность каждого.
Расскажите, как в вашей картине мира это вяжется с вашим текущим комментарием?
Скорее для любой скорости в принципе. Скорость света - просто константа, соответствующая максимальной размерности переменной) И, скорее всего, как раз signed int, поэтому нейтрино, превышающие скорость света, движутся обратно во времени - первый бит меняется от переполнения ;)
Более того, этот факт в настоящее время проверяется ежесекундно с помощью GPS, ГЛОНАСС и иже с ними, которые без поправок на релятивистские эффекты дают неверные значения.
Автор иронизирует над другими стеками технологий, которыми не пользуется.
Не увидел этого)
Автор иронизирует - это верно. Но я воспринял текст автора как иронию над культом сложности: мол, любая инженерная задача - это вызов и возможность применить весь набор инструментов, доступных человечеству на данном этапе эволюции, нагородить тысячи абстракций и декомпозировать код на миллионы методов, каждый из которых содержит одну строку кода (для читаемости).
Конечно же, это не так)
Во-первых, есть пресловутый закон Парето, который в том числе можно интерпретировать так, что 80% задач требуют самых простых и тривиальных решений. "Авантюризм", про который вы говорите, применим в остальных 20% случаев. Да, они принесут 80% пользы, но это не означает, что простые и тривиальные решения не нужны. Это всё ещё большая часть работы любого из нас.
Во-вторых, просто - не означает легко. Как верно заметили в других комментах - автор говорит про простоту восприятия написанного кода (тут невольно вспоминается "цикломатическая сложность"). Писать понятный код - это отдельное искусство: им действительно не похвастаешься в Google, но этот навык делает программиста ценнее. Проблема "авантюристов" в том, что они могут выдать рабочее (даже гениальное) решение, но если в нём никто не может разобраться - полезность этого решения снижается при необходимости внести в него правки.
Кажется, что терминологию, которую вы тут ищете, придумали давно: есть прикладные инженеры и есть инженеры-исследователи. Прикладной инженер применяет имеющиеся в его распоряжении инструменты и знания для решения конкретной прикладной задачи. Исследователи анализируют существующие инструменты и придумывают новые.
Если просто денег заработать - то нафиг не нужны распределённые кэши, абстракции и другие совершенства инженерной мысли
Не вижу связи, если честно. Необходимость высокоуровневых инструментов обычно диктуется сложностью задачи. Если ваша работа - разработать приложение на 100 человек (условно), но вы запихиваете туда все известные примочки просто из любви к профессии - вы действуете нерационально.
И не надо, пожалуйста, никого никому противопоставлять и рассказывать, кто лучше: все профессии нужны, все профессии важны. Ваш чудесный инженер-исследователь, который двигает всю индустрию, может помереть на месте от рутинных задач, которые решает обычный прикладной инженер. А прикладной инженер, в свою очередь, раз в жизни может и написать что-то общественно полезное. Это роли, которые мы примеряем на себя в жизни, они меняются.
Тем не менее, автору лично я бы посоветовал не вешать на себя ярлыки и таки прощёлкать задачки с LeetCode, или освоить Rust, или ещё как-то расшевелить свой мозг - не столько для профессионального развития, сколько для личной пользы. Просто, чтобы не утратить гибкость мышления - тяжело, больно (с возрастом образование новых нейронных связей - всё более неприятный процесс), но полезно.
Выглядит как описание прекрасного коллеги, с которым одно удовольствие работать.
Программы, которые я создаю, вроде бы работают нормально. На программиста из Google они большого впечатления, конечно, не произведут
Парадокс в том, что подобные программы не произведут впечатления при собеседовании в Google. А вот окажись такой человек внутри - есть вероятность, что его бы ценили за качество и предсказуемость результата.
Но вам такие люди не нужны, вы ищете себе подобных
Это вообще одна из главных проблем таких мини-царей от разработки. Они сначала долго и упорно убеждают себя и окружающих в собственной уникальности и непогрешимости (свой стек - единственным, достойным изучения; свои инструменты - единственными, удобными для работы; свой образ жизни, конечно же, единственно верным), а потом приходят к страшному выводу, что не способны работать ни с кем, кроме себя самого.
Спасибо, что напомнили. В голове сложился паттерн, в лицензию саму давно не смотрел.
Ну и хорошо)
Только кажется, что забыли опубликовать и нарушили GPL)
С очевидным ответом не спорю, но аналогия неверная: что происходит именно с процессором мы и так знаем. Тут вопрос скорее об отдельной программе (ядро ОС, например).
Вы выложили целый перевод статьи на Хабре, в котором один из тезисов звучит так:
Расскажите, как в вашей картине мира это вяжется с вашим текущим комментарием?
Жаль, что вы сразу не написали "sarcasm"(
Люди устали от фанатиков, видимо: проще влепить минус, чем разбираться, не шутит ли комментатор.
Скорее для любой скорости в принципе. Скорость света - просто константа, соответствующая максимальной размерности переменной)
И, скорее всего, как раз signed int, поэтому нейтрино, превышающие скорость света, движутся обратно во времени - первый бит меняется от переполнения ;)
Это вы скорее про
E = mc^2Более того, этот факт в настоящее время проверяется ежесекундно с помощью GPS, ГЛОНАСС и иже с ними, которые без поправок на релятивистские эффекты дают неверные значения.
Расслабиться и жить дальше? :D
Да, это было до бакалавров)
(Осознал свой возраст, приуныл)
Не увидел этого)
Автор иронизирует - это верно. Но я воспринял текст автора как иронию над культом сложности: мол, любая инженерная задача - это вызов и возможность применить весь набор инструментов, доступных человечеству на данном этапе эволюции, нагородить тысячи абстракций и декомпозировать код на миллионы методов, каждый из которых содержит одну строку кода (для читаемости).
Конечно же, это не так)
Во-первых, есть пресловутый закон Парето, который в том числе можно интерпретировать так, что 80% задач требуют самых простых и тривиальных решений. "Авантюризм", про который вы говорите, применим в остальных 20% случаев. Да, они принесут 80% пользы, но это не означает, что простые и тривиальные решения не нужны. Это всё ещё большая часть работы любого из нас.
Во-вторых, просто - не означает легко. Как верно заметили в других комментах - автор говорит про простоту восприятия написанного кода (тут невольно вспоминается "цикломатическая сложность"). Писать понятный код - это отдельное искусство: им действительно не похвастаешься в Google, но этот навык делает программиста ценнее. Проблема "авантюристов" в том, что они могут выдать рабочее (даже гениальное) решение, но если в нём никто не может разобраться - полезность этого решения снижается при необходимости внести в него правки.
Спасибо, что напомнили про этот шедевр)
Надо пойти выпить black think juice
Что-то очень много категоричных заявлений на единицу текста, простите. Вы уверены, что не выдаёте свои мироощущения за непреложную истину?
Это не тот вопрос, на который отвечает в своей заметке автор. Кажется, вы отвечаете в своём контексте, но многие поняли статью по-другому.
Кажется, что терминологию, которую вы тут ищете, придумали давно: есть прикладные инженеры и есть инженеры-исследователи. Прикладной инженер применяет имеющиеся в его распоряжении инструменты и знания для решения конкретной прикладной задачи. Исследователи анализируют существующие инструменты и придумывают новые.
Не вижу связи, если честно. Необходимость высокоуровневых инструментов обычно диктуется сложностью задачи. Если ваша работа - разработать приложение на 100 человек (условно), но вы запихиваете туда все известные примочки просто из любви к профессии - вы действуете нерационально.
И не надо, пожалуйста, никого никому противопоставлять и рассказывать, кто лучше: все профессии нужны, все профессии важны. Ваш чудесный инженер-исследователь, который двигает всю индустрию, может помереть на месте от рутинных задач, которые решает обычный прикладной инженер. А прикладной инженер, в свою очередь, раз в жизни может и написать что-то общественно полезное. Это роли, которые мы примеряем на себя в жизни, они меняются.
Это перевод, под заголовком есть ссылка на сайт автора.
Тем не менее, автору лично я бы посоветовал не вешать на себя ярлыки и таки прощёлкать задачки с LeetCode, или освоить Rust, или ещё как-то расшевелить свой мозг - не столько для профессионального развития, сколько для личной пользы. Просто, чтобы не утратить гибкость мышления - тяжело, больно (с возрастом образование новых нейронных связей - всё более неприятный процесс), но полезно.
Выглядит как описание прекрасного коллеги, с которым одно удовольствие работать.
Парадокс в том, что подобные программы не произведут впечатления при собеседовании в Google. А вот окажись такой человек внутри - есть вероятность, что его бы ценили за качество и предсказуемость результата.
Это вообще одна из главных проблем таких мини-царей от разработки. Они сначала долго и упорно убеждают себя и окружающих в собственной уникальности и непогрешимости (свой стек - единственным, достойным изучения; свои инструменты - единственными, удобными для работы; свой образ жизни, конечно же, единственно верным), а потом приходят к страшному выводу, что не способны работать ни с кем, кроме себя самого.
Истинно так. Автор ушёл из американской компании и вернулся в "локальную контору" - теперь ему нужно убедить себя (и нас), что решение было верным.