Почему будущее не за Python

Автор оригинала: Rhea Moutafis
  • Перевод
Хотя, безусловно, этот язык программирования будет востребован ещё много лет.



Сообществу программистов понадобились десятилетия, чтобы по достоинству оценить Python. С начала 2010-х годов он переживает бум — и в итоге превосходит C++, C#, Java и JavaScript по популярности.

Но до каких пор эта тенденция будет сохраняться? Когда Python в конечном итоге будет заменён другими языками и почему это неизбежно произойдёт?
EDISON Software - web-development
Перевод сделан при поддержке компании EDISON.

Мы занимаемся разработкой приложений на Python, а также делаем тестирование программного обеспечения.

Мы очень любим и широко используем Python! ;-)

Что делает Python популярным сегодня


О популярности Python можно судить по StackOverflow, если смотреть на количество тегов в сообщениях. Учитывая масштаб StackOverflow, это довольно-таки объективный показатель популярности языка.


Упоминаемость на StackOverflow некоторых популярных языков программирования — динамика изменений по годам. Показатели Python неуклонно растут, у конкурентов — снижаются.

В то время как R в течение последних нескольких лет находился на плато, а показатели многих других языков неуклонно снижаются, рост Python кажется неудержимым. Почти 14% всех вопросов StackOverflow помечены как «python», и эта тенденция только растёт. И тому есть ряд причин.

Проверен временем


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

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

Дружелюбен к новичкам


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

Во-первых, нет необходимости указывать тип данных. Вы просто объявляете переменную — из контекста Python поймет, является ли она целым числом, значением с плавающей запятой, логическим значением или чем-то ещё. Это огромное подспорье для начинающих. Если вам когда-либо приходилось программировать на C++, то вы знаете, как это грустно, когда программа не компилируется только из-за того, что где-то вместо числа с плавающей запятой подставлено целое.

И если вам когда-либо приходилось сравнивать код на Python и C++, то знаете, насколько более понятным выглядит Python. Несмотря на то, что C++ спроектирован с учётом английского языка, это весьма сложное чтение по сравнению с питоновским кодом.

Универсален


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

Много чисел, векторов и матриц? NumPy в помощь.
Техническо-инженерные расчёты? Используйте SciPy.
Анализ больших данных? Pandas разберётся.
Машинное обучение, нейронные сети, ИИ? Почему бы не Scikit-Learn?

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

Недостатки Python — и могут ли они похоронить язык


Воодушевившись текущим положением дел, можно вообразить, что Python — это всерьёз и надолго. Но, как и у любой технологии, у Python есть свои слабые стороны. Рассмотрим по порядку самые важные недостатки, и оценим, являются ли они фатальными или нет.

Скорость


Питон медленный. Не, ну реально медленный. В среднем задача выполняется в 2–10 раз дольше чем на языках-конкурентах.

Тому есть причины. Во-первых, динамическая типизация — помните, выше мы говорили, что очень удобно, когда не нужно указывать типы данных, как в других языках? Обратной стороной медали является необходимость в использовании большого количества памяти, потому что программе необходимо резервировать достаточно места для каждой переменной, чтобы она работала в любом случае. И память «с запасом» приводит к большему расходованию вычислительного времени.

Во-вторых, Python может одновременно выполнять только одну задачу. Это тоже является следствием гибких типов данных — Python должен убедиться, что каждой переменной соответствует только один тип данных, и параллельные процессы могут этому помешать.

Но, по большому счёту, скорость не имеет решающего значения. Производительные компьютеры и серверы настолько доступны, что речь разве что идёт о долях секунды. Конечному пользователю все равно, загружается его приложение за 0,001 или же за 0,01 секунды.

Область видимости


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

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

Python попытался перейти к статической области видимости, но неудачно. Обычно внутренние области видимости, например функции внутри функций, могут видеть и изменять внешние области видимости. В Python внутренние области могут только видеть внешние области, но не изменять их. Это приводит к большой путанице.

Лямбда-функции


Несмотря на всю гибкость Python, использование лямбда довольно ограничено. Они могут быть только выражениями в Python, но не операторами.

С другой стороны, объявления переменных и операторы всегда являются операторами. Это означает, что лямбды не могут быть использованы для них.

Это различие между выражениями и утверждениями довольно произвольно и не встречается в других языках.


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

Пробелы и табуляция


В Python пробелы и табуляция используется для обозначения разных уровней кода. Это делает его визуально привлекательным и интуитивно понятным.

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

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

Мобильная разработка


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

Но мобильных приложений на Python раз два и обчёлся. Это не значит, что это вообще невозможно — для этого есть пакет под названием Kivy.

