Это зависит от того, какой у вас состав команды. IT - это не только полные команды, но и мелкие группы, в которых либо нет архитектора (минимум, лида), либо какой-то лид есть, но свои функции не выполняет. Поэтому, программисты ходят к бизнесу и узнают, что им там нужно реализовать?
Ну и при любом раскладе, некоторые моменты коммуникации нельзя убрать. Например, приходится общаться с QA, чтобы понять: что не устраивает в выполненной работе? Приходится общаться либо с лидом, либо с бизнесом, чтобы понять суть требований. Да и в любом случае, после сеньора любой грейд можно получить только после прокачки коммуникации.
Однако, абсолютно согласен с тем, что некоторые компании преувеличивают важность софт-скиллов. А некоторые, даже пытаются совсем изжить токсичность, не понимая, что специфика работы программиста подразумевает некоторые токсичные ситуации. Бывает, что работа приводит к небольшим ссорам и спорам. Поэтому, разумеется, токсичность нужно снижать, но не до такой степени, чтобы, например, отказываться от стандартов качества, или от предъявления обоснованных претензий. Самый смак - это когда команда ищет сеньора, но считает его приверженность некоторым стандартам качества на ревью - токсичностью. При том, что проект они только начали делать, и все проблемы с кодом и архитектурой ещë не вскрылись.
Прямым образом относится. Google переводит код с голанг - на раст, пока в блоге Касперского предлагают не рассматривать голанг, и информируют читателей, чем собрать исполняемый файл из пайтон-кода. Собственно, с этого и начинается ветка. Ну, почти: вместо тезиса о переписывании гуглом кода на "Ржавом", я упомянул комментарий АНБ относительно безопасных языков, новость о котором датируется примерно теми же датами, которыми датируются первые упоминания о вливании гуглом бюджета в переписывание кода на раст:
Может, и не разбираюсь, но, если верить публикациям, и если это не первоапрельский розыгрыш, то та же корпорация Google уже форсирует переход на Rust в некоторых командах:
К тому, что в современном мире IT набирает обороты тенденция отхода от языков с низким порогом вхождения, типа Java или Golang - в пользу языков с лучшим управлением памятью. И связано это с многочисленными инцидентами безопасности. Можно вспомнить истории с уязвимостями ЦПУ, когда можно было получить доступ к памяти устройства. Истории с размещением вредоносного кода в репозиториях сверхвысокоуровневых языков (NPM, PyPi). Истории с размещением вредоносного кода в библиотеках, входящих в состав дистрибутивов Linux. Даже, истории с санкциями, когда целому вендору закрывали доступ к репозиторию Google Play. Всё это как бы намекает на то, что вскоре может образоваться тенденция использовать языки с более прозрачным контролем памяти, или языки без обширных неконтролируемых репозиториев, пакеты в которых невозможно проверить ввиду их обилия.
Статья, безусловно, интересная. Просто иронично, что материал о сборке python приложений для их поставки на исполняемую машину, выходит в это время. И выходит из-под пера разработчика ОС, позиционирующейся, как безопасный аналог западных решений.
Хочу заметить, что Касперский и Ко написали этот софт, преимущественно, на ЯП, созданных в США, либо, компаниями, работавшими на мин обороны США (AT&T), либо, на языках, компиляторы или интерпретаторы которых были написаны с помощью этих американских языков. Простой пример - язык C, созданный в Лаборатории Белла, которая вышла из AT&T.
Ну, трудно не заниматься эджизмом, когда студент рисует себе в резюме пару лет опыта в вымышленном месте и пытается устроиться к тебе сеньором, только оторвавшись от титьки женского общежития, так сказать.
Правительство США: так, разработчики Америки, отныне мы рекомендуем Вам писать на Rust, вместо Java и Golang, поскольку он является более прозрачным и, следовательно, безопасным, в вопросах использования памяти!
Разработчик Kaspersky OS: так, разработчики России, сейчас я вас научу, как можно запихнуть ваш python код в экзешник и выполнить на любом компе!
Формально, да, грани между языками по типу исполнения стираются. Но, прошу обратить внимание, что если вы на собесе зададите этот вопрос кандидату, он сможет перевернуть его в свою пользу чисто психологически. Просто компиляция может быть этапом интерпретации. Ключевое здесь, всë-таки - это запуск программы. Интерпретируемые языки выполняются при помощи интерпретатора при каждом запуске. Даже если вы соберëте .exe, в нëм будет ваша программа, + код интерпретатора для запуска. А компилируемую программу можно переносить и запускать независимо от наличия компилятора на целевой машине.
Плюс, JIT компиляция не перестаëт быть промежуточной. Она, точно так же, выполняется между запуском интерпретатора и выполнением кода на виртуальной машине. Просто она не хранит .pyc файлы на диске, и не производит компиляцию заранее. Если вы будете пытаться рассказать кандидату, понимающему это, про то, что JIT- компиляция - не промежуточная, то, боюсь, вы потеряете этого кандидата.
Почему я спорю? Наверное, потому, что вопрос про компилируемость Python - это очень популярный маячок, показывающий приверженность разработчика к хайповым высказываниям без проверки истинности. Все сейчас носятся с этим бредовым "Python - компилируемый язык, вы слыхали"?! Хотя, тут достаточно начать спрашивать про то, какие бывают типы интерпретаторов, и почему интерпретаторы компилируемого типа не перестают быть интерпретаторами? Вот это, действительно серьёзные вопросы. Несколько фактов, которые я вам привëл, в частности, о том, что интерпретируемый язык не позволяет собрать программу для запуска без библиотек интерпретатора, в принципе, уже вывели вас из себя и вынудили увести разговор в сторону от спора.
JIT компилятор - это тоже одна из особенностей реализации интерпретатора компилирующего типа. Ключевой момент здесь - CPython (интерпретатор) перешëл на использование JIT компиляции. Вот когда CPython станет компилятором, тогда можете говорить, что Python - компилируемый язык. Потому, что код, написанный на нëм, перед запуском, будет компилироваться в байт-код и кладываться в библиотечки, а потом они будут выполняться при запуске исполняемого файла. А сейчас программа на Python запускается по-умолчанию интерпретатором Python. Нельзя взять файлы .pyc, перенести на другую машину с аналогичной архитектурой и выполнить их без интерпретатора. Поэтому, язык и называется интерпретируемым.
Python - это интерпретируемый язык, основной (дефолтный) интерпретатор которого, относится к типу компилирующих. То, что интерпретатор производит промежуточную компиляцию перед выполнением на виртуальной машине, не делает язык компилируемым. Это как наличие ног: оно не превращает вас в танцора.
Я так понимаю, у Сбера есть различные проекты в области IT, и на самые массовые, с точки зрения команд, они активно набирают джунов и студентов. По крайней мере, один мой знакомый "вкатившийся" коллега начинал со Сбера. И это начало, как я понял, было не слишком приятным и успешным с точки зрения опыта.
Поэтому, после очередной волны сокращений, либо, волны увольнений по собственному, Сбер стабильно бомбардирует рынок молодым мясом. Ну и от коллег я слышал не раз, как им доводилось с этими "воспитанниками сбера" общаться на собеседованиях. И, в большинстве случаев, я слышал именно негативные оценки людям, вышедшим с трамплинных проектов Сбера. Не спорю, что у банка есть много иных проектов, в которых задействованы прекрасные специалисты, но ситуация здесь напоминает проблему шотландца, который не может понять, почему его не называют "Мак-Фларен, Строитель Мельниц"?
Не знаю: несколько лет сидел на арче. Потом, перешëл на Manjaro. Arch - это, в большей степени, идея о том, что инструмент не должен диктовать свои правила. Manjaro нарушает эту концепцию, но я не скажу, что она прям-таки юзабельная. Скорее, привлекательная, как философия. Но, когда тебе нужна система с кучей софта для работы (включая коммуникацию), абсолютно бесполезная. Поскольку, хочешь, не хочешь, а софт, который требует поставить работодатель уже тебя контролиоует.
Поэтому, сейчас я вообще сижу на винде. Манджаро стоит второй системой.
А вы, вместо того, чтобы признать факт, стали заниматься откровенным враньëм, пытаясь нивелировать значение официального документа. Не вижу смысла разговаривать с манипулятором и лжецом.
Это зависит от того, какой у вас состав команды. IT - это не только полные команды, но и мелкие группы, в которых либо нет архитектора (минимум, лида), либо какой-то лид есть, но свои функции не выполняет. Поэтому, программисты ходят к бизнесу и узнают, что им там нужно реализовать?
Ну и при любом раскладе, некоторые моменты коммуникации нельзя убрать. Например, приходится общаться с QA, чтобы понять: что не устраивает в выполненной работе? Приходится общаться либо с лидом, либо с бизнесом, чтобы понять суть требований. Да и в любом случае, после сеньора любой грейд можно получить только после прокачки коммуникации.
Однако, абсолютно согласен с тем, что некоторые компании преувеличивают важность софт-скиллов. А некоторые, даже пытаются совсем изжить токсичность, не понимая, что специфика работы программиста подразумевает некоторые токсичные ситуации. Бывает, что работа приводит к небольшим ссорам и спорам. Поэтому, разумеется, токсичность нужно снижать, но не до такой степени, чтобы, например, отказываться от стандартов качества, или от предъявления обоснованных претензий. Самый смак - это когда команда ищет сеньора, но считает его приверженность некоторым стандартам качества на ревью - токсичностью. При том, что проект они только начали делать, и все проблемы с кодом и архитектурой ещë не вскрылись.
Прямым образом относится. Google переводит код с голанг - на раст, пока в блоге Касперского предлагают не рассматривать голанг, и информируют читателей, чем собрать исполняемый файл из пайтон-кода. Собственно, с этого и начинается ветка. Ну, почти: вместо тезиса о переписывании гуглом кода на "Ржавом", я упомянул комментарий АНБ относительно безопасных языков, новость о котором датируется примерно теми же датами, которыми датируются первые упоминания о вливании гуглом бюджета в переписывание кода на раст:
https://habr.com/ru/news/796901/
Хабр, видимо превратился в Одноклассники, если местным звëздам, залайканным пенсионерами, приходится объяснять каждый панч.
Может, и не разбираюсь, но, если верить публикациям, и если это не первоапрельский розыгрыш, то та же корпорация Google уже форсирует переход на Rust в некоторых командах:
https://www.securitylab.ru/news/547188.php
https://www.opennet.ru/opennews/art.shtml?num=60556
А, учитывая письмо Вашингтона, это выглядит именно как следствие закручивания гаек безопасности в проектах американских компаний.
А ещё, я менее токсичен, чем вы. Несомненный плюс.
К тому, что в современном мире IT набирает обороты тенденция отхода от языков с низким порогом вхождения, типа Java или Golang - в пользу языков с лучшим управлением памятью. И связано это с многочисленными инцидентами безопасности. Можно вспомнить истории с уязвимостями ЦПУ, когда можно было получить доступ к памяти устройства. Истории с размещением вредоносного кода в репозиториях сверхвысокоуровневых языков (NPM, PyPi). Истории с размещением вредоносного кода в библиотеках, входящих в состав дистрибутивов Linux. Даже, истории с санкциями, когда целому вендору закрывали доступ к репозиторию Google Play. Всё это как бы намекает на то, что вскоре может образоваться тенденция использовать языки с более прозрачным контролем памяти, или языки без обширных неконтролируемых репозиториев, пакеты в которых невозможно проверить ввиду их обилия.
Статья, безусловно, интересная. Просто иронично, что материал о сборке python приложений для их поставки на исполняемую машину, выходит в это время. И выходит из-под пера разработчика ОС, позиционирующейся, как безопасный аналог западных решений.
Хочу заметить, что Касперский и Ко написали этот софт, преимущественно, на ЯП, созданных в США, либо, компаниями, работавшими на мин обороны США (AT&T), либо, на языках, компиляторы или интерпретаторы которых были написаны с помощью этих американских языков. Простой пример - язык C, созданный в Лаборатории Белла, которая вышла из AT&T.
Разумеется, преувеличено. Я и не скрывал иронии.
Ну, трудно не заниматься эджизмом, когда студент рисует себе в резюме пару лет опыта в вымышленном месте и пытается устроиться к тебе сеньором, только оторвавшись от титьки женского общежития, так сказать.
Правительство США: так, разработчики Америки, отныне мы рекомендуем Вам писать на Rust, вместо Java и Golang, поскольку он является более прозрачным и, следовательно, безопасным, в вопросах использования памяти!
Разработчик Kaspersky OS: так, разработчики России, сейчас я вас научу, как можно запихнуть ваш python код в экзешник и выполнить на любом компе!
Я ничего не упустил?
Формально, да, грани между языками по типу исполнения стираются. Но, прошу обратить внимание, что если вы на собесе зададите этот вопрос кандидату, он сможет перевернуть его в свою пользу чисто психологически. Просто компиляция может быть этапом интерпретации. Ключевое здесь, всë-таки - это запуск программы. Интерпретируемые языки выполняются при помощи интерпретатора при каждом запуске. Даже если вы соберëте .exe, в нëм будет ваша программа, + код интерпретатора для запуска. А компилируемую программу можно переносить и запускать независимо от наличия компилятора на целевой машине.
Плюс, JIT компиляция не перестаëт быть промежуточной. Она, точно так же, выполняется между запуском интерпретатора и выполнением кода на виртуальной машине. Просто она не хранит .pyc файлы на диске, и не производит компиляцию заранее. Если вы будете пытаться рассказать кандидату, понимающему это, про то, что JIT- компиляция - не промежуточная, то, боюсь, вы потеряете этого кандидата.
Почему я спорю? Наверное, потому, что вопрос про компилируемость Python - это очень популярный маячок, показывающий приверженность разработчика к хайповым высказываниям без проверки истинности. Все сейчас носятся с этим бредовым "Python - компилируемый язык, вы слыхали"?! Хотя, тут достаточно начать спрашивать про то, какие бывают типы интерпретаторов, и почему интерпретаторы компилируемого типа не перестают быть интерпретаторами? Вот это, действительно серьёзные вопросы. Несколько фактов, которые я вам привëл, в частности, о том, что интерпретируемый язык не позволяет собрать программу для запуска без библиотек интерпретатора, в принципе, уже вывели вас из себя и вынудили увести разговор в сторону от спора.
JIT компилятор - это тоже одна из особенностей реализации интерпретатора компилирующего типа. Ключевой момент здесь - CPython (интерпретатор) перешëл на использование JIT компиляции. Вот когда CPython станет компилятором, тогда можете говорить, что Python - компилируемый язык. Потому, что код, написанный на нëм, перед запуском, будет компилироваться в байт-код и кладываться в библиотечки, а потом они будут выполняться при запуске исполняемого файла. А сейчас программа на Python запускается по-умолчанию интерпретатором Python. Нельзя взять файлы .pyc, перенести на другую машину с аналогичной архитектурой и выполнить их без интерпретатора. Поэтому, язык и называется интерпретируемым.
Python - это интерпретируемый язык, основной (дефолтный) интерпретатор которого, относится к типу компилирующих. То, что интерпретатор производит промежуточную компиляцию перед выполнением на виртуальной машине, не делает язык компилируемым. Это как наличие ног: оно не превращает вас в танцора.
Я так понимаю, у Сбера есть различные проекты в области IT, и на самые массовые, с точки зрения команд, они активно набирают джунов и студентов. По крайней мере, один мой знакомый "вкатившийся" коллега начинал со Сбера. И это начало, как я понял, было не слишком приятным и успешным с точки зрения опыта.
Поэтому, после очередной волны сокращений, либо, волны увольнений по собственному, Сбер стабильно бомбардирует рынок молодым мясом. Ну и от коллег я слышал не раз, как им доводилось с этими "воспитанниками сбера" общаться на собеседованиях. И, в большинстве случаев, я слышал именно негативные оценки людям, вышедшим с трамплинных проектов Сбера. Не спорю, что у банка есть много иных проектов, в которых задействованы прекрасные специалисты, но ситуация здесь напоминает проблему шотландца, который не может понять, почему его не называют "Мак-Фларен, Строитель Мельниц"?
Это вы ещë, уважаемый, мальчиков с бэкграундом Сбера не собеседовали.
Ну, как игрушка? Скомпилить ради практики или самостоятельного исследования ядра - почему бы нет?
Выглядит так, будто вы ничего не знаете, но везде лезете.
Единственное, что не меняется - это отношение к пользователям Gentoo. Ты их уважаешь и считаешь психбольными одновременно.
Не знаю: несколько лет сидел на арче. Потом, перешëл на Manjaro. Arch - это, в большей степени, идея о том, что инструмент не должен диктовать свои правила. Manjaro нарушает эту концепцию, но я не скажу, что она прям-таки юзабельная. Скорее, привлекательная, как философия. Но, когда тебе нужна система с кучей софта для работы (включая коммуникацию), абсолютно бесполезная. Поскольку, хочешь, не хочешь, а софт, который требует поставить работодатель уже тебя контролиоует.
Поэтому, сейчас я вообще сижу на винде. Манджаро стоит второй системой.
А вы, вместо того, чтобы признать факт, стали заниматься откровенным враньëм, пытаясь нивелировать значение официального документа. Не вижу смысла разговаривать с манипулятором и лжецом.
То есть, ответа у вас нет. И к чему тогда вся эта демагогия?