На любой дистанции программист/дизайнер, который не получает фидбек от использования системы в продакшне (в виде репортов о созданных им багах, например), отрывается от реальности и витает в иллюзиях что он идеален и ему незачем исправляться и развиваться.
И каждый следующий их проект получается с такими-же багами и недоработками.
Подход, при котором "починку моих багов оставьте другим, я творец, я пошел делать новые баги" - это недальновидность и спесь.
Mr. Robot - это больше про наркоманию и психические расстройства. Не то чтобы я против, но это просто заезженые темы, вместо обещаного сериал про хакеров. Хакинг в сериале, может, и реалистичный, но он больше для создания фона, сериал мог быть и про бухгалтеров, с теми-же персонажами, и той-же драмой.
К сожалению, дальше 3-4 серии продолжать есть кактус я не смог. Я питал надежды, но видимо, сделать сам хакинг интересным для масс-консюмера не получается, и приходится фокусироваться на отработаных приемах (асоциальный гений с нарко-зависимостью, как в Доктор Хаус, например).
Фильм про Митника уже интересен, так-как по-крайней мере в нем фокус на настоящей хакерской истории (пусть Митник и social-engineer больше, чем технический спец.) Надо пересмотреть :)
Развернутый, но не аргументированый. Точка зрения ваша ясна (уже была), а причины для этой точки зрения вы не обьясняете.
И опять-таки, вы говорите о том что я, как личность, "не пожил ещё достаточно", а не о том, где моем анализе ошибки.
У меня знакомый дед есть, алкоголик-тиран, говорить с ним по существу нету как. У него аргументация на всё слилась в "я пожил". У вас, естественно, я полагаю, более продуманная позиция, мы на IT-ресурсе, как никак. Только вы её не озвучиваете.
Ну, и, П.С., может, кому неочевидно, что такое бывает: я Хабр читаю с десяток, наверное, лет, и имел приличное такое время понаблюдать. Хотя, повторюсь, если-бы кто-то вчера впервые увидел сайт, и сделал о нем аргументированые выводы и убедительные доводы, к ним всё равно стоило-бы серьезно относиться.
По сути моего коментария, я полагаю, вам нечего сказать (раз вы выше соглашаетесь с написаным в нем).
То-есть, тут просто дедовщина "будет нам ещё молодняк указывать как себя вести". Таких от вас в этом посте штук 20. Для чего вы это делаете? Какой прок иметь максимум коментов с таким контентом?
Ваш комментарий как-раз иллюстрирует 2 вещи по теме:
Карма ничему не учит, можно преспокойно иметь десятки тысяч коментов и десятки статей, и околонулевую (но плюсовую) карму, и считать себя праведником.
Перед ответом на коментарий, вместо того чтобы отвечать по существу на высказаный материал, некоторые предпочитают пойти и проверить "личность" человека. То-есть, ценные идеи могут исходить только от ценных людей?
Рационально разделять личность человека и его отдельные идеи. Это инстинктивно не присуще человеку, но думаю, имеет смысл хотя-бы не мотивировать людей идти на поводу у инстинктов через само устройство сообщества.
ИМХО, само существование метрики "карма" - избыточно и нарушает принцип Бритвы Оккама.
Возможность дать минус в карму "за то что человек неадекватный" без привязки к неадекватной вещи которую человек сказал - non-sequitur.
Всё взаимодействие на сайте происходит через публикации и коменты, соответственно, нету никакой возможности узнать что человек - неадекват, кроме как через конкретный текст, который он написал.
Но при этом мы постоянно видим коментарии людей, у которых(, по их утверждению,) сплошные плюсы в коментах, и минусы в карме. (Хотя, судя по упоминаниям в посте, начальство разбирается и устраняет подобные недоразумения, с 98% эффективностью.)
Хочется разобрать аргументы за карму по тезисам:
Карма — отличная метрика для оценки адекватности пользователя.
Только при определении "адекватность" как: мнение пользователя соответствует мнению людей, у которых уже есть карма.
Условно говоря, многие любят Go и вот приходит критик Go. Он аргументированно пишет о минусах языка программирования и о своём негативном опыте. Заслуживает ли он минус? Нет, но всё равно получит.
Карма — важный элемент геймификации.
Геймификация работает, когда есть конкретные правила, по которым ведется игра, и можно им следовать. Правило игры в карму - угадай кому подпевать, или не высовывайся. Думаю, оптимизируя эту метрику, я мог-бы набить сотню кармы для спортивного интереса, просто поддакивая в нужные моменты нужным коментариям. Вопрос лишь, чего мы достигаем как сообщество, ставя эту мотивацию перед участниками.
Карма — способ вовремя остановиться.
Это да. Но, судя по отпискам в коменты тут, тролли просто создают новые аккаунты, а люди которые задумываются над тем, что говорят, само-цензурятся (хотя их, может, и стоило-бы послушать.)
Карма — инструмент саморегуляции.
Ну это вроде повторяет тезис 3. Кину пару ассоциаций которые у меня появляются, для передания моей интуиции. Само-цензура. Само-репрессирование. Германия 30х годов, к власти пришли фашисты и отменили возможность с ними спорить и их сменить. Другие страны в другие времена, где можно присесть за выражение точек зрения, отличающихся от оффициальной.
Карма — точка роста.
К сожалению, роста в умении оптимизировать карму, критика та-же, что в первом тезисе.
И 3 пункта против, с ними я согласен, только не знал, что есть куда обратиться, чтобы твой случай разобрали.
Рекоммендации (хотя понимаю что инерция продолжать с существующей системой просто огромная, кое-как ведь работает все эти года):
Отменить карму, и оставить только +/- за публикации/коментарии.
Попробовать сделать +/- публичным, для снижения мотиваци подподлить просто от плохого настроения.
Активнее эксперементировать с механизмами фидбека, внедрять разные на месяц-два и смотреть на результат.
У сотрудника могут быть и другие, более приоритетные заботы, связанные с его основными обязанностями.
Ну так тем более :) Пускай занимается более приоритетными заботами, чем подключаться на зум-сессию чтобы сказать что "всё всё ещё ок", но теперь фокус сбился, и нужно ещё час востанавливать контест задачи, чтобы продолжить работать.
Как уже сказано в смежном коменте, лучше создать атмосферу доверия у сотрудника, чтобы он знал, что в любые часы можно придти с любой проблемой.
Понятно, что подчиненые бывают разные. Но именно из-за этого я практиковал подход, где "Если работник самостоятельный - можно заранее пропустить все будущие созвоны, когда надо, позвонит сам".
В моей команде был человек, которого надо было попытать с 20 минут, чтобы выяснить, достаточно-ли у него данных для решения задачи, какие проблемы у него есть и нужно-ли помочь ему их решать (иначе временами он провисал в "лимбо", пытаясь угадывать ответы на свои вопросы, не любил лишний раз спросить). Это было важно делать, чтобы он мог работать продуктивно, и постепенно привык рассказывать/спрашивать сам.
Но к подавляющему большинству людей такой подход строго контрпродуктивен. Люди интерпретируют это как низкий уровень доверия, или cargo-cult practices, или как критику их перформанса (в духе "если бы всё было нормально, мне-бы не ездили по ушам").
А разве не лучше делать push со стороны самого члена команды, когда у него действительно есть о чем спросить/попросить/известить? Зачем регулярный polling?
Ну, понятно зачем менеджменту, убедиться что работник ещё жив, и ещё помнит кто его нанял. А для работника это вынужденая трата времени и (и ресурса общительности, если он интроверт).
Разным людям интересно разное, например, мой камент был ответом на:
"-но я умнее чем сам компилятор Раста. -Ой ли?"
И в этом контесте, уточнения про внимательность и легкость это shifting goalposts and strawmanning.
И, по сути нового вопроса, да. Компайлер точно внимательней, но если false positive rate - 50% (к счастью, это не про Раст), то практического проку мало.
насколько легко написать код, который раст примет?
Консенсус по этому вопросу таков, что "сложнее, чем код, который примет C". (Правда это невозможно ставить Расту в упрек, у него более высокие амбиции, и требования поэтому соответствующие.)
Не совсем понимаю какие вы пытаетесь из этого делать выводы.
Я в целом со всем согласен, и в плане строгих инструментов тоже. Нужен только правильный баланс cost/benefit, а он у каждого проекта разный.
Моя претензия в том, что "язык умный, а ты тупой" это нездоровый, да и фактически неверный подход. Но, думаю, этот вопрос мы разобрали.
И, чтобы передать ещё моей интуиции по этому поводу: servo, постер-бой Раста, написаный, если не ошибаюсь, самими создателями языка, содержит в себе больше сотни упоминаний #[allow(unsafe_code)] (включая достаточно забавное "This code is highly unsafe.")
Что говорит нам о том, что создатели Раста знают (или считают что знают), где он компетентен (почти везде), а где нет, и нужно взять в свои руки контроль. За что им большое уважение.
Либо мне нужно было именно второе из них, либо split_at_mut тогда тоже было экспериментальным. Думаю, сути моего возражения это не меняет.
Практически, нужное мне поведение, стало "признано безопасным разработчиками Раст" и имплементировано средствами языка (через unsafe, неудивительно). Просто контрпример тому, что "компилятор лучше понимает".
Супер, я согласен, что это лишь вопрос того, окупаются-ли затраченые усилия.
Аналогия с код-ревью, это если на каждом ревью половина правок/коментов неоправданые, просто false-positive предрассудков ревьюера, обсудить с ревьюером смысл нельзя, и ваш деливери блокируется из-за них.
Возможно, в такой ситуации стоит поискать более понятливого ревьюера, но можно и практиковать подход "я что, считаю себя умнее чем ревьюер или его создатели?" Шучу, нельзя. Надо знать сильные и слабые стороны своего инструмента.
А почему вы сомневаетесь, что человек может быть умнее чем программа?
Тем более незнакомый вам человек, видимо вы по-умолчанию считаете всех недоумками.
Компилятор, в ваших глазах, наверняка умнее меня, а вы, раз можете мне разьяснить его логику, умнее и его и меня. Не много на себя берете?
Компилятор не божественен, он может доказать безопасность для ограниченого сабсета всех возможных корректных програм, просто есть надежда, ставка на то, что этот сабсет достаточно широк для достаточного удобства программирования. (Референс можно нагуглить по "Rust's radical wager".)
Тот факт, что практически возможно написать абсолютно безопасный код, который Раст не примет, может удивить разве-что оголтелого фанбоя.
И, по сути вопроса. Момент который конкретно мне дал интуицию, что придется прогибаться под компилятор зря, был, если я правильно помню, таков: мне надо было разделить массив на две части (скажем, [0..1] и [1..6]) и менять значения в одной, сверяясь с содержимым второй. На что Раст жаловался что я "дважды беру одно и то-же", и я могу его понять. Но на практике, эти части не пересекаются, и я это знаю, и в моей программе, соответственно, это не могло вызвать проблем. А компилятор нет. Вас может убедить что проблем не могло-бы быть, потому-что есть API языка который это разбиение поддерживает (только "ночной экспериментальный").
Советы от умных людей (вас может шокировать, что я советовался с умными людьми до вас) заключались в том, что нужно:
либо менять поведение программы, не брать слайсы, а передавать индексы (это "делать долгий крюк хотя есть короткий поворот не по рельсам"),
либо использовать unsafe, (понятно почему это не ответ)
я не умнее и опытнее чем люди которые создали теорию, и на основе нее компилятор Раста. но я умнее чем сам компилятор Раста.
Раст перестраховывается, и защищая от вещей которые возможно опасны, запрещает также вещи, которые очевидно безопасны. получается, часть дизайна программы диктуется не "так безопасно", а "только так компайлер не боится что может быть небезопасно".
да вы и сами пишете "более чем в половине случаев" - значит в остальной "почти половине" вы танцуете просто по прихоти компилятора
как трамвай, когда вам надо повернуть направо, туда точно безопасно, но рельсы трамвая рельсы только налево, в крюк через весь город (и сами рельсы невидимые, но, скажем, норм, привыкаешь интуитивно их чувствовать). зато в стену въехать невозможно, гарантии.
ps: языки с динамическими типами в этой аналогии это одноколесный мопед с ракетным движком, при достаточном старании тоже можно не въехать в стену, и можно по рампе перепрыгивать перекрёстки, но зачем?
Порядка 10^7 тонн в какую единицу времени? (Думаю, если придираться к мелочам с начала комментария, то всё его продолжение должно быть идеально выдержано.)
Пять порядков не ощущается как прям много, особенно если сравнивать только с поедаемой пищей - возможно, для создания пищи расходуется в несколько раз больше биомассы, ещё на порядок больше биомассы уничтожается / заливается / высушивается чтобы освободить место для производства еды, ещё больше биомассы затрагивается не-пищевой индустрией, и это только на данный момент, а население людей может расти в геометрической прогрессии. В целом, 10^5, даже если это в год (а не в день, например), может оказаться лишь короткой отсрочкой для человеческого рода. (А может и нет).
Меня всегда интересовало, какое влияние человек оказывает на природу вокруг себя, масштаб нашего влияния на среду по сравнению с масштабами Земли, но видимо, соотношение массы биомассы Земли к массе нашей пищи плохо это репрезентирует.
Прям реально нет разницы, что разрабатывать, как разрабатывать, лишь бы деньги платили?
Про это должен кандидат спрашивать, а не HR, и уж явно к вопросу "почему вы к нам пришли?" это никакого отношения не имеет.
Зачем люди так рьяно защищают очевидно ущербные практики? Даже принося в жертву здравый смысл (как здесь, ожидаемый ответ не соответствует вопросу). Никогда не могу этого понять.
Это такой status quo bias в крайней форме? Когда не просто хочешь чтобы всё оставалось как есть (даже если можно лучше), но и настойчиво убеждаешь в этом людей?
Формулировки вопросов, конечно, мудаковатые, но таки от разработчика чуть выше джуна ожидается некая способность к коммуникации с другими людьми.
Если от кого ожидается способность к комуникации (как основной, если не единственный скилл), то это от Хьюман Ресорс специалиста. Может не надо перекладывать с больной головы на здоровую тогда?
часто слышу/читаю про "наукообразные тексты", и по мне - это ещё одна травма с которой люди выходят из вуза - желание писать слишком заумно.
тексты надо писать так, чтобы легко, понятно, и приятно было читать, а не "наукообразные".
в идеале и научные тексты должны быть сложны ровно настолько насколько сложен сам материал и проф. жаргон (но у многих есть соблазн писать помудренее, чтобы казаться умнее чем на самом деле)
Не нравится такая система - займитесь поддержкой образования и дайте денег.
не критикуйте его в Интернете, а просто помогите
зачем? пора слезть с мертвой лошади, а не пытаться ее еще сильнее пришпоривать...
чем вливать усилия в прогнившую систему, в которой добросовестных - один человек на кафедру на много лет, лучше работать над тем чтобы убрать стигму в рекрутинге с онлайн-курсов и самообразования. особенно учитывая что именно возможность к самообразованию является критическим признаком хорошего программиста (как неоднократно упоминалось здесь в комментах)
уважаю (и сожалею) за проделанную вами работу, но к сожалению она (точнее отношение к ней универа) демонстрирует лишь ещё один симптом вышесказанного. паблишните ваш курс в опенсорс, или хотя-бы в платный MOOC может, так он принесет пользу тем кто действительно интересуется, но не хочет тратить время и силы на обесценивающуюся корочку
если нарабатываемые софт-скилы это умение хорошо списывать, то я о универе ещё более скептического мнения чем раньше. вместо того чтобы учиться быть программистами программируя, а командными игроками - через работу в команде, студенты прокачивают навыки прохождения экзаменов с минимальным оседанием бесполезной нагрузки в голове.
реальный мир же после этого играет не по тем правилам в которых можно списать все ответы в конце, и выпросить у экзаменатора проходной балл. получается, время и усилия затраченные на получение этих навыков идут только во вред общей продуктивности в индустрии
я-бы предположил, что просто произошла какая-то путаница. "не ищи злой умысел там, где можно обойтись просто глупостью". попробуй написать этому "Ричарду", что-то в духе: "I'm afraid there has been a misunderstanding. This security bug was fixed as a consequence of my report, as noted previously in our email thread. It was valid and reproduced before the fix."
может, путаница как раз там где тебя просят подтвердить фикс бага? (в не выложенной части переписки)
На любой дистанции программист/дизайнер, который не получает фидбек от использования системы в продакшне (в виде репортов о созданных им багах, например), отрывается от реальности и витает в иллюзиях что он идеален и ему незачем исправляться и развиваться.
И каждый следующий их проект получается с такими-же багами и недоработками.
Подход, при котором "починку моих багов оставьте другим, я творец, я пошел делать новые баги" - это недальновидность и спесь.
Mr. Robot - это больше про наркоманию и психические расстройства. Не то чтобы я против, но это просто заезженые темы, вместо обещаного сериал про хакеров. Хакинг в сериале, может, и реалистичный, но он больше для создания фона, сериал мог быть и про бухгалтеров, с теми-же персонажами, и той-же драмой.
К сожалению, дальше 3-4 серии продолжать есть кактус я не смог. Я питал надежды, но видимо, сделать сам хакинг интересным для масс-консюмера не получается, и приходится фокусироваться на отработаных приемах (асоциальный гений с нарко-зависимостью, как в Доктор Хаус, например).
Фильм про Митника уже интересен, так-как по-крайней мере в нем фокус на настоящей хакерской истории (пусть Митник и social-engineer больше, чем технический спец.) Надо пересмотреть :)
Развернутый, но не аргументированый. Точка зрения ваша ясна (уже была), а причины для этой точки зрения вы не обьясняете.
И опять-таки, вы говорите о том что я, как личность, "не пожил ещё достаточно", а не о том, где моем анализе ошибки.
У меня знакомый дед есть, алкоголик-тиран, говорить с ним по существу нету как. У него аргументация на всё слилась в "я пожил". У вас, естественно, я полагаю, более продуманная позиция, мы на IT-ресурсе, как никак. Только вы её не озвучиваете.
Ну, и, П.С., может, кому неочевидно, что такое бывает: я Хабр читаю с десяток, наверное, лет, и имел приличное такое время понаблюдать. Хотя, повторюсь, если-бы кто-то вчера впервые увидел сайт, и сделал о нем аргументированые выводы и убедительные доводы, к ним всё равно стоило-бы серьезно относиться.
Я много думаю, и немного пишу.
По сути моего коментария, я полагаю, вам нечего сказать (раз вы выше соглашаетесь с написаным в нем).
То-есть, тут просто дедовщина "будет нам ещё молодняк указывать как себя вести". Таких от вас в этом посте штук 20. Для чего вы это делаете? Какой прок иметь максимум коментов с таким контентом?
Ваш комментарий как-раз иллюстрирует 2 вещи по теме:
Карма ничему не учит, можно преспокойно иметь десятки тысяч коментов и десятки статей, и околонулевую (но плюсовую) карму, и считать себя праведником.
Перед ответом на коментарий, вместо того чтобы отвечать по существу на высказаный материал, некоторые предпочитают пойти и проверить "личность" человека. То-есть, ценные идеи могут исходить только от ценных людей?
Рационально разделять личность человека и его отдельные идеи. Это инстинктивно не присуще человеку, но думаю, имеет смысл хотя-бы не мотивировать людей идти на поводу у инстинктов через само устройство сообщества.
ИМХО, само существование метрики "карма" - избыточно и нарушает принцип Бритвы Оккама.
Возможность дать минус в карму "за то что человек неадекватный" без привязки к неадекватной вещи которую человек сказал - non-sequitur.
Всё взаимодействие на сайте происходит через публикации и коменты, соответственно, нету никакой возможности узнать что человек - неадекват, кроме как через конкретный текст, который он написал.
Но при этом мы постоянно видим коментарии людей, у которых(, по их утверждению,) сплошные плюсы в коментах, и минусы в карме. (Хотя, судя по упоминаниям в посте, начальство разбирается и устраняет подобные недоразумения, с 98% эффективностью.)
Хочется разобрать аргументы за карму по тезисам:
Карма — отличная метрика для оценки адекватности пользователя.
Только при определении "адекватность" как: мнение пользователя соответствует мнению людей, у которых уже есть карма.
Карма — важный элемент геймификации.
Геймификация работает, когда есть конкретные правила, по которым ведется игра, и можно им следовать. Правило игры в карму - угадай кому подпевать, или не высовывайся. Думаю, оптимизируя эту метрику, я мог-бы набить сотню кармы для спортивного интереса, просто поддакивая в нужные моменты нужным коментариям. Вопрос лишь, чего мы достигаем как сообщество, ставя эту мотивацию перед участниками.
Карма — способ вовремя остановиться.
Это да. Но, судя по отпискам в коменты тут, тролли просто создают новые аккаунты, а люди которые задумываются над тем, что говорят, само-цензурятся (хотя их, может, и стоило-бы послушать.)
Карма — инструмент саморегуляции.
Ну это вроде повторяет тезис 3. Кину пару ассоциаций которые у меня появляются, для передания моей интуиции. Само-цензура. Само-репрессирование. Германия 30х годов, к власти пришли фашисты и отменили возможность с ними спорить и их сменить. Другие страны в другие времена, где можно присесть за выражение точек зрения, отличающихся от оффициальной.
Карма — точка роста.
К сожалению, роста в умении оптимизировать карму, критика та-же, что в первом тезисе.
И 3 пункта против, с ними я согласен, только не знал, что есть куда обратиться, чтобы твой случай разобрали.
Рекоммендации (хотя понимаю что инерция продолжать с существующей системой просто огромная, кое-как ведь работает все эти года):
Отменить карму, и оставить только +/- за публикации/коментарии.
Попробовать сделать +/- публичным, для снижения мотиваци подподлить просто от плохого настроения.
Активнее эксперементировать с механизмами фидбека, внедрять разные на месяц-два и смотреть на результат.
Ну так тем более :) Пускай занимается более приоритетными заботами, чем подключаться на зум-сессию чтобы сказать что "всё всё ещё ок", но теперь фокус сбился, и нужно ещё час востанавливать контест задачи, чтобы продолжить работать.
Как уже сказано в смежном коменте, лучше создать атмосферу доверия у сотрудника, чтобы он знал, что в любые часы можно придти с любой проблемой.
Понятно, что подчиненые бывают разные. Но именно из-за этого я практиковал подход, где "Если работник самостоятельный - можно заранее пропустить все будущие созвоны, когда надо, позвонит сам".
В моей команде был человек, которого надо было попытать с 20 минут, чтобы выяснить, достаточно-ли у него данных для решения задачи, какие проблемы у него есть и нужно-ли помочь ему их решать (иначе временами он провисал в "лимбо", пытаясь угадывать ответы на свои вопросы, не любил лишний раз спросить). Это было важно делать, чтобы он мог работать продуктивно, и постепенно привык рассказывать/спрашивать сам.
Но к подавляющему большинству людей такой подход строго контрпродуктивен. Люди интерпретируют это как низкий уровень доверия, или cargo-cult practices, или как критику их перформанса (в духе "если бы всё было нормально, мне-бы не ездили по ушам").
А разве не лучше делать push со стороны самого члена команды, когда у него действительно есть о чем спросить/попросить/известить? Зачем регулярный polling?
Ну, понятно зачем менеджменту, убедиться что работник ещё жив, и ещё помнит кто его нанял. А для работника это вынужденая трата времени и (и ресурса общительности, если он интроверт).
Это так, глядя со стороны system design :)
Разным людям интересно разное, например, мой камент был ответом на:
"-но я умнее чем сам компилятор Раста. -Ой ли?"
И в этом контесте, уточнения про внимательность и легкость это shifting goalposts and strawmanning.
И, по сути нового вопроса, да. Компайлер точно внимательней, но если false positive rate - 50% (к счастью, это не про Раст), то практического проку мало.
Консенсус по этому вопросу таков, что "сложнее, чем код, который примет C". (Правда это невозможно ставить Расту в упрек, у него более высокие амбиции, и требования поэтому соответствующие.)
Не совсем понимаю какие вы пытаетесь из этого делать выводы.
Я в целом со всем согласен, и в плане строгих инструментов тоже. Нужен только правильный баланс cost/benefit, а он у каждого проекта разный.
Моя претензия в том, что "язык умный, а ты тупой" это нездоровый, да и фактически неверный подход. Но, думаю, этот вопрос мы разобрали.
И, чтобы передать ещё моей интуиции по этому поводу: servo, постер-бой Раста, написаный, если не ошибаюсь, самими создателями языка, содержит в себе больше сотни упоминаний #[allow(unsafe_code)] (включая достаточно забавное "This code is highly unsafe.")
Что говорит нам о том, что создатели Раста знают (или считают что знают), где он компетентен (почти везде), а где нет, и нужно взять в свои руки контроль. За что им большое уважение.
Либо мне нужно было именно второе из них, либо split_at_mut тогда тоже было экспериментальным. Думаю, сути моего возражения это не меняет.
Практически, нужное мне поведение, стало "признано безопасным разработчиками Раст" и имплементировано средствами языка (через unsafe, неудивительно). Просто контрпример тому, что "компилятор лучше понимает".
Супер, я согласен, что это лишь вопрос того, окупаются-ли затраченые усилия.
Аналогия с код-ревью, это если на каждом ревью половина правок/коментов неоправданые, просто false-positive предрассудков ревьюера, обсудить с ревьюером смысл нельзя, и ваш деливери блокируется из-за них.
Возможно, в такой ситуации стоит поискать более понятливого ревьюера, но можно и практиковать подход "я что, считаю себя умнее чем ревьюер или его создатели?" Шучу, нельзя. Надо знать сильные и слабые стороны своего инструмента.
А почему вы сомневаетесь, что человек может быть умнее чем программа?
Тем более незнакомый вам человек, видимо вы по-умолчанию считаете всех недоумками.
Компилятор, в ваших глазах, наверняка умнее меня, а вы, раз можете мне разьяснить его логику, умнее и его и меня. Не много на себя берете?
Компилятор не божественен, он может доказать безопасность для ограниченого сабсета всех возможных корректных програм, просто есть надежда, ставка на то, что этот сабсет достаточно широк для достаточного удобства программирования. (Референс можно нагуглить по "Rust's radical wager".)
Тот факт, что практически возможно написать абсолютно безопасный код, который Раст не примет, может удивить разве-что оголтелого фанбоя.
И, по сути вопроса. Момент который конкретно мне дал интуицию, что придется прогибаться под компилятор зря, был, если я правильно помню, таков: мне надо было разделить массив на две части (скажем, [0..1] и [1..6]) и менять значения в одной, сверяясь с содержимым второй. На что Раст жаловался что я "дважды беру одно и то-же", и я могу его понять. Но на практике, эти части не пересекаются, и я это знаю, и в моей программе, соответственно, это не могло вызвать проблем. А компилятор нет. Вас может убедить что проблем не могло-бы быть, потому-что есть API языка который это разбиение поддерживает (только "ночной экспериментальный").
Советы от умных людей (вас может шокировать, что я советовался с умными людьми до вас) заключались в том, что нужно:
либо менять поведение программы, не брать слайсы, а передавать индексы (это "делать долгий крюк хотя есть короткий поворот не по рельсам"),
либо использовать unsafe, (понятно почему это не ответ)
либо использовать "nightly-only experimental API". https://doc.rust-lang.org/std/primitive.slice.html#method.split_array_mut (тоже должно быть понятно, что "просто используй экспериментальный API" - не серьезный подход - никто даже не гарантирует что он продолжит существовать)
я не умнее и опытнее чем люди которые создали теорию, и на основе нее компилятор Раста. но я умнее чем сам компилятор Раста.
Раст перестраховывается, и защищая от вещей которые возможно опасны, запрещает также вещи, которые очевидно безопасны. получается, часть дизайна программы диктуется не "так безопасно", а "только так компайлер не боится что может быть небезопасно".
да вы и сами пишете "более чем в половине случаев" - значит в остальной "почти половине" вы танцуете просто по прихоти компилятора
как трамвай, когда вам надо повернуть направо, туда точно безопасно, но рельсы трамвая рельсы только налево, в крюк через весь город (и сами рельсы невидимые, но, скажем, норм, привыкаешь интуитивно их чувствовать). зато в стену въехать невозможно, гарантии.
ps: языки с динамическими типами в этой аналогии это одноколесный мопед с ракетным движком, при достаточном старании тоже можно не въехать в стену, и можно по рампе перепрыгивать перекрёстки, но зачем?
Более того, Open и Libre - не "отечественные", как и большинство софта упоминающегося в коментах...
А значит, любая капиталистическая свинья может заложить в них бомбу чтобы саботировать Отечество на пути к светлому будущему.
То-есть, надо таки "свои, с нуля" разработки, с нескучными обоями.
Порядка 10^7 тонн в какую единицу времени? (Думаю, если придираться к мелочам с начала комментария, то всё его продолжение должно быть идеально выдержано.)
Пять порядков не ощущается как прям много, особенно если сравнивать только с поедаемой пищей - возможно, для создания пищи расходуется в несколько раз больше биомассы, ещё на порядок больше биомассы уничтожается / заливается / высушивается чтобы освободить место для производства еды, ещё больше биомассы затрагивается не-пищевой индустрией, и это только на данный момент, а население людей может расти в геометрической прогрессии. В целом, 10^5, даже если это в год (а не в день, например), может оказаться лишь короткой отсрочкой для человеческого рода. (А может и нет).
Меня всегда интересовало, какое влияние человек оказывает на природу вокруг себя, масштаб нашего влияния на среду по сравнению с масштабами Земли, но видимо, соотношение массы биомассы Земли к массе нашей пищи плохо это репрезентирует.
Про это должен кандидат спрашивать, а не HR, и уж явно к вопросу "почему вы к нам пришли?" это никакого отношения не имеет.
Зачем люди так рьяно защищают очевидно ущербные практики? Даже принося в жертву здравый смысл (как здесь, ожидаемый ответ не соответствует вопросу). Никогда не могу этого понять.
Это такой status quo bias в крайней форме? Когда не просто хочешь чтобы всё оставалось как есть (даже если можно лучше), но и настойчиво убеждаешь в этом людей?
Если от кого ожидается способность к комуникации (как основной, если не единственный скилл), то это от Хьюман Ресорс специалиста. Может не надо перекладывать с больной головы на здоровую тогда?
часто слышу/читаю про "наукообразные тексты", и по мне - это ещё одна травма с которой люди выходят из вуза - желание писать слишком заумно.
тексты надо писать так, чтобы легко, понятно, и приятно было читать, а не "наукообразные".
в идеале и научные тексты должны быть сложны ровно настолько насколько сложен сам материал и проф. жаргон (но у многих есть соблазн писать помудренее, чтобы казаться умнее чем на самом деле)
зачем? пора слезть с мертвой лошади, а не пытаться ее еще сильнее пришпоривать...
чем вливать усилия в прогнившую систему, в которой добросовестных - один человек на кафедру на много лет, лучше работать над тем чтобы убрать стигму в рекрутинге с онлайн-курсов и самообразования. особенно учитывая что именно возможность к самообразованию является критическим признаком хорошего программиста (как неоднократно упоминалось здесь в комментах)
уважаю (и сожалею) за проделанную вами работу, но к сожалению она (точнее отношение к ней универа) демонстрирует лишь ещё один симптом вышесказанного. паблишните ваш курс в опенсорс, или хотя-бы в платный MOOC может, так он принесет пользу тем кто действительно интересуется, но не хочет тратить время и силы на обесценивающуюся корочку
если нарабатываемые софт-скилы это умение хорошо списывать, то я о универе ещё более скептического мнения чем раньше. вместо того чтобы учиться быть программистами программируя, а командными игроками - через работу в команде, студенты прокачивают навыки прохождения экзаменов с минимальным оседанием бесполезной нагрузки в голове.
реальный мир же после этого играет не по тем правилам в которых можно списать все ответы в конце, и выпросить у экзаменатора проходной балл. получается, время и усилия затраченные на получение этих навыков идут только во вред общей продуктивности в индустрии
я-бы предположил, что просто произошла какая-то путаница. "не ищи злой умысел там, где можно обойтись просто глупостью". попробуй написать этому "Ричарду", что-то в духе: "I'm afraid there has been a misunderstanding. This security bug was fixed as a consequence of my report, as noted previously in our email thread. It was valid and reproduced before the fix."
может, путаница как раз там где тебя просят подтвердить фикс бага? (в не выложенной части переписки)