Python не был создан для мобильных устройств. Даже если он и может дать приемлемые результаты для решения базовых задач в этой области, лучше всего использовать язык, заточенный под разработку мобильных приложений. Некоторые широко используемые платформы программирования для мобильных устройств включают в себя React Native, Flutter, Iconic и Cordova.

Конечно, ноутбуки и настольные ПК ещё будут использоваться долгие годы. Однако мобильные устройства уже давно превосходят настольный трафик. Можно уверенно утверждать, что изучение Python недостаточно, чтобы считаться опытным всесторонним разработчиком.

Ошибки времени выполнения


Сначала отдельно компиляция, затем выполнение — так в каких-то других языках, но не в Python. Вместо этого код компилируется всякий раз, когда исполняется, поэтому любая ошибка в коде проявляется во время выполнения программы. Это приводит к снижению производительности, лишнему расходу времени и необходимости большого количества тестов. Больше тестов богу тестов!

Это отлично подходит для начинающих, так как тестирование само по себе многому учит. Но для опытных разработчиков необходимость отладки сложной программы в Python заставляет их ошибаться. Эта нехватка производительности — самый серьёзный фактор, свидетельствующий о том, что время Python в обозримом будущем пройдёт.

Что может заменить Python в будущем — и когда


На рынке языков программирования появилось несколько новых конкурентов:

  • Rust предлагает тот же протокол безопасности, что и Python — никакая переменная не может быть случайно перезаписана. При этом решена проблема производительности наряду с реализацией концепции владения и заимствования. Согласно StackOverflow Insights, он также входит в число самых любимых языков программирования последних лет.
  • Go отлично подходит для начинающих, как и Python. Это так просто, а поддерживать код еще проще. Интересный момент: разработчики Go — одни из самых высокооплачиваемых программистов на рынке.
  • Julia это очень новый язык, который напрямую конкурирует с Python. Он заполняет пробел в крупномасштабных технических вычислениях: обычно можно было использовать Python или Matlab, выполняя часть задач (подчас — весьма значительную часть) с помощью библиотек C++. Теперь вместо жонглирования двумя языками можно просто использовать Julia.

Хотя на рынке есть и другие языки, Rust, Go и Julia исправляют слабые места Python. Все эти языки превосходны в будущих технологиях, особенно в искусственном интеллекте. Хотя их доля на рынке все ещё невелика (что отражается в количестве тегов StackOverflow), тенденция для каждого из них очевидна: наверх и только наверх.


Упоминаемость на StackOverflow для Go/Rust/Julia — динамика изменений по годам. Показатели пока скромные, но у этих языков устойчивый восходящий тренд.

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

Какой из языков это будет — Rust, Go, Julia или ещё какой-то новый язык будущего — трудно сказать на данный момент. Но, учитывая проблемы с производительностью, которые являются фундаментальными для Python из-за его архитектуры, рано или поздно неизбежное случится.
Edison
Изобретаем успех: софт и стартапы

Похожие публикации

