«Python выходит в лидеры»: кто и почему его использует

    В январе Stack Overflow провели ежегодный опрос, в котором приняли участие 100 тыс. разработчиков из 183 стран. В этом году Python вновь приблизился к вершине рейтинга популярных языков: в прошлом году он оставил позади PHP, в этом ― обошёл C#.

    При этом Python стоит на третьем месте в рейтинге наиболее любимых ЯП. Далее расскажем, почему и как его используют крупные корпорации и небольшие стартапы.


    / фото PxHere PD

    Крупные ИТ-компании: простота и производительность


    Аналитики из iDataLabs больше двух лет собирали данные о том, сколько компаний используют Python. В результате они установили, что на этом языке пишут в 75 тыс. компаний по всему миру. И хотя, по их данным, Python имеет не самую большую долю рынка, его популярность стабильно увеличивается.

    В прошлом году Python занимал пятое место в рейтинге TIOBE. Это индекс, оценивающий популярность ЯП, на основе количества поисковых запросов на платформах Google, Wikipedia, YouTube, Amazon и др. В 2018 году популярность языка увеличилась до 6% (почти на 3% c 2017 года), и теперь он занимает четвертое место в рейтинге.

    Среди крупных организаций, которые начали использовать Python именно из-за его простоты и популярности, можно выделить Instagram. Как отметили представители компании, они перешли на Python 3 и фреймворк Django из-за того, что этот ЯП «дружелюбен» к разработчикам и позволяет им сконцентрироваться на создании важных для пользователей функций.

    Плюс широкая распространенность языка и глобальное комьюнити (по данным SO, на нем пишет 39% разработчиков, а 68% ― называет Python любимым ЯП) позволяют быстрее нанимать новых членов команды.

    Другой кейс ― компания SurveyMonkey, занимающаяся разработкой облачного программного обеспечения для онлайн-опросов. Ежедневно организация обрабатывает порядка миллионов ответов респондентов. Изначально веб-приложение SurveyMonkey было написано на C# с помощью платформы .NET. Приложение работало без сбоев, однако показывало не лучшую производительность во время тестирования и развертки новых фич.

    В SurveyMonkey решили переписать приложение на Python и разбить основные функции на несколько сервисов, каждый из которых «общался» с остальными через API. Это уменьшило кодовую базу, с которой приходилось работать при тестировании функций, и упростило процесс их реализации.

    Помимо простоты, среди преимуществ Python, разработчики из SurveyMonkey отмечают удобные инструменты для тестирования и развертывания приложений и большое количество библиотек.

    На Python пишут в Google, Facebook, Netflix, Quora, Reddit и многих других крупных компаниях. При этом Python используют не только разработчики, но и специалисты по обработке и анализу данных.

    Согласно июльскому опросу от Burtch Works, где занимаются подбором специалистов по анализу данных, Python вместе с R находятся на втором месте по популярности: их использует треть из 1200 опрошенных специалистов. При этом от лидера опроса ― SAS ― Python «отстал» всего на один процент. А по информации аналитической платформы Kdnuggets, за последний год 66% из 2300 опрошенных data scientist’ов использовали Python в рабочих проектах. Причем популярность языка выросла на 14% в период с 2016 по 2018 год.

    Например, как отметил Абхишек Гхош (Abhishek Ghose) из компании [24]7.ai, занимающейся разработкой ПО для работы с клиентами, он использует Python для сбора и обработки данных разных форматов. По словам Гхоша, тот упрощает и ускоряет процесс написания кода. При этом специалист отмечает, что для решения некоторых data science-задач ему достаточно использовать Python shell.


    / фото Tambako The Jaguar CC

    Стартапы: минимум ресурсов на запуск проекта


    В отличие от крупного бизнеса, большинство стартапов не обладает мощным стартовым капиталом, а время ― критический фактор для начинающих компаний. Им важно как можно скорее создать работающее решение, чтобы представить его инвесторам. Python же позволяет ускорить разработку, затратив минимум ресурсов. Язык позволяет команде из двух-трех человек создать рабочий прототип за пару месяцев. По такой схеме в 2013 году стартовали в компании Shippo, занимающейся поставкой товаров для бизнесов.

    Эта особенность языка в свое время помогла и Дрю Хьюстону (Andrew W. Houston), когда он начинал работу над Dropbox. Будучи студентом, он постоянно забывал дома флешку. Вознамерившись решить эту проблему, Дрю быстро создал прототип облачного хранилища и закрыл сделку с инвесторами.

    Другой пример: Никита Соболев, разработчик и основатель стартапа Wemake.services, перевел всю свою команду с Java на Python. Среди причин такого решения он называет скорость разработки. По его словам, производительность программиста, который пишет на Python, в несколько раз выше, чем, например, у того, кто пишет на Java.

    Программисты со знанием Python очень сильно востребованы. Согласно статистике Hacker News за июль 2018, этот ЯП занимает второе место по популярности после React: 24% всех постов на ресурсе, посвящены поиску Python-разработчиков для стартапов. При этом позиции этот ЯП удерживает уже несколько лет.

    И есть основания полагать, что в дальнейшем Python будет только набирать популярность.



    P.S. Свежие материалы из нашего корпоративного блога:




    Основное направление нашей деятельности — предоставление облачных сервисов:

    Виртуальная инфраструктура (IaaS) | PCI DSS хостинг | Облако ФЗ-152 | Аренда 1С в облаке

    ИТ-ГРАД

    389,92

    vmware iaas provider

    Поделиться публикацией
    Комментарии 76
      +7
      В SurveyMonkey решили переписать приложение на Python и разбить основные функции на несколько сервисов, каждый из которых «общался» с остальными через API. Это уменьшило кодовую базу, с которой приходилось работать при тестировании функций, и упростило процесс их реализации.

      Так как-бы не понятно что большее влияние оказало — смена языка или смена архитектуры.
        +8

        Да, наверное, Google создал язык Go, потому что Python был слишком быстр для них

          +4
          Непонятно, к чему этот комментарий. Статья же не про скорость языка, а про популярность и некоторые причины её объясняющие.
            0
            Крупные ИТ-компании: простота и производительность

            Проавда производительность чего? — все же разработки наверное. Гвороят что раньше Google применял python для написания прототипов. И, кстати, один из самых первых облачных проектов который не стал правда мега-популярным — это был google app engine с модернизированным Django в качестве движка. Потом эта идея как-то у них затормозиась в развитии. А могли бы стать лидерами.
              +1
              Термин «производительность» не обязательно относится к программам, написанным на языке, он может означать и производительность разработчиков, использующих этот язык.
                0
                Стоит заметить, что Gо, согласно замыслу его создателей, призван решать обе эти проблемы.
                  0
                  Это скорее была бы «продуктивность»
              0
              Гугл это гугл, это крайний случай, думаю всем остальным производительность питона вполне нормальная.
            • НЛО прилетело и опубликовало эту надпись здесь
                +5
                Другой пример: Никита Соболев, разработчик и основатель стартапа Wemake.services, перевел всю свою команду с Java на Python. Среди причин такого решения он называет скорость разработки. По его словам, производительность программиста, который пишет на Python, в несколько раз выше, чем, например, у того, кто пишет на Java
                Видимо, не очень хорошие Java программисты в команде, если при переходе на новый язык их производительность выросла в несколько раз)
                  +1
                  Перевести команду на другой язык можно разными способами. Например путем замены.
                    –7
                    Java медленнее Python в несколько раз, так что это тоже послужило причиной.
                      +5

                      Как java с jit медленнее иетерпетируемого python?

                        –2
                        Ну да ты правый, посмотрел на бенчмарки benchmarksgame-team.pages.debian.net/benchmarksgame/faster/python.html python в некоторых тестах проигрывает java в 10-20 раз.
                          0
                          Или 40, не считая потребления ЦПУ.
                          spectral-norm

                          source secs mem gz cpu cpu load
                          Python3 193.86 50,556 443 757.23 98% 98% 99% 99%
                          Java 4.41 35,028 950 16.79 96% 97% 98% 95%
                          0

                          Я бы хотел поправить вопрос. Вот так звучит афористичнее:


                          Как java с jit медленнее python с gil?

                      +4

                      сколько людей — столько мнений… я крайне доволен .Net стэком. У меня в текущем проекте полный фарш: на бэке webapi, сайт, wpf десктоп клиент админки, xamarin forms мобила. Интеграция и повторное использование кода между этими вещами просто фантастическая: по сути я один раз написал модель данных и натянул на неё разные интерфейсы, а в добавок еще десктоп и мобила вообще почти 1 в 1 совпадают по xaml. Если бы это добро всё было на разных языках и платформах… я б потратил на это раз в 5 больше времени.

                        0
                        Аналогично. Правда, я извращенец, наверное, но меня вполне устраивает С++ для числодробилок и хаскель для всего остального.
                        –7
                        Вот интересно, почему если язык такой простой и так на нем быстро писать, разработчики часто пользуются поиском?
                          +9

                          Затем, чтобы не изобретать свой велосипед и не ходить по граблям.
                          И это не зависит от языка — поиском пользуются все. И это правильно и разумно.

                            0
                            это все понятно, но бывает и другие случаи. Вот мой пример: я разработчик на платформе 1С, это моя работа, поиском пользуюсь редко. Ещё бывает пишу запросы на SQL, поиск тоже редко нужен. Ещё я пишу на c#, поиск пользуюсь чаще, но в принципе код могу написать без Гугла. А ещё очень редко нужно писать на cpp, но без Гугла я и 50 строк не напишу. Вот и получается, что чем хуже я знаю язык и платформу, тем чаще мне нужен поиск. А судя по такой статистике может оказаться, что у меня самый популярный язык это cpp.
                              0

                              Тут, видимо, трудности перевода.
                              Популярность = интересуемость. Количество поисковых запросов это показатель интересуемости языка, а не абсолютного количества разрабов или проектов.
                              Питон, он клевый. Он, зараза, для всего пригоден. от "скриптов" до прилождений для мобильников.
                              Его любят ученые. И на волне машинного обучения он — огого!
                              И если вам мил одинэс, то у меня десятки внешних питонячих сервисов работают с базой. некоторые даже еще SOAP. Тут больше ограничений и уродства со стороны 1С — сколько лет уже HTTP-сервисы не поддерживают тупой синтакс-контроль. Нураленышам же пофигу — бабло капает и ладно. А на нас с вами — класть с прибором.

                              0
                              на питоне часто пишут скрипты, а т.к. он может быть не основным языком разработки, то и иногда без Гугла не обойтись, чтоб написать небольшой скрипт.
                              +3
                              А 30 лет назад программисты пользовались книгами, чем отличается поиск в интернете от поиска в книге, кроме скорости, разумеется?
                                0
                                1. Книги не получают новой информации в онлайн режиме.
                                2. В книге не найдешь готовой библиотеки / функции на конкретную узкую задачу.
                                  +1
                                  Это был скорее риторический вопрос-ответ на замечание автора комментария «Пользуются поиском, ай-ай-ай», хотя пользовались поиском всегда, только раньше это были книги, еще раньше статьи и т.д.
                                +1
                                По той причине, что язык состоит не только из конечного числа операторов, но и многих сотен модулей/библиотек, API которых могут потребовать время на изучение. Часто, проще и быстрее воспользоваться поиском и подсмотреть уже готовые примеры использования API.
                                0
                                Жаль ruby с рельсами таки стал сливать из-за AI тренда.
                                  0

                                  "Есть лож, а есть статистика.."
                                  Я то же питон активно пользую. Очень удобно простой скрипт скидать для анализа лога, генерации отчетов (выборок из БД… срочно срочно..) и тому подобных задач.


                                  Но основное языки для разработки все равно остаются Java и С++.
                                  Поскольку "дружелюбность для разработчика" заканчивается на уровне программ в 500..1000 строк кода.
                                  Что то более объемное — лучше Java.

                                    +1
                                    Поскольку «дружелюбность для разработчика» заканчивается на уровне программ в 500..1000 строк кода.

                                    А поподробнее можно?
                                    Т.е. я еще как-то могу понять, если у вас программа в один файл в 500-1000 строк кода, но кто мешает разбивать на модули и писать нормальный, структурированный код?
                                      0
                                      А интересно, много проектов на питоне, которые больше уровня «скрипт скидать для анализа лога, генерации отчетов»? Для бигдаты и мл вроде тоже достаточно скромные по объёму скрипты.
                                      Если не брать в рассчёт что-то типа matplotlib, в котором порядка 20 мегабайт кода и в основном на питоне, но это всё же библиотека. В ближнем окружении не видел крупных задач, всё в основном — скрипт скидать.
                                      0
                                      Разбивать никто не мешает, но отсутствие строгой статической типизации мешает это всё потом поддерживать.
                                        –1

                                        Это все прекрасно покрывается тестами и проблемы с поддержкой и рефакторингом совсем небольшие. Ну и в Питона 3.5 завезли аннотации, если вам прям нужно знать типы, можете использовать такие подсказки. Один из основных плюсов Питона как раз в его динамической типизациии. А это позволяет не писать тонны интерфейсов явно, а использовать duck typing, что как раз и ускоряет разработку и поддержку в разы. Ну и тестирование автоматическое никто не отменял

                                          +1
                                          Переизобретать руками тайпчекер для данных конкретных случаев вашего кода в виде тестов — не очень понятное мне развлечение.

                                          Динамическая утиная типизация ускоряет разработку и поддержку, пока софтина мелкая. После этого уже начинает ускорять разработку эта пресловутая строгая статическая типизация. Желательно, достаточно выразительная.

                                          Когда вы делаете рефакторинг, тайпчекер перестаёт ругаться, и у вас после этого все тесты (которые ближе к интеграционным, а не к юнит-тестам) зелёные, это очень круто.
                                            0

                                            Ну если вы пишете тесты на тайпчекинг, вам видимо нужно протестировать тайпчекинг) Обычно тестами тестируют реализованный функционал. Я не один проект на питоне запустил, и мне не пришлось ни разу писать тесты на тайпчекинг. Может конечно я что-то не так делаю) Но сейчас эти проекты прекрасно рефакторятся и расширяются. А тесты функционала помогают ничего не сломать. Ну и делается это все как минимум в 2 раза быстрее, чем было бы на той же Джаве)

                                              0
                                              Это все прекрасно покрывается тестами и проблемы с поддержкой и рефакторингом совсем небольшие.

                                              Я на это отвечал вот. Просто я такие тесты видел, они покрывают то, что в более других языках проверяется тайпчекером.

                                              Но да, это не джава и не С++.
                                                0

                                                Ну наличие где-то в каком то проекте таких тестов совсем не означает, что это common practice. Тесты пишут обычно на функционал, а тесты на поверку типов бессмысленны просто потому, что в питоне обычно используется подход к объектам по "интерфейсу", а не по типу. А тип может быть любой, если он реализует этот интерфейс

                                                  0
                                                  Соответствие реализации функции принимаемым интерфейсам тоже вполне проверяется тайпчекером (и это даже удобнее, на мой взгляд, чем тестами, ввиду очевидного различия между кванторами существования и всеобщности).
                                                    0

                                                    Ну хорошо) Простой пример из практики, чтобы вы поняли, что тайпчекинг смысла не имеет. У вас есть утилитарная функция, которая принимает объект, у которого должен быть метод get_value,. к примеру, который не принимает параметров и возвращает число. Функция знает сигнатуру вызываемого метода и знает как с ним работать. Зачем ей тип объекта? Ну и этот метод реализуют 20 классов в проекте, которые никак не связаны друг с другом. Как это будете тестировать? С каким типом?

                                                      +1
                                                      Видимо, у нас немного разные представления о тайпчекинге. Я не говорю о том, чтобы руками типы проверять.

                                                      Что до тестов и вашего вопроса об их выражении — смотря на каком языке. И мой поинт как раз в том, чтобы написать программу так, чтобы тут нечего было тестировать. На современных плюсах, скажем, такую программу никак не написать, шаблоны тайпчекаются компилятором после мономорфизации, а не до (хотя с concepts нулевых годов там такое выражалось, но, увы, их не приняли).

                                                      На хаскеле — напишу тайпкласс
                                                      class HasValue a where
                                                          getValue :: a -> Int
                                                      

                                                      и напишу искомую функцию в её терминах (чтобы она принимала не конкретный тип, а произвольный инстанс этого класса). Компилятор тогда всё проверит за меня. При этом на конкретные типы оно завязываться не будет совсем.
                                                        0

                                                        Теперь я понимаю, о чем вы. К сожалению или к счастью, такой тайпчекинг в языках с динамической типизацией невозможен. И, если честно, я не вижу особой необходимости для этого просто потому, что автоматические тесты являются обязательными. А они в свою очередь покрывают и ту ситуацию, когда объект может использоваться неверно, либо не тот интерфейс у переданного объекта. Ну так просто получается, потому что, тестируя функционал, автоматически тестируются и функции, которые принимают динамически сформированные объекты. А как работать без тестов вообще даже в языках со статической типизацией, я плохо представляю. Программа без тестов, как модульных, так и функциональных, с большой долей вероятности не выдержит даже минимальный рефакторинг без дополнительных затрат на ручные проверки.

                                                          0
                                                          Ну так просто получается, потому что, тестируя функционал, автоматически тестируются и функции, которые принимают динамически сформированные объекты.

                                                          Если есть интеграционные тесты, то юнит-тесты не нужны? :)

                                                          И, если честно, я не вижу особой необходимости для этого просто потому, что автоматические тесты являются обязательными. А они в свою очередь покрывают и ту ситуацию, когда объект может использоваться неверно, либо не тот интерфейс у переданного объекта.

                                                          Вопрос, опять же, лишь в том, тесты какого рода и в каком количестве вы пишете.

                                                          А как работать без тестов вообще даже в языках со статической типизацией, я плохо представляю. Программа без тестов, как модульных, так и функциональных, с большой долей вероятности не выдержит даже минимальный рефакторинг без дополнительных затрат на ручные проверки.

                                                          Никто не говорит о том, чтобы писать вообще без тестов. Речь о том, чтобы не писать те тесты, которые не нужны.

                                                          В одном моём предыдущем проекте (что-то вроде компилятора) юнит-тестов не было вообще. При этом я вёл проект в соответствии с чем-то вроде test-driven development: перейти к следующему пункту в документации языка (которая даже не спекой была, а гайдом для пользователей, увы), написать тест, реализовать недостающую функциональность, повторить. Соответственно, у меня были тесты на фронтенд компилятора (считайте, тупо таблица, какая входная программа должна приводить к какому AST или к какой ошибке парсинга), так как с фронтенда и AST я начал. Были тесты на кодогенератор (аналогично тупо таблица из исходного текста программы, входа этой программы и ожидаемого вывода программы). Были тесты на оптимизатор (quickcheck-style-тесты на то, что программа до оптимизации и после оптимизации ведёт себя одинаково). При этом отдельные комбинаторы в парсере во фронтенде, отдельные функции кодогенератора или отдельные функции оптимизатора я не тестировал.

                                                          И при этом программа выдерживала не только рефакторинг (см. выше про зелёность), но и семантические изменения в логике работы.

                                                          Другой пример: сейчас я балуюсь с биндингами к libclang на хаскеле. clang тоже строит AST программы на C++. Какие гарантии мы можем сделать статическими? Ну, например, что детей вы будете запрашивать только у тех AST-нод, которые вообще могут иметь детей. Или что тип возвращаемого значения вы можете запрашивать только у тех типов, которые соответствуют функциям.

                                                          При этом даже совсем не обязательно делать каждую ноду в AST своим собственным типом данных. Можно их просто правильно протегать. Хотя, конечно, система типов в хаскеле здесь уже немножко рвётся, и на более продвинутых языках это было бы изящнее, но увы, там с FFI всё очень плохо.
                                                        0
                                                        У вас есть утилитарная функция, которая принимает объект, у которого должен быть метод get_value

                                                        Значит она принимает интерфейс у которого описан метод get_value.


                                                        Функция знает сигнатуру вызываемого метода и знает как с ним работать.

                                                        Ну да, сигнатура же описана в интерфейсе


                                                        Зачем ей тип объекта?

                                                        Чтобы в неё нельзя было передать объект, который не реализует этот интерфейс.


                                                        Ну и этот метод реализуют 20 классов в проекте, которые никак не связаны друг с другом.

                                                        В джаве они все помечены как реализующие этот интерфейс. В Go они вообще никак не помечены, просто у них есть такой метод.


                                                        Как это будете тестировать?

                                                        В языке со статической проверкой типов это не надо тестировать. В питоне — передать в функцию объект, у которого нет метода с такой сигнатурой и проверить, что поведение функции соответствует ожидаемому.

                                                          0
                                                          В питоне интерфейсы — это номинальный тип, реально такого типа нет.
                                                          > Ну да, сигнатура же описана в интерфейсе

                                                          А ещё там есть магические методы типа __getattr__, который спокойно может вернуть этот метод, хотя в интерфейсе класса его нет явно. А ещё в питоне есть возможность в рантайме добавить метод в объект. Поэтому увы, но тут никак интерфейсами не поможешь. Да они особо и не нужны. Как я уже писал, все покрывается тестами. А если есть веррятность получения неправильного объекта, ловите эксепшн и обрабатываете соотв. образом, или делаете проверку нужных атрибутов
                                                            0
                                                            Поэтому увы, но тут никак интерфейсами не поможешь.

                                                            Если статической типизации нет, то конечно не поможешь.


                                                            Да они особо и не нужны. Как я уже писал, все покрывается тестами.

                                                            И, как уже писали вам в ответ, если типизация статическая, то тесты для проверки того, правильный ли объект вам передали, можно не писать. Это экономит время.


                                                            А если есть веррятность получения неправильного объекта, ловите эксепшн и обрабатываете соотв. образом, или делаете проверку нужных атрибутов

                                                            И, конечно, пишете тесты, которые проверяют, правильно ли вы ловите и обрабатываете эксепшн. А вероятность получения неправильного объекта в динамически типизируемом языке есть практически всегда.

                                                              0
                                                              Ну что поделаешь. Лучше написать один-два лишних теста, чем писать несколько интерфейсов, продумывать правильную цепочку наследования, может даже создавать новые типы для унификации, как-то это все связать вместе и потом поддерживать.
                                                              Ну и справедливости ради, ситуация, когда в функцию отправляется объект неправильного типа (кроме None, undefined, null и подобных), когда у функции четко описан интерфейс в той же документации, на моей практике возникает нечасто. Разве что по ошибке в вызываемом коде или по злому умыслу. В обоих случаях ловится функциональными тестами. Ну и если что, IDE подскажет, что тут тип не совсем правильный, а если IDE не подскажет, есть typing (https://docs.python.org/3/library/typing.html) и аннотации, тогда уж хороший линтер неправильный тип не пропустит. В общем, все решаемо в Питоне, на любой вкус и цвет, даже с динамической типизацией.
                                                                0
                                                                Лучше написать один-два лишних теста, чем писать несколько интерфейсов

                                                                Одним-двумя тестами тут не обойдёшься, тест надо писать для каждой функции, которая принимает объект с get_value. То есть количество тестов, которое нужно написать вместо объявления интерфейсов в лучшем случае будет равно количеству интерфейсов, а обычно будет намного больше.


                                                                продумывать правильную цепочку наследования

                                                                Для объявление интерфейса продумывать цепочку наследования не нужно. Вообще наследование не нужно.


                                                                может даже создавать новые типы для унификации

                                                                Тоже не нужно )))


                                                                Ну и справедливости ради, ситуация, когда в функцию отправляется объект неправильного типа (кроме None, undefined, null и подобных)… на моей практике возникает нечасто.

                                                                Кстати null система статической типизации тоже может отловить. Но в общем приятно, что нечасто возникает.


                                                                Разве что по ошибке в вызываемом коде

                                                                А как хорошо всё начиналось ))

                                                                  0
                                                                  Ну что я могу сказать) Если вам приходится писать кучу тестов на такие вот проверки, ну значит Питон не для вас) Используйте статически типизированные языки. А мы просто тесты не пишем на такие вот вещи типа некорректных параметров, подразумевая, что данные корректны, и пока вроде проблем не возникало) Функциональные тесты решают) Зато разработка и поддержка раза в 2 точно меньше времени занимает. А меньше времени на поддержку и разработку — больше фичей, меньше затрат для компании и так далее. В общем, у нас одни плюсы. Если у вас минусы, ну, значит Питон в вашем случае не подойдет.
                                                                    0
                                                                    Если вам приходится писать кучу тестов на такие вот проверки, ну значит Питон не для вас)

                                                                    А если вы используете питон и не тестируете эти кейсы, значит в вашем коде полным полно ошибок. ))


                                                                    Зато разработка и поддержка раза в 2 точно меньше времени занимает.

                                                                    С чего бы вдруг? Вы же не хотите сказать, что декларация типов занимает столько времени?

                                                                      0

                                                                      Нас это мифическое "полным полно ошибок", о котором вы пишете, вполне устраивает. Лучше потратить время на исправление действительно значимых проблем, чем ситуации, вероятность появления которой стремится к нулю. Чего и вам желаю

                                                                        0
                                                                        Нас это мифическое "полным полно ошибок", о котором вы пишете, вполне устраивает.

                                                                        Охотно верю.


                                                                        Лучше потратить время на исправление действительно значимых проблем, чем ситуации, вероятность появления которой стремится к нулю

                                                                        Ещё лучше тратить время на исправление действительно значимых проблем и при этом точно знать, что ошибок, связанных с передачей переменных неверного типа, просто не может возникнуть.

                                                                          0
                                                                          > Ещё лучше тратить время на исправление действительно значимых проблем

                                                                          Ну вам виднее) Пусть лучше программа крашится или достает пользователей багами в логике, но зато все входные типы там четко протестированы. Желаю успеха вашим продуктам)
                                                                            0
                                                                            Пусть лучше программа крашится или достает пользователей багами в логике, но зато все входные типы там четко протестированы.

                                                                            Нет, так не лучше, именно поэтому вы не тестируете входные типы. У вас нет времени протестировать и то и другое.


                                                                            Чтобы сравниться по скорости разработки с разработчиками, использующими языки со статической типизацией, вам приходится сознательно отказываться тестировать значительное количество кейсов.

                                                                              0
                                                                              Некоторые логические инварианты тоже можно выражать в виде типов (на самом деле практически все, вопрос в упоротости упорстве). Но это, конечно, совсем не на джаве. И даже не совсем на хаскеле.
                                                                          0
                                                                          Вы же не хотите сказать, что декларация типов занимает столько времени?

                                                                          Которая, более того, в подавляющей части объявлений переменных не нужна.
                                                                          0
                                                                          Зато разработка и поддержка раза в 2 точно меньше времени занимает.

                                                                          По сравнению с каким статически типизированным языком? Их очень много разных, с кучей разных видов статической типизации.
                                                0

                                                В python (и JS) мне не нравится:


                                                • неявное преобразование типов
                                                • создание переменных без объявления

                                                Это потенциальная (и наступал на это) "слабое место" для ошибок.


                                                В простых программках, когда нужно быстро быстро решить какую то задачу (на те же 500 строк кода) — это может оказаться преимуществом. А в программах которые потом сопровождать и где исходного кода на пару сотен кбайт, лично я предпочитаю C++ или Java. (Java лучше, поскольку проблемы с версиями Unix/Oracle client задрали..)


                                                При прочих равных, производительность — это то же важно..


                                                В повседневной работе сейчас:


                                                • в основном, новые проекты на Java.
                                                • Сопровождаю старый код на C++ (которой частично и сам писал).
                                                • питон — для анализа логов (нестандартные задачи), не стандартные разовые отчеты, вместо sh/bash (когда его возможностей мало), и т.п.
                                                • js — web морды для пользователей. Регулярно..
                                                • PL-SQL + SQL — когда долго ждать когда у разработчика Oracle время появится и нужно срочно..

                                                Для хобби: C++, java и питон.


                                                Все сказанное — мое личное мнение, на моем личном опыте. А не на теоретических рассуждениях.

                                                Все эти споры "какой язык лучше"…
                                                Да пофиг, по большому счету, на чем кодить… У всего есть недостатки и достоинства.

                                                  0

                                                  В питоне нет неявного преобразования типов

                                                    0

                                                    И неявного объявления переменных в питоне тоже нет. Это вы с JS перепутали.

                                                  0

                                                  Все зависит от задач и ресурсов. Разработка на Java как правило затратнее по времени, чем на Python. Но если есть критичные ко времени выполнения требования, тут да, Java может и лучше подойдёт. Но опять же, все зависит от задач и Питон отлично интегрируется с модулями на Си там, где нужна производительность. А если ещё вспомнить, что время разработчиков обходится значительно дороже, чем затраты на железо, тут вопрос может сместиться не в сторону Java. Не все так однозначно)

                                                  +2
                                                  Для начала следует задать вопросы:
                                                  — Что такое Stackoverflow?
                                                  — Какова ниша данного продукта?
                                                  — Каков уровень активных пользователей в разработке?

                                                  И только после этого делать какие-то выводы.
                                                  Меня напрягают современные методы изучения языков программирования. Вместо того, чтобы почитать книгу или другие материалы, проще сгонять на форум и задать вопрос. Что-то мне подсказывает, что это и есть основной контингент Stackoverflow и подобных сервисов. Особенно идеально это доказывает Тостер.
                                                    +1
                                                    Одно дело, когда задают вопрос по конкретной задаче и используют конкретный подробный ответ.
                                                    Другое дело, когда задают вопрос и используют ответ в качестве основы «что, как и почему» и уже на этой основе ищут информацию. Если речь про первое — то да, тенденция не очень, если про второе — не вижу в этом ничего крамольного, это так же эффективно и возможно фундаментально, как и книга, и при этом в разы быстрей.
                                                      0
                                                      Да вот второго я замечаю всё меньше и меньше, может они учатся пользоваться поисковиками, но мне слабо верится. И именно из-за первых я начал бросать сервисы подобные stackoverflow.

                                                      Я знаю кучу «разработчиков», которые реально не хотят изучать, в лучшем случае поищут, в худшем просят, что за них написали готовый код.
                                                      0
                                                      Только читать нужно не книги, а доки. Инфа в книгах часто успевает устареть за время выхода в печать. Исключения конечно есть, типа книг по алгоритмам и другим базовым вещам.
                                                      В остальном согласен с вами, GDD весьма популярен.
                                                      Ну а Тостер к сожалению окупировали те кто хочет чтобы за них сделали работу, а не те кто пытаеться сам научиться.
                                                        +1
                                                        Новичку надо научиться правильно думать, это могут дать книги, но никак не сухая документация. Опытный программист уже и без stackoverflow сможет решить большинство проблем.
                                                        0
                                                        Stackoverflow — замечательный сервис на тот случай, если нужно быстро получить ответ на какой-то конкретный вопрос. Особенно если попался какой-то совершенно нелогичный баг или фича, про который фиг прочтёшь в книжке. А из реальных программистов кто-нибудь с ним да сталкивался. Ну и не только это, бывают и полезные всякие howto там, о которых тоже бывает в книжках не прочесть.
                                                        0

                                                        Странно оценивать популярность языка по количеству поисковых запросов связанным с ним. Этот показатель может указывать на наличие проблем на которые пытаются найти ответ в поисковиках.


                                                        Может народ кучу старых питоновских скриптов народ переводит под 3ю версию. Или пытатся сделать чтоб они работали на обоих версиях.

                                                          0
                                                          Хм, даже не прочитать первую строку статьи и написать комментарий, это конечно сильно. Там написано: провели опрос.
                                                            0

                                                            Я об этом:


                                                            В прошлом году Python занимал пятое место в рейтинге TIOBE. Это индекс, оценивающий популярность ЯП, на основе количества поисковых запросов на платформах Google, Wikipedia, YouTube, Amazon и др. В 2018 году популярность языка увеличилась до 6% (почти на 3% c 2017 года), и теперь он занимает четвертое место в рейтинге.
                                                              0
                                                              Ну это да, тогда я с вами согласен. Тут только на попугаев можно посмотреть и всё.
                                                          0
                                                          Оценивать популярность языка по количеству запросов может и не правильно. Но факт то, что на HeadHunter количество вакансий по Python иной раз больше чем вакансий по C#.
                                                            0
                                                            ценность языка очень сильно зависит от количества полезных и удобных инструментов для работы и куча хороших библиотек, с питоном не знаком, но может тут есть умельцы раз он так популарен которые смогут подсказать в какую сторону смотреть, чтоб хватило на разработку веб приложений и сервисов. имеется ввиду удобное IDE с необходимыми плагинами и хорошие библиотеки
                                                              0
                                                              PyCharm от Jetbrains если нужна полноценная IDE, если же продвинутый редактор, то VSCode/Atom/Brackets/SublimeText с плагинами. Ну а готовые библиотеки есть есть под все что душа пожелает. Самый популярный вебфреймворк Django или более легковестный Flask, для удобной работы с http — requests, для асинхронных приложений asyncio, для тяжелых мат. вычислений NumPy и т.д.
                                                                0

                                                                Тут все, что в принципе может понадобиться https://pypi.org. Там и категории есть и поиск по ключевым словам

                                                                  0

                                                                  Из IDE отлично подходит PyCharm или IntellujIdea с плагином Python.

                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                Самое читаемое