Какая разница социопат человек или нет, поддерживает ли он ваш псевдо «командный дух» , главное чтобы в своей области разбирался и на людей не кидался)
«Ответственность за результат» — что это значит ? Моя ответственность прописана в документе называемый «трудовой договор» Когда мне пытаются навязать другую ответственность, то это значит, что кто-то другой не выполнил свои обязанности. «Ответственность за результат» может быть только в том случае, когда ты отвечаешь своими деньгами за результат, в ином случае это профанация
«Критическое мышление, Самостоятельность»— ха, ну удачи вам проверить это на собеседование
«Работа на команду» — ага, значит мы перекладываем ответственность за кривые бизнес процессы на разработчика и называем это красивой фразой «работа на команду».
Есть одно правило, когда ответственных за конкретную задачу больше одного, ответственный никто . Это всё равно что говорить «Раз двигатель машины работает плохо, тогда колеса и кузов должен толкать машину вперёд»
Цена ошибки низкая только в своих pet-проектах …В коммерческой разработке, вне зависимости от сложности, цена ошибки огромная )И человек который просто дергает код из интернета и не понимает как он работает, для любого проекта эта мина замедленного действия)
Программист это человек который занимается профессиональной разработкой ПО.
Я бы сказал, что для него как раз soft-skills вторичны , а hard-skills первичны . Для меня очень странные такие посты, такое ощущение что IT это какая-то от отдельная область летающая в космосе….Никто же не пишет что «Инженеру-электронщику или инженеру который занимается разработкой двигателей» не очень важны хардскилы, вот софтскилы рулят , чем же «Инженер по ПО» так сильно отличается ?
Это первое, второе статья содержит логическую ошибку, а именно «Хороший разработчик разберётся»…У хорошего разработчика как раз будет перевес в сторону hard-навыков , soft-навыки просто достаточно на уровне «адекватного человека», для всего остального есть всякие срам-мастера и менеджеры
Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть как типа данных "значительно уступает" Даже у вас в банке, как много сервисов написанных не на python ?
В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
Ключевое преимущество языков с динамической типизацией — скорость разработки.
В целом да, на себе ощутил, что накидать прототип быстрее . Но, если выйти за пределы прототипирования, то скорость разработки (учитывая классные, современные framework-и) будет сравнима (для Java это Spring ). В целом python классный инструмент, у нас он очень активно используется для инфраструктуры, но весь бэк на java был есть и будет)Чему я очень рад)
P.S Вполне возможно, что я не прав и просто хочу из python сделать java ))
Да, но это лишь «подсказки типов данных», мне бы конечно хотелось бы, чтобы статическая типизация была по умолчанию, а динамическая опциональная (как в C# )
Нет, иногда действительно показываются методы которые в реальности не существуют у объекта , сам с таким сталкивался при работе с внешней библиотекой )
Ага, особенно прикольно когда стоит Any или подсказки по типу нет из-за старой версии библиотеки ) Непонятно зачем нужны такие костыли, если есть нормальная статическая типизация и опциональная динамическая (в C# она неплохо реализована)
Для быстрого создания прототипов или небольших приложений хороший инструмент , но динамическая типизация в большинстве случаев это зло. Аргумент «динамическая типизация» позволяет писать меньше кода — правда,но лишь отчасти, разницу в размере кода будет компенсировано большим количеством тестов.
Это единственный (на мой взгляд), но очень серьезный недостаток, который не позволяет python конкурировать с java или C#
P.S
Забавно, я не встречал статей «Java — серьезный язык …» или «C# — серьезный язык …»
Go хороший инструмент для примитивных сервисов где требуется хорошая паррарельность задач. Он не конкурент языкам из категории main-stream , но может успешно применяться для отдельных микросервисов …
Статьи про этот язык, часто вызывают срач в комментариях , потому-что люди думают, что этот инструмент некая волшебная пуля от всех бед и начинают использовать его там где это не нужно. Ну серьезно, вы же не забиваете гвозди с помощью отвертки ?
Представляете сколько будет стоить собрать архитектуру проекта с нуля ? Не совсем понятна связь между клиентской базой и архитектурой . Современные облачные платформы позволяют масштабировать ваши сервисы практически под любую нагрузку.
1)Почему python ? Разве не лучше выбрать такие инструменты как Java или С# , статическая типизация и лучшая поддержка многопоточности, то что надо для нагрузок.
2) «С точки зрения бэкенда это означает постоянную перекройку внутренней инфраструктуры» эээ…Ну мягко говоря это очень плохо…И главное, зачем ?
А современный …Это какого года выпуска ?)
Какая разница социопат человек или нет, поддерживает ли он ваш псевдо «командный дух» , главное чтобы в своей области разбирался и на людей не кидался)
«Ответственность за результат» — что это значит ? Моя ответственность прописана в документе называемый «трудовой договор» Когда мне пытаются навязать другую ответственность, то это значит, что кто-то другой не выполнил свои обязанности. «Ответственность за результат» может быть только в том случае, когда ты отвечаешь своими деньгами за результат, в ином случае это профанация
«Критическое мышление, Самостоятельность»— ха, ну удачи вам проверить это на собеседование
«Работа на команду» — ага, значит мы перекладываем ответственность за кривые бизнес процессы на разработчика и называем это красивой фразой «работа на команду».
Есть одно правило, когда ответственных за конкретную задачу больше одного, ответственный никто . Это всё равно что говорить «Раз двигатель машины работает плохо, тогда колеса и кузов должен толкать машину вперёд»
Цена ошибки низкая только в своих pet-проектах …В коммерческой разработке, вне зависимости от сложности, цена ошибки огромная )И человек который просто дергает код из интернета и не понимает как он работает, для любого проекта эта мина замедленного действия)
Просто этот компонент джавист писал))
да, с менеджментом в IT часто полный швах…
Программист это человек который занимается профессиональной разработкой ПО.
Я бы сказал, что для него как раз soft-skills вторичны , а hard-skills первичны . Для меня очень странные такие посты, такое ощущение что IT это какая-то от отдельная область летающая в космосе….Никто же не пишет что «Инженеру-электронщику или инженеру который занимается разработкой двигателей» не очень важны хардскилы, вот софтскилы рулят , чем же «Инженер по ПО» так сильно отличается ?
Это первое, второе статья содержит логическую ошибку, а именно «Хороший разработчик разберётся»…У хорошего разработчика как раз будет перевес в сторону hard-навыков , soft-навыки просто достаточно на уровне «адекватного человека», для всего остального есть всякие срам-мастера и менеджеры
Цитата была действительно неверная, прошу прощения !
Надеюсь python будет расти и здравствовать и составлять достойную конкуренцию Java и C# , как не крути единственный путь развития это конкуренция )
Спасибо за статью и за доп.информацию о типизации)
P.S
Возможно Graal VM даст хороший толчок для развития python в корпоративном сегменте )
Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть как типа данных "значительно уступает"
Даже у вас в банке, как много сервисов написанных не на python ?
Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
В целом да, на себе ощутил, что накидать прототип быстрее . Но, если выйти за пределы прототипирования, то скорость разработки (учитывая классные, современные framework-и) будет сравнима (для Java это Spring ). В целом python классный инструмент, у нас он очень активно используется для инфраструктуры, но весь бэк на java был есть и будет)Чему я очень рад)
P.S
Вполне возможно, что я не прав и просто хочу из python сделать java ))
Да, но это лишь «подсказки типов данных», мне бы конечно хотелось бы, чтобы статическая типизация была по умолчанию, а динамическая опциональная (как в C# )
Вот согласен !
В ML и DS прекрасно могли себя чувствовать C# и Java )Но, к сожалению эти языки не так добры к новичкам)
Ну это всего лишь подсказки по типу , это если и шаг в сторону типизации то очень маленький и незначительный)
В целом это костыль, мое личное убеждение , что должна быть статическая типизация и опционально динамическая,но не наоборот )
Нет, иногда действительно показываются методы которые в реальности не существуют у объекта , сам с таким сталкивался при работе с внешней библиотекой )
Ага, особенно прикольно когда стоит Any или подсказки по типу нет из-за старой версии библиотеки ) Непонятно зачем нужны такие костыли, если есть нормальная статическая типизация и опциональная динамическая (в C# она неплохо реализована)
Да … ничем не хуже) Есть случаи когда полезна динамическая типизация (например для прототипов, devOps, аналитики )
Мне забавно читать про «многословность» …прям представляю разработчика который сидит и считает слова и буквы в коде)))
Имел опыт разработки на python после java .
Для быстрого создания прототипов или небольших приложений хороший инструмент , но динамическая типизация в большинстве случаев это зло. Аргумент «динамическая типизация» позволяет писать меньше кода — правда,но лишь отчасти, разницу в размере кода будет компенсировано большим количеством тестов.
Это единственный (на мой взгляд), но очень серьезный недостаток, который не позволяет python конкурировать с java или C#
P.S
Забавно, я не встречал статей «Java — серьезный язык …» или «C# — серьезный язык …»
Ну , тут с вами можно поспорить основываясь на данных с hh .
-Бэкенд плотно заняли : Java, Python и C# , уже написано куча кода и библиотек …Переписывать это без крайней необходимости не будут
-DevOps : Python тут вообще король, такое количество библиотек и инструментов
-Системное программирование: C/C++ наше всё)
Go силен своей многопоточной моделью, корутины плохо подходят для выполнения сложных вычислений, но отлично для I/O задач.
Например, сервис уведомления пользователей, который должен рассылать кучу уведомлений в минуту.
Для больших проектов он плохо подходит из-за фактически отсутствующего ООП и странной обработки ошибок, но определенно своя ниша у него есть.
А срач часто возникает из-за «Java мерва, потому что Go есть» ну и подобных заголовков)
Go хороший инструмент для примитивных сервисов где требуется хорошая паррарельность задач. Он не конкурент языкам из категории main-stream , но может успешно применяться для отдельных микросервисов …
Статьи про этот язык, часто вызывают срач в комментариях , потому-что люди думают, что этот инструмент некая волшебная пуля от всех бед и начинают использовать его там где это не нужно. Ну серьезно, вы же не забиваете гвозди с помощью отвертки ?
Отрадно видеть для подобных задач реализацию на родной Java )А то python порядком надоел)
Представляете сколько будет стоить собрать архитектуру проекта с нуля ? Не совсем понятна связь между клиентской базой и архитектурой . Современные облачные платформы позволяют масштабировать ваши сервисы практически под любую нагрузку.
Два вопроса :
1)Почему python ? Разве не лучше выбрать такие инструменты как Java или С# , статическая типизация и лучшая поддержка многопоточности, то что надо для нагрузок.
2) «С точки зрения бэкенда это означает постоянную перекройку внутренней инфраструктуры» эээ…Ну мягко говоря это очень плохо…И главное, зачем ?