Формально, да, грани между языками по типу исполнения стираются. Но, прошу обратить внимание, что если вы на собесе зададите этот вопрос кандидату, он сможет перевернуть его в свою пользу чисто психологически. Просто компиляция может быть этапом интерпретации. Ключевое здесь, всë-таки - это запуск программы. Интерпретируемые языки выполняются при помощи интерпретатора при каждом запуске. Даже если вы соберëте .exe, в нëм будет ваша программа, + код интерпретатора для запуска. А компилируемую программу можно переносить и запускать независимо от наличия компилятора на целевой машине.
Плюс, JIT компиляция не перестаëт быть промежуточной. Она, точно так же, выполняется между запуском интерпретатора и выполнением кода на виртуальной машине. Просто она не хранит .pyc файлы на диске, и не производит компиляцию заранее. Если вы будете пытаться рассказать кандидату, понимающему это, про то, что JIT- компиляция - не промежуточная, то, боюсь, вы потеряете этого кандидата.
Почему я спорю? Наверное, потому, что вопрос про компилируемость Python - это очень популярный маячок, показывающий приверженность разработчика к хайповым высказываниям без проверки истинности. Все сейчас носятся с этим бредовым "Python - компилируемый язык, вы слыхали"?! Хотя, тут достаточно начать спрашивать про то, какие бывают типы интерпретаторов, и почему интерпретаторы компилируемого типа не перестают быть интерпретаторами? Вот это, действительно серьёзные вопросы. Несколько фактов, которые я вам привëл, в частности, о том, что интерпретируемый язык не позволяет собрать программу для запуска без библиотек интерпретатора, в принципе, уже вывели вас из себя и вынудили увести разговор в сторону от спора.
JIT компилятор - это тоже одна из особенностей реализации интерпретатора компилирующего типа. Ключевой момент здесь - CPython (интерпретатор) перешëл на использование JIT компиляции. Вот когда CPython станет компилятором, тогда можете говорить, что Python - компилируемый язык. Потому, что код, написанный на нëм, перед запуском, будет компилироваться в байт-код и кладываться в библиотечки, а потом они будут выполняться при запуске исполняемого файла. А сейчас программа на Python запускается по-умолчанию интерпретатором Python. Нельзя взять файлы .pyc, перенести на другую машину с аналогичной архитектурой и выполнить их без интерпретатора. Поэтому, язык и называется интерпретируемым.
Python - это интерпретируемый язык, основной (дефолтный) интерпретатор которого, относится к типу компилирующих. То, что интерпретатор производит промежуточную компиляцию перед выполнением на виртуальной машине, не делает язык компилируемым. Это как наличие ног: оно не превращает вас в танцора.
Я так понимаю, у Сбера есть различные проекты в области IT, и на самые массовые, с точки зрения команд, они активно набирают джунов и студентов. По крайней мере, один мой знакомый "вкатившийся" коллега начинал со Сбера. И это начало, как я понял, было не слишком приятным и успешным с точки зрения опыта.
Поэтому, после очередной волны сокращений, либо, волны увольнений по собственному, Сбер стабильно бомбардирует рынок молодым мясом. Ну и от коллег я слышал не раз, как им доводилось с этими "воспитанниками сбера" общаться на собеседованиях. И, в большинстве случаев, я слышал именно негативные оценки людям, вышедшим с трамплинных проектов Сбера. Не спорю, что у банка есть много иных проектов, в которых задействованы прекрасные специалисты, но ситуация здесь напоминает проблему шотландца, который не может понять, почему его не называют "Мак-Фларен, Строитель Мельниц"?
Не знаю: несколько лет сидел на арче. Потом, перешëл на Manjaro. Arch - это, в большей степени, идея о том, что инструмент не должен диктовать свои правила. Manjaro нарушает эту концепцию, но я не скажу, что она прям-таки юзабельная. Скорее, привлекательная, как философия. Но, когда тебе нужна система с кучей софта для работы (включая коммуникацию), абсолютно бесполезная. Поскольку, хочешь, не хочешь, а софт, который требует поставить работодатель уже тебя контролиоует.
Поэтому, сейчас я вообще сижу на винде. Манджаро стоит второй системой.
А вы, вместо того, чтобы признать факт, стали заниматься откровенным враньëм, пытаясь нивелировать значение официального документа. Не вижу смысла разговаривать с манипулятором и лжецом.
Да, да, да. Выше уже один написал, что делал баланс в игре - математика и алгоритмы ему не пригодились. Если бы кто-то сказал, что реализовывал программу для выполнения преобразований Фурье, они бы ответили, что писали такой код, но математика им для этого не потребовалась.
В конце 90-х - нулевых годах Google был точно таким же "рывком". До него были каталоги сайтов. Однако, развитие копипастинга, как способа решения проблем в программировании, связано с наполнением баз StackOverflow и Habr. А как способа прохождения интервью - только с развитием схем удалённого трудоустройства. В 10-х годах, чтобы устроиться в Web-студию, приходилось писать код на листочке, а решение можно было спросить, максимум, у голубя, сидящего за окном.
С одной стороны, может показаться, что поменялось многое: можно устраиваться на работу по скайпу, можно давать примеры нейросети, и она будет находить правильные ответы...
А с другой стороны, ничего не поменялось: программирование как было научной деятельностью, так и осталось. Раньше были Web-мастера, которые собирали сайты мышкой, сейчас есть кодеры, которые работают методом копипасты. Но они не осуществляют научную деятельность в рамках своей работы. Они собирают простые средства автоматизации.
Есть человек, который жарит котлеты во "Вкусно и Точка", есть человек, который готовит блюда в мишленовском ресторане. Они решают похожие задачи, но не эквивалентные. Хотя, казалось бы, техпроцесс приготовления бургеров шагнул далеко вперёд, чтобы заменить собой традиционную готовку вычурных блюд. И, всё-таки, приготовление бургеров - это достаточно автоматизированная деятельность. Она хорошо оптимизируется, и она оплачивается гораздо скромнее, чем деятельность шеф-повара в ресторане. Исчез ли спрос на шеф-поваров? Нет.
Бургер - это идеальная метафора для интеграции. Повар жарит котлету, готовит соус, режет салат, помидоры и сыр. Потом, собирает всё в единую конструкцию и отдаёт клиенту. По сути, деятельность похожа на то, что делают кодеры, пользующиеся StackOverflow или ChatGPT. Получить готовый кусочек кода, интегрировать в готовый продукт, продать клиенту.
Осталось найти ответ на простой вопрос: является ли должность повара во "Вкусно и Точка" пределом ожиданий выпускника кулинарных техникумов и академий? И является ли копипастинг посредством любых поисковых систем или лингвистических моделей пределом ожиданий человека, который идёт писать программы?
Спасибо. Хотелось бы ещë почитать про типизацию в Python. Я еë активно использую, включая дженерики с ограничениями, но русскоязычных статей на эту тему мало. Особенно, в разрезе связи с математикой. На всякий случай, подпишусь.
Вот вы пристали со своими примерами. Ещë с вашего поста о том, что математика не нужна. Раздел математики, определяющий большинство процессов в современном IT, называется "Дискретная математика". Код, который вы пишете на языке программирования, подчиняется правилам логических высказываний.
Пример здесь - любой программный код. Ваши инструкции либо имеют логическое обоснование, либо не имеют.
Графы имеют непосредственное отношение к БД, поскольку ими реализована часть индексов. Вот, например, какой индекс вы будете использовать при поиске по дате в таблице последовательного лога событий? Почему? Каким индексом можно реализовать полнотекстовый поиск, не прибегая к использованию сторонних поисковых движков? Почему индексация в эластике проходит долго и как это исправить? Всë это - логические шарады, которые, так или иначе, решаются дискретной математикой. Вы можете еë не знать, но вы еë применяете каждый день. Просто, если вы еë знаете, то вы применяете еë эффективнее.
Сложность алгоритма - это, по сути, нахождение в уме производной и процесс дифференцирования функции, поскольку именно производная является мерилом любых изменений, а дифференциал показывает как меняется функция при прогнозируемом изменении аргумента (да поправят меня математики). Вы можете не знать всего этого, но вы используете это каждый день, и если вы знаете базу, то вы используете это эффективнее.
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная? Насколько лучше? Допустим, вы видите, что при постоянном приращении числа заказов в бд на 100 в день, через месяц ваш алгоритм, использующий эти записи для отчëта, будет обрабатывать их в сумме на 10 секунд дольше. Откуда вы это видите? Как вы это посчитали? Ну, хорошо, посчитали и посчитали. Теперь, вы идëте к заказчику и говорите: "Насяльника, алгоритм совсем медленный будет, да! Согласуй доработку на 40 часов"! А он вам говорит: "Обоснуйте-ка, Мишель89, оплату вам 40 часов". И, опять, чтобы обосновать выгоду оплаты 40 часов для снижения сложности алгоритма, вам понадобится математика.
В этом прелесть работы человека: мы не машины - мы ошибаемся. Дело не в знании или незнании алгоритма. Как ни странно, мы можем не увидеть такие ошибки не потому, что не знаем теорию алгоритмов, а потому, что банально устали в тот день, когда это писалось.
Однако, я согласен с тезисами статьи. За 12 лет работы в IT, 9 из которых - в области коммерческой разработки, я пришëл к тому, что знания нужны. Знания различных теорий, связанных с IT, знание математики. Потому, что с этими знаниями уровень разработки совсем другой. В нëм минимизирован элемент случайности. Ты смотришь на коллег, которые не обладают базой, и видишь, что они не выбирают правильные пути решения задачи. В то время, как у коллег с базой выбор подхода идентичен тому, что выбрал бы ты. Это радует: так, хотя бы, можно понять, что не сошëл с ума.
Потому, что вокруг тебя целая куча программистов, которые сошли. Один носится с какой-нибудь дикой теорией, что код надо писать только так, как он учит. При этом, никто до сих пор не может начать писать так, как пишет он, поскольку он выбирает стиль и алгоритмы рандомно. Другой кричит, что ему, как сеньор-джуну математика не нужна, и он готов писать статьи на эту тему. И вообще, он много лет работает на одном месте, и работодатель им доволен.
Нет, всë-таки, базу нужно знать. Хотя бы, ради возможности общаться на одном уровне с нормальными инженерами, которые пишут одинаково лаконичный и качественный код. Потому, что в наш век Искусственного Интеллекта, очень трудно найти интеллект. Он заявлен, но его нет. Ни искусственного, ни естественного. Есть только море дезинформации и продвинутые боты типа Chat GPT или Copilot. В этот век не трудно закинуть в сеть какой-нибудь фэйковый материал про алгоритмы, а потом наблюдать, как у этого материала появляются адепты, и как работодатели включают в собесы пункты вопросов, чтобы отсеивать этих адептов.
И, я думаю, всë к этому идëт: скоро многие идеи мира IT превратятся в религиозные догмы. У Лю Цисина псевдонаучная организация "Грани Науки" продвинула идею того, что "физики не существует". Современные авторы хабра пишут, что "математика не нужна". То, о чëм вы говорите - алгоритмы, математика, различные теории, которые входят в минимум для айтишника - они нужны не для того, чтобы вы не совершали ошибок в коде. Вы их, так или иначе, будете совершать. Всë это нужно потому, что программирование - это научный процесс, и все эти базовые вещи - это база научного процесса. Они нужны затем, чтобы вы не занимались лженаукой. Чтобы шли только по пути доказанных теорем. А это, в свою очередь, нужно для того, чтобы ваша деятельность имела положительный результат, была продуктивной и снижала процент случайностей.
Формально, да, грани между языками по типу исполнения стираются. Но, прошу обратить внимание, что если вы на собесе зададите этот вопрос кандидату, он сможет перевернуть его в свою пользу чисто психологически. Просто компиляция может быть этапом интерпретации. Ключевое здесь, всë-таки - это запуск программы. Интерпретируемые языки выполняются при помощи интерпретатора при каждом запуске. Даже если вы соберëте .exe, в нëм будет ваша программа, + код интерпретатора для запуска. А компилируемую программу можно переносить и запускать независимо от наличия компилятора на целевой машине.
Плюс, JIT компиляция не перестаëт быть промежуточной. Она, точно так же, выполняется между запуском интерпретатора и выполнением кода на виртуальной машине. Просто она не хранит .pyc файлы на диске, и не производит компиляцию заранее. Если вы будете пытаться рассказать кандидату, понимающему это, про то, что JIT- компиляция - не промежуточная, то, боюсь, вы потеряете этого кандидата.
Почему я спорю? Наверное, потому, что вопрос про компилируемость Python - это очень популярный маячок, показывающий приверженность разработчика к хайповым высказываниям без проверки истинности. Все сейчас носятся с этим бредовым "Python - компилируемый язык, вы слыхали"?! Хотя, тут достаточно начать спрашивать про то, какие бывают типы интерпретаторов, и почему интерпретаторы компилируемого типа не перестают быть интерпретаторами? Вот это, действительно серьёзные вопросы. Несколько фактов, которые я вам привëл, в частности, о том, что интерпретируемый язык не позволяет собрать программу для запуска без библиотек интерпретатора, в принципе, уже вывели вас из себя и вынудили увести разговор в сторону от спора.
JIT компилятор - это тоже одна из особенностей реализации интерпретатора компилирующего типа. Ключевой момент здесь - CPython (интерпретатор) перешëл на использование JIT компиляции. Вот когда CPython станет компилятором, тогда можете говорить, что Python - компилируемый язык. Потому, что код, написанный на нëм, перед запуском, будет компилироваться в байт-код и кладываться в библиотечки, а потом они будут выполняться при запуске исполняемого файла. А сейчас программа на Python запускается по-умолчанию интерпретатором Python. Нельзя взять файлы .pyc, перенести на другую машину с аналогичной архитектурой и выполнить их без интерпретатора. Поэтому, язык и называется интерпретируемым.
Python - это интерпретируемый язык, основной (дефолтный) интерпретатор которого, относится к типу компилирующих. То, что интерпретатор производит промежуточную компиляцию перед выполнением на виртуальной машине, не делает язык компилируемым. Это как наличие ног: оно не превращает вас в танцора.
Я так понимаю, у Сбера есть различные проекты в области IT, и на самые массовые, с точки зрения команд, они активно набирают джунов и студентов. По крайней мере, один мой знакомый "вкатившийся" коллега начинал со Сбера. И это начало, как я понял, было не слишком приятным и успешным с точки зрения опыта.
Поэтому, после очередной волны сокращений, либо, волны увольнений по собственному, Сбер стабильно бомбардирует рынок молодым мясом. Ну и от коллег я слышал не раз, как им доводилось с этими "воспитанниками сбера" общаться на собеседованиях. И, в большинстве случаев, я слышал именно негативные оценки людям, вышедшим с трамплинных проектов Сбера. Не спорю, что у банка есть много иных проектов, в которых задействованы прекрасные специалисты, но ситуация здесь напоминает проблему шотландца, который не может понять, почему его не называют "Мак-Фларен, Строитель Мельниц"?
Это вы ещë, уважаемый, мальчиков с бэкграундом Сбера не собеседовали.
Ну, как игрушка? Скомпилить ради практики или самостоятельного исследования ядра - почему бы нет?
Выглядит так, будто вы ничего не знаете, но везде лезете.
Единственное, что не меняется - это отношение к пользователям Gentoo. Ты их уважаешь и считаешь психбольными одновременно.
Не знаю: несколько лет сидел на арче. Потом, перешëл на Manjaro. Arch - это, в большей степени, идея о том, что инструмент не должен диктовать свои правила. Manjaro нарушает эту концепцию, но я не скажу, что она прям-таки юзабельная. Скорее, привлекательная, как философия. Но, когда тебе нужна система с кучей софта для работы (включая коммуникацию), абсолютно бесполезная. Поскольку, хочешь, не хочешь, а софт, который требует поставить работодатель уже тебя контролиоует.
Поэтому, сейчас я вообще сижу на винде. Манджаро стоит второй системой.
А вы, вместо того, чтобы признать факт, стали заниматься откровенным враньëм, пытаясь нивелировать значение официального документа. Не вижу смысла разговаривать с манипулятором и лжецом.
То есть, ответа у вас нет. И к чему тогда вся эта демагогия?
Вы не ответили на вопрос: кому или чему мне верить? Стандарту, или случайному человеку в Интернете?
Да, да, да. Выше уже один написал, что делал баланс в игре - математика и алгоритмы ему не пригодились. Если бы кто-то сказал, что реализовывал программу для выполнения преобразований Фурье, они бы ответили, что писали такой код, но математика им для этого не потребовалась.
А вот ГОСТ 19781—90 определяет программирование, как научную деятельность. Кому или чему мне верить? Стандарту, или случайному человеку в Интернете?
В конце 90-х - нулевых годах Google был точно таким же "рывком". До него были каталоги сайтов. Однако, развитие копипастинга, как способа решения проблем в программировании, связано с наполнением баз StackOverflow и Habr. А как способа прохождения интервью - только с развитием схем удалённого трудоустройства. В 10-х годах, чтобы устроиться в Web-студию, приходилось писать код на листочке, а решение можно было спросить, максимум, у голубя, сидящего за окном.
С одной стороны, может показаться, что поменялось многое: можно устраиваться на работу по скайпу, можно давать примеры нейросети, и она будет находить правильные ответы...
А с другой стороны, ничего не поменялось: программирование как было научной деятельностью, так и осталось. Раньше были Web-мастера, которые собирали сайты мышкой, сейчас есть кодеры, которые работают методом копипасты. Но они не осуществляют научную деятельность в рамках своей работы. Они собирают простые средства автоматизации.
Есть человек, который жарит котлеты во "Вкусно и Точка", есть человек, который готовит блюда в мишленовском ресторане. Они решают похожие задачи, но не эквивалентные. Хотя, казалось бы, техпроцесс приготовления бургеров шагнул далеко вперёд, чтобы заменить собой традиционную готовку вычурных блюд. И, всё-таки, приготовление бургеров - это достаточно автоматизированная деятельность. Она хорошо оптимизируется, и она оплачивается гораздо скромнее, чем деятельность шеф-повара в ресторане. Исчез ли спрос на шеф-поваров? Нет.
Бургер - это идеальная метафора для интеграции. Повар жарит котлету, готовит соус, режет салат, помидоры и сыр. Потом, собирает всё в единую конструкцию и отдаёт клиенту. По сути, деятельность похожа на то, что делают кодеры, пользующиеся StackOverflow или ChatGPT. Получить готовый кусочек кода, интегрировать в готовый продукт, продать клиенту.
Осталось найти ответ на простой вопрос: является ли должность повара во "Вкусно и Точка" пределом ожиданий выпускника кулинарных техникумов и академий? И является ли копипастинг посредством любых поисковых систем или лингвистических моделей пределом ожиданий человека, который идёт писать программы?
Спасибо. Хотелось бы ещë почитать про типизацию в Python. Я еë активно использую, включая дженерики с ограничениями, но русскоязычных статей на эту тему мало. Особенно, в разрезе связи с математикой. На всякий случай, подпишусь.
Вот вы пристали со своими примерами. Ещë с вашего поста о том, что математика не нужна. Раздел математики, определяющий большинство процессов в современном IT, называется "Дискретная математика". Код, который вы пишете на языке программирования, подчиняется правилам логических высказываний.
Пример здесь - любой программный код. Ваши инструкции либо имеют логическое обоснование, либо не имеют.
Графы имеют непосредственное отношение к БД, поскольку ими реализована часть индексов. Вот, например, какой индекс вы будете использовать при поиске по дате в таблице последовательного лога событий? Почему? Каким индексом можно реализовать полнотекстовый поиск, не прибегая к использованию сторонних поисковых движков? Почему индексация в эластике проходит долго и как это исправить? Всë это - логические шарады, которые, так или иначе, решаются дискретной математикой. Вы можете еë не знать, но вы еë применяете каждый день. Просто, если вы еë знаете, то вы применяете еë эффективнее.
Сложность алгоритма - это, по сути, нахождение в уме производной и процесс дифференцирования функции, поскольку именно производная является мерилом любых изменений, а дифференциал показывает как меняется функция при прогнозируемом изменении аргумента (да поправят меня математики). Вы можете не знать всего этого, но вы используете это каждый день, и если вы знаете базу, то вы используете это эффективнее.
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная? Насколько лучше? Допустим, вы видите, что при постоянном приращении числа заказов в бд на 100 в день, через месяц ваш алгоритм, использующий эти записи для отчëта, будет обрабатывать их в сумме на 10 секунд дольше. Откуда вы это видите? Как вы это посчитали? Ну, хорошо, посчитали и посчитали. Теперь, вы идëте к заказчику и говорите: "Насяльника, алгоритм совсем медленный будет, да! Согласуй доработку на 40 часов"! А он вам говорит: "Обоснуйте-ка, Мишель89, оплату вам 40 часов". И, опять, чтобы обосновать выгоду оплаты 40 часов для снижения сложности алгоритма, вам понадобится математика.
В этом прелесть работы человека: мы не машины - мы ошибаемся. Дело не в знании или незнании алгоритма. Как ни странно, мы можем не увидеть такие ошибки не потому, что не знаем теорию алгоритмов, а потому, что банально устали в тот день, когда это писалось.
Однако, я согласен с тезисами статьи. За 12 лет работы в IT, 9 из которых - в области коммерческой разработки, я пришëл к тому, что знания нужны. Знания различных теорий, связанных с IT, знание математики. Потому, что с этими знаниями уровень разработки совсем другой. В нëм минимизирован элемент случайности. Ты смотришь на коллег, которые не обладают базой, и видишь, что они не выбирают правильные пути решения задачи. В то время, как у коллег с базой выбор подхода идентичен тому, что выбрал бы ты. Это радует: так, хотя бы, можно понять, что не сошëл с ума.
Потому, что вокруг тебя целая куча программистов, которые сошли. Один носится с какой-нибудь дикой теорией, что код надо писать только так, как он учит. При этом, никто до сих пор не может начать писать так, как пишет он, поскольку он выбирает стиль и алгоритмы рандомно. Другой кричит, что ему, как сеньор-джуну математика не нужна, и он готов писать статьи на эту тему. И вообще, он много лет работает на одном месте, и работодатель им доволен.
Нет, всë-таки, базу нужно знать. Хотя бы, ради возможности общаться на одном уровне с нормальными инженерами, которые пишут одинаково лаконичный и качественный код. Потому, что в наш век Искусственного Интеллекта, очень трудно найти интеллект. Он заявлен, но его нет. Ни искусственного, ни естественного. Есть только море дезинформации и продвинутые боты типа Chat GPT или Copilot. В этот век не трудно закинуть в сеть какой-нибудь фэйковый материал про алгоритмы, а потом наблюдать, как у этого материала появляются адепты, и как работодатели включают в собесы пункты вопросов, чтобы отсеивать этих адептов.
И, я думаю, всë к этому идëт: скоро многие идеи мира IT превратятся в религиозные догмы. У Лю Цисина псевдонаучная организация "Грани Науки" продвинула идею того, что "физики не существует". Современные авторы хабра пишут, что "математика не нужна". То, о чëм вы говорите - алгоритмы, математика, различные теории, которые входят в минимум для айтишника - они нужны не для того, чтобы вы не совершали ошибок в коде. Вы их, так или иначе, будете совершать. Всë это нужно потому, что программирование - это научный процесс, и все эти базовые вещи - это база научного процесса. Они нужны затем, чтобы вы не занимались лженаукой. Чтобы шли только по пути доказанных теорем. А это, в свою очередь, нужно для того, чтобы ваша деятельность имела положительный результат, была продуктивной и снижала процент случайностей.