у раста кривая обучения не похожа на иные языки. И это известный факт.
Кому известный? На какие «другие»? Чем именно не похожа?
Раст — всего лишь еще один низкоуровневый язык, появление которого бы вообще никто не заметил, если бы не хайп по типам и не агрессивный маркетинг. Даже Julia извне пузыря — выглядит в разы более продуманной. Через несколько лет спираль сделает очередной изгиб — вот тогда и посмотрим.
Говорить про что-то, в чем сам уже освоился, мол «это сложно, не всем дано кривая обучения особенная» — очень смешно и не очень вежливо. У понимания доказательства гипотезы Римана — кривая действительно крутовата. У очередного говноязыка, каких было и будет сотни — никакой особенной кривой нет, код пописал месяцок — и уже мидл.
Но это же стандартная реализация поиска в дереве [...]
А ничё, что код, на который вы дали ссылку — уже рекурсивен? Подозреваю, что Rust не сможет вывести тотальность перекрестной рекурсии, поэтому там и появляется хак с псевдобесконечным циклом, переопределением биндинга из внутреннего скоупа и бесчисленными ранними возвратами, превращающими и без того лапшу — в мелкопокрошенное спагетти. Может быть, лучше заняться доведением до ума компилятора, чтобы можно было бы избежать вот таких хаков?
Я уже ответил на пять каментов выше в ветке.
Ну это ответ в духе «все ваши варианты мне не нравятся, поэтому не существуют».
Я же выше привёл простой, конкретный пример.
Циклы очень часто используются [...]
int n = 0;
while (n < 42) {
n = process(n);
}
Во-первых, есть куча языков, в которых циклы в принципе не предусмотрены синтаксисом. Во-вторых, в мультипарадигменных языках как-то все более принято заменять циклы на функциональные аналоги типа map/reduce, или, на худой конец, comprehensions. В-третьих, даже в языках с «родными» циклами, вышеприведенный фрагмент — смердит, и я лично разворачиваю на ревью код, который так волюнтаристски мутирует весь окружающий мир; это нечитаемо и очень подвержено привнесению ошибок впоследствии.
Покажите замену того кода на цикл без присваиваний. Без рекурсии.
А почему она должна существовать? «Покажите замену кода с goto на код без goto и без циклов» — тоже разновидность некорректного безответного вопроса.
За что я люблю синтетические примеры, так это за всё.
int (*fns[16])(int * const * p)
Я готов поспорить, что когнитивные усилия здесь придется тратить на понимание того, как этот тип заполняется, и зачем вообще автору втемяшилось объявлять такую функцию. После того, как это будет понято, тип сам собой нарисуется.
В простом коде все эти фигурные скобки и отступы считываются мгновенно, а в сложном — основные проблемы чтения связаны далеко не с ними.
Разработчикам новых языков — полезно учиться на чужих ошибках, чтобы их не повторять.
Это было бы круто, кабы существовала непротиворечивая корректная шкала оценки синтаксиса. А так, как ее нет, то и определить — ошибка ли это, или суперспособность — возможным не представляется. «Демократичным» голосованием это определять? — Увольте.
Вон там внизу предлагают изменять язык до неузнаваемости, развивать и дополнять, пока количество синтаксического сахара не превысит количество символов на клавиатуре (а потом и в юникоде) — я бы лично не хотел, чтобы над языками издевались таким способом, выбранным по результатам голосования у джаваскриптовиков, которые желают, чтобы все мучались так, как они.
Я лучше уж разочек синтаксис (любой) освою, а потом буду языком пользоваться, а не переучивать семантику каждые полгода.
Вообще, обсуждение характеристик синтаксиса (даже если называть их уместными словами с соответствующими значениями, типа «читаемость») — мне непонятно в принципе. Совершенно очевидно, что любой язык (да, и кобол, и сиквел — тоже) превращается из нечитаемого в читаемый по мере погружения.
Когда я еду во Францию, я освежаю в голове всякие «сильвупле» и «мерси», а не говорю, мол, «фу, какой нечитаемый язык, я лучше пару дней буду питаться не в кабаках, а в супермаркетах без кассиров».
Какая вообще нахрен разница, каков синтаксис языка, если он не умеет, например, из коробки задействовать все ядра? А если умеет — ну в чужой монастырь не надо со своим синтаксисом лезть, можно потратить пару часиков на привыкание.
он сказал, что да, зная что его зарплата в псоледнем квартиле, а сегодня вышл новый обзор рынка, по которому он увидел, что его текущая зарплата стала медианной и она его перестала устраивать...
Во-первых, так не бывает. Зарплаты так не растут.
Но даже если бы и было — я уже сказал: если разработчик следит за каждым дуновением ветерка, и бегает клянчить каждый раз, как выпал из последнего квартиля — пошел он в жопу (на галеру).
Мы без него обойдемся, а он — ну тут совсем не факт, что ему понравится все то, на что он променял свои 10%.
Мы говорим примерно об одном и том же. Шеф не обязан быть телепатом, и подходить к нему можно, и нужно.
Что шеф обязан, с моей точки зрения — так это не делегировать инициативу поощрения сотрудников самим сотрудникам. Разработчик не должен ходить просить повышать зарплату; разработчик должен ходить предлагать хорошие решения чего бы то ни было (от «давайте-ка я тут тестами позанимаюсь месяцок» до «давайте-ка я вот этот проект буду вести») — а релевантное вознаграждение, устраивающее разработчика — это и есть прямая обязанность шефа.
Иначе попрошайки начнут получать в разы больше прямо завтра.
Почему-то мне кажется вы критически не способны воспринимать чужую точку зрения.
Я хотел понять вашу мотивацию, но в вашем ответе больше пафоса, чем реальных причин.
Ну вот зато вы прям можете гордиться своей суперспособностью критически воспринимать чужую точку зрения, ну а когда не способны, в силу скудости ума и воображения — всегда можно объявить собеседника пафосным тараканом, не способным на развитие.
По существу нечего ответить?
Я подробно ответил выше, но мой ответ вам не понравился.
Просто наблюдение, к вам не имеющее никакого отношения: леммингам почти никогда не нравится то, что я говорю. Это ни хорошо, ни плохо, если не оправдывать это другими причинами.
Предугадывание и понимание «какие обязанности разработчик может ещё исполнять, чтобы получать больше», продвижение людей по карьерной лестнице, поощрение, поддержание во всех хорошего настроения и удовлетворения зарплатой.
Вообще, в здоровых командах, люди делают сколько хотят и могут — без предварительного шантажа «дай рубль, а то буду как буратино только то, что мне навязали, делать», — а руководство обо всем этом знает, и повышает зарплаты соответственно. Я это назвал «автоматически» в своем самом первом комментарии.
С тех пор меня успели обвинить в том, что я всех вокруг держу за холопов, а сам пригрелся и просто не хочу развиваться. Но тезис от этого не поменялся.
В моем понимании хорошей команды (как я, опять же, написал в самом первом комментарии) — люди довольны, работают в охотку, получают за это хорошие деньги, а при увеличении нагрузки (расширении полномочий и ответственности) — тут же получают надбавку, которая их устраивает. Без необходимости сообщать что-то CTO, потому что хороший CTO это знает и видит. Если за прибавкой надо ходить — это говно, а не CTO; если разработчик сообщает «могу вот в полную силу работать, если мне заплатят больше» — это говно, а не разработчик.
Я не знаю, как разжевать эту бесхитростную мысль дальше.
Вы проецируете свои ожидания и ощущения на всех остальных
Нет.
при этом работодатель у вас умный и добрый
Нет.
средний разработчик (к которым вы себя не относите) не особо.
Нет (нет).
Дальше уже бессмысленно; мы явно разговариваем на разных языках, выторговывайте, сбегайте от красных CTO, что там еще — я лично буду только рад за вас.
«никто не решил и никто вокруг решить не может» это вы про FX Risk Management?
Я занимаюсь технической стороной вопроса на низком уровне, там предметная область вообще никакого значения не имеет.
разработчик говорит что хочет получать больше и предлагает пересмотреть свои обязанности, чтобы его работа приносила больше пользы
Очень странно ожидать такого прозрения от разработчика. Это прямая обязанность CTO и его помощников.
я так понимаю дело не в лояльности работодателю (было бы странно жертвовать своими интересами/временем ради чужих)
На 80% в лояльности работодателю. Не понимаю, с чего вы взяли, что я чем-то жертвую, и что работодатель — всенепременно «чужой». Во-первых, я уже не голодаю, а человек я не очень притязательный. Во-вторых, я работаю на позиции «principal engineer», тут смена работы уже равнозначна трем переездам (девяти пожарам). Еще я много времени уделяю OSS, веду внутренние курсы повышения квалификации, решаю действительно интересные задачи, которые вообще стали реальностью именно благодаря лояльности компании ко мне. Не вижу причин не платить им тем же. Я теоретически могу фигачить простой код километрами, но я не хочу этим заниматься; мне нравится решать то, что пока никто не решил и никто вокруг решить не может.
Остльные 20% — я не готов ни за какие деньги никуда переезжать, я нашел себе для жизни место моей мечты, а всякая удаленка — это про гораздо более слабые позиции. Теоретически можно было бы подумать о швейцарских альпах, но там нет интересных мне лично технологий, из окна не увидеть рассвет над Средиземным морем, да и не хочется мне жить среди швейцарцев.
В ручном даже лучше, я имел в виду «автоматически, без вмешательства сотрудника, на регулярной основе».
Много может быть факторов, которые компания может исправить, когда сыпятся красные флажки.
Когда сыпятся — да, разумеется; если что-то идет не так на потоке — надо разбираться, очевидно. И, поскольку это очевидно, я говорил про ситуацию «раз в пятилетку один из ста сотрудников приходит клянчить». Надо предотвращать такие оказии, я же в первом абзаце акцентировал на этом внимание: «Сотрудник должен быть доволен [...]». Это первоочередная задача, и исполнение ее не зависит от конкурентов и фазы луны. Но всех не удовлетворишь, и это нормально. Неудовлетворенных надо с миром отпускать.
TL;DR: если сотрудник чем-то недоволен, с ним надо бескомпромиссно расставаться.
Мне кажется, тут все просто. Если сотрудник — просто сотрудник, то я вообще не вижу смысла с ним разговаривать при постановке вопроса «хочу больше денег» (при условии, конечно, что ежегодная индексация и карьерный рост автоматические). Ну, хочешь — иди, в такой ситуации уже все равно что-то подгнило. Сотрудник должен быть доволен задолго до того, как он начнет задумываться о других офферах.
При этом платить выше рынка просто нерентабельно в том смысле, что всегда найдется контора послабее, которой нужен один сильный разработчик, — они его в любом случае перекупят; для них это одна высокая зарплата, для нас — одна из тридцати.
С другой стороны, при конкурентноспособных зарплатах можно прилагать усилия для того, чтобы люди были привязаны нематериальной составляющей (внутренние курсы повышения квалификации, сильная команда, интересные технологии, конференции, и так далее). Мой шеф прекрасно знает, что и я лично регулярно получаю предложения о вдвое-втрое бо́льшей зарплате (это если не рассматривать Долину, там и впятеро дадут хоть сегодня), и большинство коллег, проработавших у нас хотя бы год — точно могут получить завтра от входа от двадцати до ста процентов прибавки к тому, что платим мы. Всем поднять зарплату? — Так себе вариант. Разработчики у нас и сейчас не бедствуют.
Так что после достижения сотрудником определенного уровня — любой разговор о недостатке денег — с оффером ли, без ли — большой красный флажок «что-то пошло не так, пора расстаться, бывает, останемся друзьями».
Навряд ли вышеизложеннеое будет работать для галер, впрочем.
Кому известный? На какие «другие»? Чем именно не похожа?
Раст — всего лишь еще один низкоуровневый язык, появление которого бы вообще никто не заметил, если бы не хайп по типам и не агрессивный маркетинг. Даже Julia извне пузыря — выглядит в разы более продуманной. Через несколько лет спираль сделает очередной изгиб — вот тогда и посмотрим.
Говорить про что-то, в чем сам уже освоился, мол «это сложно,
не всем данокривая обучения особенная» — очень смешно и не очень вежливо. У понимания доказательства гипотезы Римана — кривая действительно крутовата. У очередного говноязыка, каких было и будет сотни — никакой особенной кривой нет, код пописал месяцок — и уже мидл.В точности, как и все без исключения остальные техники проверки корректности более-менее сложного кода.
Ну да, вам ровно про то и говорят же. В точности, как
c++.А ничё, что код, на который вы дали ссылку — уже рекурсивен? Подозреваю, что Rust не сможет вывести тотальность перекрестной рекурсии, поэтому там и появляется хак с псевдобесконечным циклом, переопределением биндинга из внутреннего скоупа и бесчисленными ранними возвратами, превращающими и без того лапшу — в мелкопокрошенное спагетти. Может быть, лучше заняться доведением до ума компилятора, чтобы можно было бы избежать вот таких хаков?
Ну это ответ в духе «все ваши варианты мне не нравятся, поэтому не существуют».
Во-первых, есть куча языков, в которых циклы в принципе не предусмотрены синтаксисом. Во-вторых, в мультипарадигменных языках как-то все более принято заменять циклы на функциональные аналоги типа
map/reduce, или, на худой конец, comprehensions. В-третьих, даже в языках с «родными» циклами, вышеприведенный фрагмент — смердит, и я лично разворачиваю на ревью код, который так волюнтаристски мутирует весь окружающий мир; это нечитаемо и очень подвержено привнесению ошибок впоследствии.А почему она должна существовать? «Покажите замену кода с
gotoна код безgotoи без циклов» — тоже разновидность некорректного безответного вопроса.За что я люблю синтетические примеры, так это за всё.
Я готов поспорить, что когнитивные усилия здесь придется тратить на понимание того, как этот тип заполняется, и зачем вообще автору втемяшилось объявлять такую функцию. После того, как это будет понято, тип сам собой нарисуется.
В простом коде все эти фигурные скобки и отступы считываются мгновенно, а в сложном — основные проблемы чтения связаны далеко не с ними.
Это было бы круто, кабы существовала непротиворечивая корректная шкала оценки синтаксиса. А так, как ее нет, то и определить — ошибка ли это, или суперспособность — возможным не представляется. «Демократичным» голосованием это определять? — Увольте.
Вон там внизу предлагают изменять язык до неузнаваемости, развивать и дополнять, пока количество синтаксического сахара не превысит количество символов на клавиатуре (а потом и в юникоде) — я бы лично не хотел, чтобы над языками издевались таким способом, выбранным по результатам голосования у джаваскриптовиков, которые желают, чтобы все мучались так, как они.
Я лучше уж разочек синтаксис (любой) освою, а потом буду языком пользоваться, а не переучивать семантику каждые полгода.
Абсолютно согласен.
Вообще, обсуждение характеристик синтаксиса (даже если называть их уместными словами с соответствующими значениями, типа «читаемость») — мне непонятно в принципе. Совершенно очевидно, что любой язык (да, и кобол, и сиквел — тоже) превращается из нечитаемого в читаемый по мере погружения.
Когда я еду во Францию, я освежаю в голове всякие «сильвупле» и «мерси», а не говорю, мол, «фу, какой нечитаемый язык, я лучше пару дней буду питаться не в кабаках, а в супермаркетах без кассиров».
Какая вообще нахрен разница, каков синтаксис языка, если он не умеет, например, из коробки задействовать все ядра? А если умеет — ну в чужой монастырь не надо со своим синтаксисом лезть, можно потратить пару часиков на привыкание.
Я почему-то думал, что JS и питон уже написаны, а что такое компилятор интерпретируемого языка — я вообще не очень понимаю.
Ну идрис вот написан на идрисе, он умеет проверить самое себя, в принципе.
Во-первых, так не бывает. Зарплаты так не растут.
Но даже если бы и было — я уже сказал: если разработчик следит за каждым дуновением ветерка, и бегает клянчить каждый раз, как выпал из последнего квартиля — пошел он в жопу (на галеру).
Мы без него обойдемся, а он — ну тут совсем не факт, что ему понравится все то, на что он променял свои 10%.
Мы говорим примерно об одном и том же. Шеф не обязан быть телепатом, и подходить к нему можно, и нужно.
Что шеф обязан, с моей точки зрения — так это не делегировать инициативу поощрения сотрудников самим сотрудникам. Разработчик не должен ходить просить повышать зарплату; разработчик должен ходить предлагать хорошие решения чего бы то ни было (от «давайте-ка я тут тестами позанимаюсь месяцок» до «давайте-ка я вот этот проект буду вести») — а релевантное вознаграждение, устраивающее разработчика — это и есть прямая обязанность шефа.
Иначе попрошайки начнут получать в разы больше прямо завтра.
Ну вот зато вы прям можете гордиться своей суперспособностью критически воспринимать чужую точку зрения, ну а когда не способны, в силу скудости ума и воображения — всегда можно объявить собеседника пафосным тараканом, не способным на развитие.
Я подробно ответил выше, но мой ответ вам не понравился.
Просто наблюдение, к вам не имеющее никакого отношения: леммингам почти никогда не нравится то, что я говорю. Это ни хорошо, ни плохо, если не оправдывать это другими причинами.
Предугадывание и понимание «какие обязанности разработчик может ещё исполнять, чтобы получать больше», продвижение людей по карьерной лестнице, поощрение, поддержание во всех хорошего настроения и удовлетворения зарплатой.
Вообще, в здоровых командах, люди делают сколько хотят и могут — без предварительного шантажа «дай рубль, а то буду как буратино только то, что мне навязали, делать», — а руководство обо всем этом знает, и повышает зарплаты соответственно. Я это назвал «автоматически» в своем самом первом комментарии.
С тех пор меня успели обвинить в том, что я всех вокруг держу за холопов, а сам пригрелся и просто не хочу развиваться. Но тезис от этого не поменялся.
В моем понимании хорошей команды (как я, опять же, написал в самом первом комментарии) — люди довольны, работают в охотку, получают за это хорошие деньги, а при увеличении нагрузки (расширении полномочий и ответственности) — тут же получают надбавку, которая их устраивает. Без необходимости сообщать что-то CTO, потому что хороший CTO это знает и видит. Если за прибавкой надо ходить — это говно, а не CTO; если разработчик сообщает «могу вот в полную силу работать, если мне заплатят больше» — это говно, а не разработчик.
Я не знаю, как разжевать эту бесхитростную мысль дальше.
Нет.
Нет.
Нет (нет).
Дальше уже бессмысленно; мы явно разговариваем на разных языках, выторговывайте, сбегайте от красных CTO, что там еще — я лично буду только рад за вас.
Я занимаюсь технической стороной вопроса на низком уровне, там предметная область вообще никакого значения не имеет.
Очень странно ожидать такую инициативу от разработчика. Это прямая обязанность CTO и его помощников.
Если они не справляются, да, может помочь, но зачем работать с некомпетентными людьми?
Вы только что продемонстрировали, что TL;DR: не работает для людей, не отягощенных умением понять не разжеванную в труху мысль.
Очень странно ожидать такого прозрения от разработчика. Это прямая обязанность CTO и его помощников.
На 80% в лояльности работодателю. Не понимаю, с чего вы взяли, что я чем-то жертвую, и что работодатель — всенепременно «чужой». Во-первых, я уже не голодаю, а человек я не очень притязательный. Во-вторых, я работаю на позиции «principal engineer», тут смена работы уже равнозначна трем переездам (девяти пожарам). Еще я много времени уделяю OSS, веду внутренние курсы повышения квалификации, решаю действительно интересные задачи, которые вообще стали реальностью именно благодаря лояльности компании ко мне. Не вижу причин не платить им тем же. Я теоретически могу фигачить простой код километрами, но я не хочу этим заниматься; мне нравится решать то, что пока никто не решил и никто вокруг решить не может.
Остльные 20% — я не готов ни за какие деньги никуда переезжать, я нашел себе для жизни место моей мечты, а всякая удаленка — это про гораздо более слабые позиции. Теоретически можно было бы подумать о швейцарских альпах, но там нет интересных мне лично технологий, из окна не увидеть рассвет над Средиземным морем, да и не хочется мне жить среди швейцарцев.
В ручном даже лучше, я имел в виду «автоматически, без вмешательства сотрудника, на регулярной основе».
Когда сыпятся — да, разумеется; если что-то идет не так на потоке — надо разбираться, очевидно. И, поскольку это очевидно, я говорил про ситуацию «раз в пятилетку один из ста сотрудников приходит клянчить». Надо предотвращать такие оказии, я же в первом абзаце акцентировал на этом внимание: «Сотрудник должен быть доволен [...]». Это первоочередная задача, и исполнение ее не зависит от конкурентов и фазы луны. Но всех не удовлетворишь, и это нормально. Неудовлетворенных надо с миром отпускать.
Сильная позиция заканчивается примерно там, где начинается ограниченный контракт.
Можно, ту сам экстент.
На самом деле инвариантность преобразований доказывать почти всегда гораздо проще, чем оригинальный пучок лемм.
TL;DR: если сотрудник чем-то недоволен, с ним надо бескомпромиссно расставаться.
Мне кажется, тут все просто. Если сотрудник — просто сотрудник, то я вообще не вижу смысла с ним разговаривать при постановке вопроса «хочу больше денег» (при условии, конечно, что ежегодная индексация и карьерный рост автоматические). Ну, хочешь — иди, в такой ситуации уже все равно что-то подгнило. Сотрудник должен быть доволен задолго до того, как он начнет задумываться о других офферах.
При этом платить выше рынка просто нерентабельно в том смысле, что всегда найдется контора послабее, которой нужен один сильный разработчик, — они его в любом случае перекупят; для них это одна высокая зарплата, для нас — одна из тридцати.
С другой стороны, при конкурентноспособных зарплатах можно прилагать усилия для того, чтобы люди были привязаны нематериальной составляющей (внутренние курсы повышения квалификации, сильная команда, интересные технологии, конференции, и так далее). Мой шеф прекрасно знает, что и я лично регулярно получаю предложения о вдвое-втрое бо́льшей зарплате (это если не рассматривать Долину, там и впятеро дадут хоть сегодня), и большинство коллег, проработавших у нас хотя бы год — точно могут получить завтра от входа от двадцати до ста процентов прибавки к тому, что платим мы. Всем поднять зарплату? — Так себе вариант. Разработчики у нас и сейчас не бедствуют.
Так что после достижения сотрудником определенного уровня — любой разговор о недостатке денег — с оффером ли, без ли — большой красный флажок «что-то пошло не так, пора расстаться, бывает, останемся друзьями».
Навряд ли вышеизложеннеое будет работать для галер, впрочем.