Я скорее про то, что порог входа для новичков может приподняться слишком крутым и неприятным образом, потому что раньше надо было конкурировать с такими же новичками, а теперь ещё и с железным конём. Причем учиться самостоятельно мыслить станет сложнее.
Но поживем увидим, я не очень уверен в своих же прогнозах. Может напротив всё станет как в старые добрые с зелёной травой: в профессии снова смогут закрепляться только те, кто горят инженерным делом и качество среднего человеческого материала вырастет.
Для питона шаг наверное очень правильный, но всё равно звучит слабенько. Да, can benefit without JIT, но без возможности убер-оптимизаций связанных с инлайном, питон всё равно будет оставаться неприлично медленным.
Не уверен, откуда цифры про удесетирять, и не уверен в её правомерности. Впрочем, интерпретатор питона тоже довольно примитивен в сравнении, например, с джавовым.
Это бессмысленно. Для любого эффективного JIT нужно считать статистику. Если вы уже имеете на руках статистику - поставить trap для редких случаев тривиально. Инлайн всё равно нужно уметь делать, иначе всё будет медленно, т.к. именно инлайн открывает пути к другим оптимизациям (убрать дублирующиеся проверки, выкинуть аллокацию неиспользуемых объектов, разложить по стеку то, что не убегает за пределы скоупа и т.д.). Хотите чтобы работало быстро - нужен нормальный JIT. Иначе всё мёртвому припарки.
Предположим, адепты билдеров фабрик везде объявляют интерфейсы. Вызов интерфейсного метода очень похож на вызов в динамическом языке: нужно сделать перебор по иерархии, чтобы найти имплементацию.
Но JIT ведёт статистику, и если в какой-то метод приходит (почти) только одна имплементация (или две, для двух тоже есть оптимизация) - JIT поставит специальную ловушку на случай "а что если нет", в которой проводит деоптимизацию (на самом деле не совсем так, но в первом приближении пойдет). Для нормального же случая код будет работать так, будто был объявлен конкретный класс, вызовы будет дозволено инлайнить и проводить все возможные оптимизации.
Теоретически, для питона никто не мешает делать так же. На практике же JIT питона просто находится в совершенно зачаточном состоянии.
По ощущениям, инженеры, понимающие, как работает ассемблер и основные концепции работы современных процессоров, никуда не делись. Просто появились и другие тоже. Не думаю, что это проблема.
Ну нет, действительно некоторые настолько не умеют писать код, что лучше нейронка. Особенно на рутинных задачах. К сожалению, ситуация встречается всё чаще, и у меня есть сомнения, что это связано с ростом качества нейронок, а не с деградацией качества мясных мешков.
Наткнутся на ситуацию, когда производительность пострадает от дополнительных вызовов хоть и возможно, но крайне непросто. Сначала все мелкие вызовы синлайнит компилятор. Затем, если этого не произошло, при исполнении горячего кода всё пролезет в кэши, что частично компенсирует проблему.
Разумеется, бывает всякое, но экономить вызовы с точки зрения производительности бывает разумным крайне редко.
Люди разные. Для вас это не выглядит бюрократией и инструментом контроля. А для меня только так и выглядит. Формальность принципиально для меня не может вызывать доверия. Вы сами тут же говорите, что это "фильтр включенности" и что это вопрос продуктивности.
На моей практике, доверительные отношения выстраиваются с теми руководителями, которые отменяют бюрократию и формальности.
Для меня сам факт регулярного 1-1 уже напряжно. Я предпочитаю иррегулярные встречи без явной повестки. И сам это практиковал, когда был лидом. Безусловно, сам руководитель это всё для себя как-то формализует и держит руку на пульсе, и может строить любые таблички и что угодно, а не разделяет эту ответственность с подчинённым.
Самое главное - обсудить, почему без сменки и перенести встречу.
При том, что неформальные вещи автор, как мне кажется, в целом передает верно, но уже на этапе первой же анкеты я бы обдумал смену работы. Такая формализация личного общения точно не по мне.
Я скорее про то, что порог входа для новичков может приподняться слишком крутым и неприятным образом, потому что раньше надо было конкурировать с такими же новичками, а теперь ещё и с железным конём. Причем учиться самостоятельно мыслить станет сложнее.
Но поживем увидим, я не очень уверен в своих же прогнозах. Может напротив всё станет как в старые добрые с зелёной травой: в профессии снова смогут закрепляться только те, кто горят инженерным делом и качество среднего человеческого материала вырастет.
Ну на наш век конечно хватит, а вот за молодняк обидно. Им теперь вайти в айти будет сильно тяжелее. Ну или мне просто так кажется.
Нет, спасибо, я напротив считаю, что питон не нужон и должен умереть)
Жаль только мир считает иначе)
Для питона шаг наверное очень правильный, но всё равно звучит слабенько. Да, can benefit without JIT, но без возможности убер-оптимизаций связанных с инлайном, питон всё равно будет оставаться неприлично медленным.
Не уверен, откуда цифры про удесетирять, и не уверен в её правомерности. Впрочем, интерпретатор питона тоже довольно примитивен в сравнении, например, с джавовым.
Это бессмысленно. Для любого эффективного JIT нужно считать статистику. Если вы уже имеете на руках статистику - поставить trap для редких случаев тривиально. Инлайн всё равно нужно уметь делать, иначе всё будет медленно, т.к. именно инлайн открывает пути к другим оптимизациям (убрать дублирующиеся проверки, выкинуть аллокацию неиспользуемых объектов, разложить по стеку то, что не убегает за пределы скоупа и т.д.). Хотите чтобы работало быстро - нужен нормальный JIT. Иначе всё мёртвому припарки.
В Java сделано иначе (хоть и для других целей).
Предположим, адепты билдеров фабрик везде объявляют интерфейсы. Вызов интерфейсного метода очень похож на вызов в динамическом языке: нужно сделать перебор по иерархии, чтобы найти имплементацию.
Но JIT ведёт статистику, и если в какой-то метод приходит (почти) только одна имплементация (или две, для двух тоже есть оптимизация) - JIT поставит специальную ловушку на случай "а что если нет", в которой проводит деоптимизацию (на самом деле не совсем так, но в первом приближении пойдет). Для нормального же случая код будет работать так, будто был объявлен конкретный класс, вызовы будет дозволено инлайнить и проводить все возможные оптимизации.
Теоретически, для питона никто не мешает делать так же. На практике же JIT питона просто находится в совершенно зачаточном состоянии.
Я не знаю какой продакшн у вас, но за 20 лет ни я не бил, ни меня не били за switch.
Да и во многих случаях switch читается/дебажится/поддерживается лучше, чем потуги в полиморфизм на пустом месте.
По ощущениям, инженеры, понимающие, как работает ассемблер и основные концепции работы современных процессоров, никуда не делись. Просто появились и другие тоже. Не думаю, что это проблема.
Это банально дольше, чем писать самому.
Ну нет, действительно некоторые настолько не умеют писать код, что лучше нейронка. Особенно на рутинных задачах. К сожалению, ситуация встречается всё чаще, и у меня есть сомнения, что это связано с ростом качества нейронок, а не с деградацией качества мясных мешков.
Всё верно, поэтому цепочка и закончилась на "своем государстве". Впрочем, тут предлагают отдельную планету, звучит неплохо.
Я, разумеется, не серьёзно, но если продолжать, то зависит от того, на какое время. Если раз лет в 50 повторять, то отличный план же!
Есть ощущение, что и этого недостаточно.
Пора делать свой интернет, со своими мессенджерами, облаками и государством...
По моим ощущениям, баланс сейчас идеален. Ещё более foolproof реализовывать разумно на стороне фреймворков и библиотек.
Со временем все адаптируются, а пока да, будет большое количество краевых случаев.
Наткнутся на ситуацию, когда производительность пострадает от дополнительных вызовов хоть и возможно, но крайне непросто. Сначала все мелкие вызовы синлайнит компилятор. Затем, если этого не произошло, при исполнении горячего кода всё пролезет в кэши, что частично компенсирует проблему.
Разумеется, бывает всякое, но экономить вызовы с точки зрения производительности бывает разумным крайне редко.
Не разделяю ваших ценностей, но разделяю выводы)
Люди разные. Для вас это не выглядит бюрократией и инструментом контроля. А для меня только так и выглядит. Формальность принципиально для меня не может вызывать доверия. Вы сами тут же говорите, что это "фильтр включенности" и что это вопрос продуктивности.
На моей практике, доверительные отношения выстраиваются с теми руководителями, которые отменяют бюрократию и формальности.
Для меня сам факт регулярного 1-1 уже напряжно. Я предпочитаю иррегулярные встречи без явной повестки. И сам это практиковал, когда был лидом. Безусловно, сам руководитель это всё для себя как-то формализует и держит руку на пульсе, и может строить любые таблички и что угодно, а не разделяет эту ответственность с подчинённым.
Самое главное - обсудить, почему без сменки и перенести встречу.
При том, что неформальные вещи автор, как мне кажется, в целом передает верно, но уже на этапе первой же анкеты я бы обдумал смену работы. Такая формализация личного общения точно не по мне.