Комментарии 83

    +4

    В Python внутренние области могут только видеть внешние области, но не изменять их.


    wut?


    def setup():
        global pytest
        import pytest

    Расскажите, что именно я тут меняю и зачем?

      +1
      С одной стороны нас при подготовке статьи смутил этот момент, поскольку опыт собственных python-разработчиков (которые предварительно ознакомились с текстом) говорит об обратном. Был выбор то ли вообще удалить этот абзац, то ли пойти по принципу «из песни слов не выкинешь». Всё-таки это перевод.
        +2
        мб речь про замыкания?
        def a():
            x = 10
            def b():
                x = 20 #хотел внешнюю x, но ....
                print(x)
            b()
            print(x)
        
        a()
        
          +2
          Для этого есть ключевое слово nonlocal, автор просто не очень знает современный Python. Ну и динамической области видимости, как в старых Lisp'ах, в Python никогда не было, автор написал чушь.
            +4

            В питоне недозамыкания, про которые лучше не вспоминать (кроме как в разгар отладки).


            >>> def x():
            ...     a=10
            ...     def y():
            ...             return a
            ...     a=20
            ...     return y
            ... 
            >>> x()()
            20
              +6

              Эмм, а при чем тут питон, если это обычное замыкание по ссылке?


              Func<int> X() {
                  var a = 10;
                  int Y() {
                      return a;
                  }
                  a = 20;
                  return Y;
              }
              
              >>> X()()
              20
                +4
                Не пишите чушь, причем тут замыкания в Python? Так будет в любом языке с замыканиями и мутабельными переменными, и это абсолютно нормальное поведение.
                  +1

                  Кроме rust'а, который этот вопрос разрулит как положено. Оно либо move, либо borrow в замыкание, но если значение в замыкании, то пока замыкание живо, значение будет то, какое положили. (как всегда, "если нет unsafe'а").

                    +4

                    В расте есть линейные типы, которые запретят сначала отдать a в замыкание, а потом смутировать его откуда-то ещё. Это понятно. Непонятно, почему это преимущество. Я могу легко представить ситуацию, где это будет недостатком, и расторешение будет костылить это через рц рефцеллы, обмазываясь рантайм борровчекингом.


                    Мне нравится раст, но я не вижу смысла фанатично считать правильным только то, как там сделано.

                      +2

                      Вы можете не обмазываться ничем и пахать на пролом как вам кажется. У вас будет zero cost leg shooting под вашу ответственность. Но в ногу выстрелить без спецусилий не дадут.

            –2
            Ошибки времени выполнения

            Ну вот постоянно так, ведь исключительно скриптовые языки старадают от таких проблем? :) Как там борьба с NullPointerException, потомки?

              +3

              Активировал nullable reference types, не ловил ни одного после этого в проекте. Хотя хотелось бы честных опшнов, но их нет, хнык-хнык.

                +3
                Отлично, после перехода на Kotlin практически исчезли:)
                –2
                Все проблемы, кроме многопоточности, решаются PyPy. Это офигительная технология, которую сейчас заимствует джава в своем граале.
                  +8
                  Новые (относительно) языки, вроде Haskell, решают эту проблему: они полагаются на пробелы, но предлагают альтернативный синтаксис для тех, кто хочет обойтись без них.

                  Хаскель и питон появились в один год, каким образом хаскель стал "новичком"?
                  Список заменяющих языков тоже странный, раст это системная возня с байтиками, где каждая аллокация имеет целый специальный тип, и идёт война за каждый вызов маллока. В то время как в питоне типичное гцшное отношение "насоздавал объектов — гц разберется". Про го и без меня сказано — в mypy типизация на голову выше, чем у го. Производительность — да, такая себе, но обычно на это и пофиг, особенно когда вся нужная инфраструктура на си написана и импортируется в 1 строчку.


                  Вот Скала или хотя бы котлин выглядят как замена. Раст и го — не очень.


                  Ну и странно видеть сравнение "табы против пробелов", у питона ведь хватает реальных проблем, докапываться при этом до синтаксиса...

                    +2
                    Scala сильно сложнее, Kotlin може быть. Насчет mypy неистово плюсую.
                      +3

                      Скала сложнее, но и награждает она больше, если в ней разобраться.

                        +3
                        Я без оценочности, просто констатировал факт. Если же про «награждает она больше», это безусловно так, но может оказаться, что цена этой награды за повышение сложности сделает невозможным вытеснение Python в контексте того, что написано в статье. Гиперболизируя, Haskell потенциально награждает еще больше, но большинству людей не придет в голову увидеть этот язык в качестве конкурента Python. Со Scala не все так однозначно, но тем не менее.
                          +5

                          Хаскель и скала +- одинаковы по возможностям, просто скала еще с сишным синтаксисом, поэтому пугает меньше. Ну и да, хаскель для всяких оперденей имхо вполне себе актуальный язык, было бы желание. Но, чем дальше живу, тем больше вижу, что люди не особо стараются развиваться. Выучил язык, выучил фреймворк — растешь в сениоры-лиды своего языка, в комментах на хабре ругаешь другие языки, рассказываешь как ты 15 лет решаешь задачи на своем языке, всякие изящные решения предлагаешь. Вылезти из рамок привычного фреймвокра и подхода большинство людей даже не пытаются. Многие вообще берут одну технологию тырпрайзную — шарепоинт, например — и всю жизнь пишут этот шарепоинт. То, что они за месяц делают задачу на 1 день (конкретный пример из моей практики) — да пофиг, зарплату то платят. Печально всё это, однако.

                            +3
                            Я сам люблю новые языки и фреймворки, но не стоит достаточно большой проект переписывать под новый язык/платформу/технологию. Это выкидывает в мусорку весь труд не только разработчиков, но и тестировщиков за много лет — а это могут быть миллионы долларов.

                            Собственно, потому и приходится разводить всю эту тягомотину на месяц под устаревшие платформы, хотя и хочется быстро на новой технологии сделать.
                    +3
                    Может лучше почаще писать о недостатках Go?

                    Сейчас даже на Python конференции прибегают любители Go и нагло пиарят свой язык с низким содержанием сахара.
                      +6

                      А на конференции по Go прибегают любители Rust, и так далее. Круговорот любителей в природе, ничего нового.

                        +1

                        Я Вам априори верю, но чтобы был именно круговорот — то он должен быть замкнутым.


                        Означает ли это что на конференции по Rust прибегают любители Python ?

                          +5

                          Круговорот замкнут во времени, но не в пространстве. Любители го прибегают к любителям питона, любители раста к любителям го, а те, кто прибежит к любителям раста, еще не родились/не стали программировать. Возможно, это будут дети любителей питона.

                            0

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


                            Да и в описанном Вами примере мы скорее всего имеем отношение к последовательности которую можно формализовать так:


                            "Если n — новый ЯП, тогда на конференции по n-1 ЯП прибегают любители n"

                              +3

                              Да, вы правы.


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



                              Где n+m; m=[1,2,3...] — следующий язык, а gen+l; l=[1,2,3...] — поколения языков (или программистов).


                              При этом набегают в направлении, противоположном формированию спирали по времени (то есть n+m -> n+(m-1)).

                                +3

                                Ну это ведь логично, языки ведь развиваются. И набегать со словами "смотрите как проблема которая есть в вашем языке автоматически решается в нашем" это просто щэринг знаний, ничего плохого в этом нет. Либо вы в свой язык затащите похожий механизм (привет лайфтайм чекеру в плюсах), либо перейдете на такой язык. Можно существовать в вакууме, и писать так как писалось и 10, и 20 лет назад, но это не очень эффективно получается с точки зрения затрат и сил, и собственного времени.

                                  +3

                                  И да, и нет.


                                  Да — потому что действительно, обмен знаниями и все такое, важно знать, как это делается у соседей, и брать лучшие практики себе.


                                  Нет — потому что часто другие языки ругают с точки зрения контекста, под который "правильный" язык заточен.


                                  Пример — я работаю с Go и часто вижу обсуждения статей вида "почему Go плох", или "почему мы перешли с Go на X" (впрочем, полно и противоположных статей, но там такого обсуждения не получается, конечно). Из недавнего — переход дискорда с Go на Rust и Elixir.


                                  В итоге ругаемые в том или ином языке (в этом случае в Go) вещи — есть следствия trade-off ради получения выгод где-то еще. Например, GC значительно упрощает работу с памятью с точки зрения программиста (особенно что касается гринтредов), но дает пиковые провалы в производительности, когда этот самый GC отрабатывает. Или там отсутствие дженериков делает возможность компиляции за секунды (очень грубо говоря).


                                  В итоге, большинство критики — это просто "неумение правильно готовить ЯП X". И прийти в питон тусовку и сказать — а вот у нас в Го есть гринтреды, а вы до сих пор кипятите с GIL сидите — неверно, потому что контекст решаемых задач на том и на том обычно разный, и цена этого тоже разная.


                                  В целом, самое главное — взаимоуважение и готовность идти на диалог. Не стоит пытаться впихнуть невпихуемое, но и ругать ЯП за то, что он не подошел для решения задачи, где есть инструмент заточенный под эту задачу — тоже неверно.

                                    +7

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


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

                                      +2

                                      Отсутствие дженериков — это не только ради скорости компиляции, конечно. Это и необходимость расчета размера в хипе, и много чего еще (я не эксперт в этом вопросе). Более того, насколько я слышал, с момента релиза го появились новые подходы к работе с дженериками, которые мы, возможно, увидим в Go 2.


                                      Что же касается времени компиляции — сравните компиляцию большого приложения на Go и на c++ (условно) — разница намного больше, чем 5 секунд против доли секунды. Особенно при кросс-компиляции на несколько платформ, особенно в пайплайне.


                                      Но дабы не вдаваться в холивар — прелесть Go не в скорости компиляции, да и проблем ему хватает. Как и любому другому ЯП.

                                        +1
                                        Отсутствие дженериков — это не только ради скорости компиляции, конечно. Это и необходимость расчета размера в хипе, и много чего еще (я не эксперт в этом вопросе). Более того, насколько я слышал, с момента релиза го появились новые подходы к работе с дженериками, которые мы, возможно, увидим в Go 2.

                                        Ну, рассчеты в хипе и остальное — это пусть голова у языковой типы болит, я за них их работу руками делать не очень жажду. Один раз сделали — оно работает. Да, есть проблемы при попытке добавить какие-нибудь ХКТ, но лучше уж так, чем никак.


                                        Что же касается времени компиляции — сравните компиляцию большого приложения на Go и на c++ (условно) — разница намного больше, чем 5 секунд против доли секунды. Особенно при кросс-компиляции на несколько платформ, особенно в пайплайне.

                                        Да пожалуйста, все равно задачи у нас меньше 4 часов практически не бывают, 5 секунд из них можно выделить. А вот ловить потом часами проблемы из-за того что где-то в FooBarInt32 фикс сделали, а в FooBarInе64 забыли — куда менее приятно (в контексте тех же обсуждаемых генериков). Смысл ведь в том, что если машина тратит время на это, то она выполняет какую-то работу. Либо вы выполняете её руками (тратя куда больше времени), либо не выполняете вовсе, и работа остётся несделаной (тоже плохой вариант).


                                        Но дабы не вдаваться в холивар — прелесть Go не в скорости компиляции, да и проблем ему хватает. Как и любому другому ЯП.

                                        Согласен, я просто сказал, что некоторые трейдофы понятные, а некоторые вызывают недоумение.

                            +6

                            Как большой неофит-фанат Rust'а и застарелый олдфаг-питонист, я точно могу сказать, что Rust и python достаточно далеки друг от друга, чтобы не заниматься конкуренцией.


                            Оставляя в стороне вопросы производительности, библиотек и компиляции, Rust — это практическая вершина строгости. Т.е. не полный пуризм с зависимыми типами, но настолько близко к пуризму, насколько это полезно.


                            Python — наоборот. Он практическая вершина расхлябанности. Т.е. не полная расхлябанность с JS-style WTF… Пардон, у нас теперь есть ансибл, который ещё более расхлябан, но настолько к нему близко, насколько это полезно.


                            Т.е. питон идеальный язык для выразительного и краткого кода. Он допускает неточности и огрубления. Rust — практическая вершина строгости и тщательности. Python позволяет написать быстро и близко к тому, что хочется, а язык будет этому помогать. Rust позволяет написать СТРОГО то, что хотелось так, чтобы комар носа не подточил. Все случаи покрыты, всё учтено.


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

                        +7
                        Большинство претензий почему-то сосредоточено вокруг фич языка. Да, питон очень хорош в смысле синтаксиса.
                        Но! Важно еще и место Питона в экосистеме и тулчейн.
                        Место в экосистеме — интерпретатор с очень коротким циклом написал-запустил-проверил, клей для склеивания вызовов сишных и других библиотек и дружественный интерфейс ко всем фичам компьютера. В этом смысле Питон вытеснил перл и тикл. И называемые в качестве альтернативы языки вовсе не выглядят как замена Питону.
                        Тулчейн — простой и переносимый интерпретатор с неплохим REPL ну и простой дебаггер. Хотя не уверен, пусть подскажут знатоки но и с этой точки зрения альтернативы выглядят не очень.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            >> серьезно? Хаскель в 1990 появился.
                            Ну там же специально в скобках уточнено, что он новый относительно.
                              +2
                              Относительно чего? Относительно Python, появившегося в 1990?
                                +1
                                По всей видимости, появившиеся примерно в один год Haskell и Python относительно новые не в сравнении друг с другом, а по отношению к нынешнему времени.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                +2
                                Я родился в 91, означает ли это что я уже стар?
                                +2

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


                                И питон, и го, и раст заточены под, в целом, достаточно разные ниши. Конечно, они в целом перекрываются, но для написания веб-сайта я бы взял питон, для дата-интенсив вебсервиса взял бы го, а для плотной работы с железом скорее раст.


                                Все они хороши по-своему, и по-своему плохи. Каждый берет то, что ближе к его задачам и мировоззрению. Заменит ли что-то из этого друг друга — вряд ли это вообще когда-то произойдет. Появятся ли в ближайшие годы ЯП, делающие то же самое, но лучше — да, возможно.


                                Вот тогда и поговорим.

                                  –5
                                  «Python может одновременно выполнять только одну задачу.» Совсем не так.
                                  АПД: минусы от тех кто программирует на питоне? :)
                                    +3

                                    Скорее всего от тех, кто ждал не просто "Это не так", а объяснения.

                                    +2

                                    Очередная много буквенная похоронная статья по питону, а пациент все никак не умирает. А от отступов прочь руки, это святое)

                                      +1
                                      Мы у себя широко используем Python и любим его. Так как Питон нам небезразличен, потому и вынесли на обсуждениие (спорную) переводную статью о среднесрочных и долгосрочных перспективах языка. Чтобы язык и дальше развивался — о нём в том числе нужно спорить и говорить.
                                        +3

                                        Отступы такие плохие, что в скала3 (который дотти) такие отступы упёрли и сделали по-умолчанию) С этими изменениями скала код стал куда читаемее.


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

                                          +2

                                          Вот у меня прямо противоположные ощущения. Если есть IDE — то и фигурные скобки неплохи, а вот без IDE код на Питоне оказывается более аккуратным, нежели на других языках.


                                          Видимо, тут дело в том, что я читаю программы чаще чем пишу.

                                        +5
                                        Python возможно чем-то хорош.
                                        Но пробелы/табуляция как способ задавать вложенность блоков кода для меня просто красный флаг. Еще со времен Фортрана у меня к этому сформировалось четкое отторжение.
                                        Не понимаю, почему это показывают как преимущество для новичков и вообще как какое-то преимущество. Что может быть сложного в скобках { }?
                                        Преимущество скобок — при любом форматировании, любых настройках табуляции, любой операции copy/paste можно однозначно сказать что блок кода не изменил своей вложенности.
                                        Также если функция больше чем размер экрана, можно поставить курсор на одну из скобок, промотать экран и увидеть соответствующую ей открывающую/закрывающую скобку, которую IDE подсветит.
                                          +11

                                          Нет ничего сложного ни в том ни в том.


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


                                          То, что у вас отторжение — это чисто вкусовщина, не более. Питон хорош как раз тем, что возводит оформление кода в стандарт — хочешь не хочешь, а не получится писать код абы как (без отступов). Да, в 2020 это может казаться странным, потому что уже у всех есть IDE, которые все как надо выравнивают, но в свое время мне это показалось очень крутой фичей.


                                          К сравнению, у компилятора Go тоже довольно жестки требования к форматированию кода, несмотря на наличие скобок. И это тоже супер удобно, потому что писать код одинаково что так, что так — IDE сама делает отступы. А вот читать исходник без отступов (в тех ЯП, которые это допускают, и у тех программистов, кому религия не позволяет) — это просто пытка.

                                            +6
                                            Преимущество отступов для вложенности блоков — уменьшение визуального мусора. IDE точно так же может подсветить вертикальными линиями уровни отступов, это не проблема.

                                            Кстати, по моему преподавательскому опыту, отступы новичков скорее запутывают, скобочки более понятны. А вот читать Питон приятнее и (главное) легче, чем «скобочные» языки.
                                              +5
                                              Еще один плюс, с отступами очень неудобно делать много вложенных циклов и условий. Это бьет по рукам и не дает развернуться любителям таких штук. Тоже очень полезно.
                                                +3

                                                А каким образом скобки не будут бить по рукам? Фигурные скобки это всегда уровень отступа, некоторые IDE даже ругаться будут и автоматически отформатируют при первом возможном случае (при написании точки запятой, при закрытии скобки, ...).

                                                  +2
                                                  Еще и точку с запятой писать?
                                                  Не всегда программирование происходит в IDE, по крайней мере для Python. Довольно часто приходится и по ssh и vim что-то подправить.
                                                    +4

                                                    Без точки с запятой в большинстве япов с фигурными скобками у вас код не скомпилируется.


                                                    Ну а без IDE скобки уже удобнее, я выше уже писал. Заходил на ссш, ставил 11 пробелов вместо 12, на меня интерпретатор потом орал, приходилось снова файл открывать и искать, где там косяк

                                                      +3
                                                      для vscode есть прекрасное расширение, которое позволяет подключиться к удаленной машине по ssh
                                                        +3
                                                        Так-то оно так, но это нужно всегда под рукой иметь vscode…
                                              +1
                                              Проблемы скорости и параллельного выполнения давного уже решаются jit компиляцией. Вот простейший пример:
                                              @numba.jit(nopython=True, parallel=True)
                                              def logistic_regression(Y, X, w, iterations):
                                                  for i in range(iterations):
                                                      w -= np.dot(((1.0 /
                                                            (1.0 + np.exp(-Y * np.dot(X, w)))
                                                            - 1.0) * Y), X)
                                                  return w
                                              
                                                +2
                                                «Решаются» проблемы скорости таким образом только если мы большую часть возможностей языка выкидываем. Например, хотим чтобы был массив самых обычных классов — numba здесь никак не поможет. С переиспользованием кода между библиотеками тоже куча проблем (это не только о numba).
                                                Да даже массивов есть несколько вариантов в широкоиспользуемых библиотеках (numpy, tensorflow, был theano), и они друг с другом не совместимы.

                                                UPD: не заметил, что пост не новый — в сайдбаре был.
                                                +2
                                                И еще раз о скорости Python. Не так давно тут была статья с хорошим бенчмарком на многих языках программирования.

                                                Так вот, Python с jit компиляцией по скорости был на уровне C, Go и Rust. Поэтому миф о медленном Python давно уже пора забыть. Правда тут в другом.

                                                На Python можно писать медленно, но в 2020 году нет никаких проблем оптимизировать критические участки кода парой аннотаций для jit комплиции.

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

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

                                                Не говоря о том, что почти любая научная C/Fortran библиотека имеет обвязку на Python. И как дополнительный бонус крайне удобные Python ноутбуки и вменяемая система управления пакетами.
                                                  +5
                                                  Но, по большому счёту, скорость не имеет решающего значения. Производительные компьютеры и серверы настолько доступны, что речь разве что идёт о долях секунды. Конечному пользователю все равно, загружается его приложение за 0,001 или же за 0,01 секунды

                                                  Личный опыт — писал скрипт, который производит итеративный (2000+ итераций) расчёт на данных размера 4095x4095. Питон считал результат более 5 часов. Не помогал ни numpy с массивами вместо списков, ничего. После переписывания скрипта на C++ с задействованием GPU время расчёта уменьшилось до 4 секунд.

                                                  Производительность важна.
                                                    +7

                                                    Я не специлист в питоне, но есть подозрение, что можно было получить похожие цифры там без переписывания на плюсы. Вполне возможно, ключевая часть "зайдействование GPU", к языку оно слабо относится, там 99% времени это рассчет на гпу и перенос данных туда-обратно.

                                                    +2
                                                    С другой стороны, объявления переменных и операторы всегда являются операторами. Это означает, что лямбды не могут быть использованы для них.

                                                    Это различие между выражениями и утверждениями довольно произвольно и не встречается в других языках.


                                                    Не очень понял этот пассаж. То ли ошибка перевода, то ли что-то пытались сказать…
                                                    Да и вообще наезд на лямбды какой-то натянутый, они работают как анонимные функции by design.
                                                    Если вам нужно создавать новую переменную — сделайте полноценную функцию, не нужно пристраивать крылья к велосипеду.

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


                                                    А как же .pyc файлы?
                                                      +9
                                                      У автора логическая брешь в рассуждении: все перечисленные недостатки были у Python с рождения, но ничуть не помешали ему выйти на первое место на SO к 2020. Из чего делается вывод, что в будущем эти же самые недостатки как-то пошатнут его позиции?
                                                        +4
                                                        Особенности нашего любимого Python по большому счёту остались те же, а вот времена меняются и меняются очень сильно.

                                                        Поэтому да, то что раньше играло в плюс, со временем может играть уже и в минус.
                                                          +3
                                                          Возможно, это так; но тогда автору стоило именно об этом и писать.
                                                          Не «что в Python мне не нравится», а «что изменилось вокруг Python так, что он перестал отвечать потребностям».
                                                          Вот например, он критикует отношение Python к пробелам и табуляции. Что где поменялось так, что пробелы и табуляция раньше не были проблемой, а теперь стали?
                                                        +4
                                                        Питон медленный. Не, ну реально медленный.

                                                        У Python прекрасная двусторонняя интероперабельность с C и C++, о которой никто из конкурентов не может и мечтать. Это основная причина его успеха. Именно благодаря ей существуют NumPy и подобные пакеты. И если уметь ей пользоваться, то на выходе получишь высокую скоростью разработки с не менее высокой скоростью выполнения.

                                                        Несмотря на всю гибкость Python, использование лямбда довольно ограничено. Они могут быть только выражениями в Python, но не операторами.

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

                                                        Хотя это может не так красиво и неудобно для начинающих, это делает код более удобным для сопровождения.

                                                        С чего бы это вдруг?

                                                        Python не был создан для мобильных устройств.

                                                        Go и Haskell заточены?

                                                        Вместо этого код компилируется всякий раз, когда исполняется

                                                        Это не так. CPython компилирует код при первом выполнении. Можно скомпилировать и до.

                                                        У меня сложилось впечатление, что автор оригинала считает статическую типизацию однозначно хорошей, а динамическую однозначно плохой. Что, конечно же, ужасная глупость. Инструмент надо выбирать под задачу. Поэтому существование таких языков, как Rust не угрожало и не будет угрожать существованию таких, как Python.
                                                          +4
                                                          Ну, то есть они именно лямбды, в исконном значении этого термина, а не просто анонимные функции, как в других языках.

                                                          Мне почему-то кажется, что лямбда-счисление разрешает объявлять переменные, а лямбда в питоне объявить переменную не разрешит. Так что я бы не стал говорить, что именно в питоне исконные лямбды.

                                                            +2
                                                              +4

                                                              Вот как раз лямбда-исчисление никаких переменных не разрешает. Это ж чистое ФП, притом настолько чистое насколько это возможно — там нет вообще ничего кроме функций, даже стандартных типов данных, вроде bool или int (они все выражаются через функции).

                                                                +2

                                                                То есть понятия "лямбда-абстракция" не существует или оно означает не то, что я думаю (биндинг имени к некоторой функции)?


                                                                Lambda calculus (also written as λ-calculus) is a formal system in mathematical logic for expressing computation based on function abstraction and application using variable binding and substitution.
                                                                  +2
                                                                  Слово «переменная» в математике имеет несколько иное значение, чем в программировании.
                                                                  f(x,y)=x+y — функция двух переменных.

                                                                  PS: слово «binding» читается через «ай».
                                                                    +2
                                                                    Слово «переменная» в математике имеет несколько иное значение, чем в программировании.
                                                                    f(x,y)=x+y — функция двух переменных.

                                                                    Возьмём даже такой приземлённый язык как жс и получим


                                                                    const f = (x,y) => x + y;

                                                                    Как по мне, это — переменная.


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


                                                                    PS: слово «binding» читается через «ай».

                                                                    Знаю, просто иногда почему-то приятнее использовать такое слово. Как "адоб" вместо "эдоуби" и "зиксель" вместо "зайзел".

                                                                      +2
                                                                      То есть понятия «лямбда-абстракция» не существует или оно означает не то, что я думаю (биндинг имени к некоторой функции)?

                                                                      Нет, λ-абстракция — это создание из выражения, содержащего переменную x, функции этой переменной. (То же самое написано на рувики.) Это в точности то, что делает оператор lambda в Python.

                                                                      PS: ладно что не «зухель»
                                                            +5
                                                            На Питоне можно писать пьяным и программа всё равно работает.
                                                              +2

                                                              1) пайтон для ИИ/Нейронок и тд… (вот его стихия)
                                                              2) пайтон быстрее чем с++ в 14 ра => (Вот взяли 1 задачу и сказали программистам реализовать ее. Самое быстрое решение было за 2 часа на питоне, самое долгое за 14 часов на срр. Мораль ,, в первой версии стартапа можно ложить боль на много вещей. Нам важно чтоб продукт был сделан в кратчайщие сроки и если он будет перспективным — мы будем расширять функционал, оптимизировать, использовать другия ЯПы,, ну и как следствие бюддет на разработку можно скоратить в 7 раз. И эти деньги перераспределить на маркетинг
                                                              3) все уходит в мир облачных вычислений. (Зачем мне делать приложение на разные платформы, если я 1 раз сделаю логику на сервере и красивый UI на разные платформы с минимальным функционалом)
                                                              ИМХО.

                                                                +3
                                                                Умрёт так умрёт, пока мы на бинарной логике, принципы программирования не изменятся, та и библиотек много: зачем новые грабли, когда есть старые. А тем кто с математикой связан, вообще пофиг, она красавица до конца вселенной жить будет)
                                                                  +4

                                                                  проблемы выглядят высосанными из пальца.
                                                                  медленный? последствия динамичности и сложности оптимизации, решается JIT в PyPy. хочешь еще быстрее — пиши модули на C
                                                                  нет явного объявления типов нужно много тестов для отлова ошибок? аннотируешь код и подключаешь анализатор вроде mypy
                                                                  не подходит для мобил? успешные реализации есть — renpy неплохо себя чувствует в сфере игр. интерпретатор давно перетащили на множество платформ, просто никто еще не релизнул серьезную библиотеку для UI

                                                                    +1
                                                                    хочешь еще быстрее — пиши модули на C

                                                                    И зачем тогда вообще нужен питон?

                                                                      +5
                                                                      Затем, что бизнес-логику на С вы замучаетесь писать и поддерживать.
                                                                      Питон хорош именно тем, что вы можете весь проект написать на нём, а несколько маленьких вставочек в критичных местах — на C/С++.
                                                                    +3
                                                                    А почему, интересно, Питон не набрал популярности ни в 90-е, ни в 2000-е, а начал подниматься только в последнее десятилетие? Ну хорошо, в 90-е вычислительных ресурсов для Питона могло не хватать, но в начале 2000-ых такой проблемы точно быть не могло.
                                                                      +4
                                                                      Называют две основные причины: поддержка Гуглом с 2006, и появление Django в 2005.
                                                                        0
                                                                        Ещё то, что производительность компьютеров с тех пор сильно выросла.
                                                                          +2
                                                                          Для JS и PHP её хватало, а для Python не хватало?
                                                                        +2
                                                                        Строгие отступы делают код читабельнее, но их обязательность ухудшает поддерживаемость.
                                                                        — бред

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

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