Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
Вот как будет: половина языков будут по чуть-чуть вытеснять Python и возможно на нём будут писать небольшие терминалы. MicroPython будет примерно на пике и возможно половина людей которые сидят на CircuitPython перейдут на него. Либо наоборот. В итоге сам Python будет уже не тем, как сейчас. Я конечно не уверен что так и будет, но это мои догадки.
Пора требовать чтобы статьи ИИ помечали тегом.
Изначально это требование должно быть и на YouTube и так далее…
Везде, где СМИ не является официальным (блогеры на ютуб, на личных форумах и прочих площадях) — было неплохо, а я считаю необходимым, показывать плашку на главной странице или под каждым постом, что: «Это личное мнение автора», в случае когда не указаны ссылки на первоисточник.
ИИ-гадание на кофейной (привет Java!))) гуще. ;-)
Вместо того, чтобы расписывать местами довольно банальные рассуждения (о том, что может быть, а может и не быть, но... не суть важно! Всё будет обязательно как-то и так и как-то не так), лучше было бы порассуждать о том, каким должен стать сам язык программирования.
Что должен предложить программисту Python? Каким мог бы быть Python 4.0? Как должна измениться сама разработка на Python?
Следующий шаг в развитии языка обязательно будет связан с развитием его синтаксиса. Смысл синтаксиса языка программирования заключается в том, чтобы предложить программисту точные изобразительные средства для решения повседневных задач. В Python'е такими средствами являются отступы, генераторы, итераторы и декораторы (замыкания и yield'ы), всевозможные коллекции и возможность реализовать собственный вычислительный объект, функционирующий как коллекция. Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка. Есть ли у Вас такая идиома на примете?
Лично мне, кажется логичным, сделать f-строки некоторым стандартом, то есть — отбросить приставку f. Но если требуется какое-то специальное форматирование, то можно было бы использовать специальную синтаксическую конструкцию по типу старой Python-овской функции format(), которая описывает этот самый формат.
Проблема всякого языка программирования — это опора на библиотеки: есть предметная область — создаём библиотеку функций для решения соответствующих задач. А развитие языка программирования заключается в том, чтобы реализовать требуемые функции в виде явных синтаксических конструкций. Спрашивается, если у нас есть numpy.array, то почему у нас не может быть явного синтаксического способа работы с массивами? Да, никто не мешает использовать словари: например, можно реализовать простые матрицы с доступом по двум координатам — A[(i,j)]. Но! Хотелось бы иметь возможность писать A[i,j]. (Возможно, я что-то пропустил, и этим своим замечанием попадаю просто в небо?!! И всё уже давно реализовано в Python 3.14.x.) Мы могли бы на уровне языка явно определять. как мы храним элементы обыкновенной плоской матрицы (или. даже, многомерного числового массива) — по строкам или по столбцам (как в MATLAB/OCVTAVE), или, вообще, используется какое-нибудь особое представление (вроде диагонального), не говоря уже и о возможности применения "разреженных" (sparse) матриц (словарь, в этом смысле, как раз, и воспроизводит эту самую разреженную матрицу).
Думается, в Python-е можно было предусмотреть специальные локальные (предметно-ориентированные) языки для решения узких задач. Ведь, ещё одна проблема — это значительная перегрузка функций и операторов. Если бы можно было бы создавать локальные вычислительные модели, тогда можно было избавиться от встроенного косноязычия Python-е, когда приходится создавать объект определённого класса и мириться с его реализацией и выбранными способами доступа...
Лично мне не хватает в Python-е угловых скобок (типа <>), при помощи которых можно было бы обозначать кортежи, а круглые скобки освободить для функций. (Тогда не придётся писать (,) для обозначения пустого кортежа.)
Следующий шаг в развитии языка обязательно будет связан с развитием его синтаксиса. Смысл синтаксиса языка программирования заключается в том, чтобы предложить программисту точные изобразительные средства для решения повседневных задач. В Python'е такими средствами являются отступы, генераторы, итераторы и декораторы (замыкания и yield'ы), всевозможные коллекции и возможность реализовать собственный вычислительный объект, функционирующий как коллекция. Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка. Есть ли у Вас такая идиома на примете?
А я вот думаю по другому, особенно про это:
"Если в практике встречается какая-то идиома, она должна быть в явной форме выражена в синтаксисе языка."
Набор базовых идиом языка должен быть ограничен, особенно в таком языке, как Питон, который является и клеем и языком работы с данными и еще 100 примененией. Почему? Потому, что ядро такого языка желательно иметь:
А) компактное.
Б) Легкое для изучения.
Питон, собственно и был задуман таким. Например из циклов только for и while.
Набор базовых идиом языка должен быть ограничен, особенно в таком языке, как Питон, который является и клеем и языком работы с данными и еще 100 примененией.
А давайте, уж, простите мне такую фамильярность, рассмотрим подробнее эту самую работу с данными.
Где у нас данные? В файлах? В базах данных? Как мы хотели бы видеть работу с данными?
Лично мне очень интересен такой вопрос: почему мы не можем расписать всю логику работы своего приложения на сервере (в самой базе данных) и, просто, подключаться тонким клиентом к серверу и делать всё, что нам нужно?
Понятное дело, что Python здесь, как бы, ни при чём. Но было бы интересно посмотреть на то, может ли разработка приложений выглядеть как-то по другому.
Можно и так, даже кое-кто так и делал. Данные обрабатывали во встроенных процедурах, сейчас можно и ЯП в базах данных использовать. Лично я с таким не встречался, те кто видел, вспоминали об этом как об ужасном кошмаре.
По идее БД умеет две вещи, хранить данные и выдавать подмножества хранимых данных. Но делает это хорошо. Если мы запихаем туда еще и обработку данных, что улучшится? Ничего. Все то, что мы делаем сейчас снаружи просто придется делать внутри базы. Но теперь мы делаем это из кирпичиков типа {БД}<->{логика обработки на ЯП}<->{Библиотеки для обработки данных}, а так все будет запихано в базу данных и вместо набора кирпичей получим один бетонный блок. Потеряем гибкость, а выигрыша не будет.
Как бы мне объяснить Вам, что именно меня беспокоит?
Допустим, мы хотим сделать какое-то приложение, требующее какой-то базы данных. Мы начинаем описывать сами хранимые данные, объекты, отношения, ограничения целостности, права и роли. И всё это — на уровне баз данных! А потом наступает момент написания клиентского приложения, где... многие элементы уже сделанного нами ранее описания воспроизводятся. Не буквально, но довольно близко к первоисточнику. Спрашивается, зачем?
A[I, j] уже сто лет работает и используется. Что оно будет означать и как будет матрица в памяти лежать как раз в языке фиксировать не надо.
Ну и синтаксис менее важен в эпоху генерации кода ИИ, так что если и будет развитие, то в чём-то другом
Но этот успех построен на его роли «языка-клея», управляющего высокопроизводительными низкоуровневыми библиотеками.
Могу поделиться чужим мнением, оно мне кажется весьма верным. Успех построен на том факте, что Python стал основным языком периода хайпа больших данных. Усилиями Гугол стал.
Роль языка клея к успеху Python точно отношения не имеет, выбор альтернатив огромен. Тут есть другое аналогично чужое мнение - Python является лучшим, в том числе самым простым, языком для прототипирования и экспериментирования. Это, кстати, объясняет почему он не просто медленный, а чудовищно медленный - можно было сделать быстрее, но за счёт легкости тех самых прототипирования и экспериментирования, а с этим было бескомпромиссно. Бескомпромиссно - это когда и мельчайшее не допускается. Пользователи клея - уже второй круг пользователей.
Погоня за скоростью - пустое времяпрепровождение. С одной стороны, к быстрым языкам Python всё равно по скорости не приблизится. С другрй стороны, быстрый Python давно существует, называется Julia, может использовать модули Python, первых мест эта скорость что-то не обеспечивает.
Я не вижу причин по которым может произойти массовый уход от Python, равно не вижу причин, помимо инерции, почему с Python нельзя уйти прямо сейчас, хоть на JavaScript, Dart или Go. Поэтому судьба Python - политическое решение и принимать его будут Гугол с ИИ.
Что-то я не заметил большой схожести у Юли с Питоном. Зато есть проекты типа IronPython. Если они научатся поддерживать все питоновские библиотеки, Питон ещё долго будет трудно подвинуть.
Роль языка клея к успеху Python точно отношения не имеет, выбор альтернатив огромен.
Поверьте мне, имеет, я использую Питон почти с самого начала, когда на выбор клея были: bash, tcl и Perl. Я воспринял его как "Perl" aбез его недостатков. А тогда собственно и гугла-то еще не было. Как сказал кто-то (и это было верно еще в прошлом тысячелетии): "При всем богатстве выбора, альтернативы Питону нет!"
Какие такие недостатки у перл? Перл - идеальный клей!
Например, "write only". И почему-то этот идеальный клей, уступил python свое место в linux окружении.
Люди, которые утверждают, что программы на Perl - "write only", либо некомпетентны, либо клоуны. Выбирайте. Obfuscated contest бывает на любом ЯП.
"Почему-то уступил" -- есть несколько теорий об этом. Я считаю, что сыграло несколько факторов одновременно. Perl5 был очень успешным в нескольких областях сразу, но не был "идеальным". Из него задумали сделать "идеальный" ЯП - Perl6. За дело взялись "большие умы", которые по итогу страшно затянули процесс, начавшийся примерно в 2000. Первую версию, которую официально объявили "минимально пригодной к использованию" выпустили в 2015, сменив при этом имя на Raku. Ощущение "заброшенности" пятой версии длилось больше 10 лет, от этого и случился отток в питон. Веб на себя тогда успел подмять похапе.
Где-то в 2003 я пытался для себя понять что за волна вокруг питона подниматься начала, всячески поизучал его в сравнении с перлом и не обнаружил что качественно нового он мне даст, в итоге остался на перл.
Это было так в самом начале, а потом Python как минимум однажды, когда он едва не убился о Юникод, рождался заново, вместе со своей популярностью.
Если по получаемым возможностям на вложенные усилия по обучению - да, конечно, альтернативы Python нет. Будет ли это цениться через 10 лет - я не знаю.
Один из моментов, почему я думаю питон был принят "научным сообществом", что это скриптовый язык как перл, но с ООП в стиле джавы. Как системный клей перл, всё-таки, лучше.
"научному сообществу" как раз пофиг на ООП и "ООП в стиле джавы" (откуда вообще такой вывод, в питоне ООП точно не в стиле java, а если учесть еще и то что он появился раньше java) в частности. Это сообщество, как раз часто пишет код в стиле write only, надо решить текущую задачу, решил и пошел дальше, поддерживать, то что нафигачил не нужно. "Научному сообществу" нужен простой синтаксис и куча доступных библиотек, что и предоставил python
Ставлю на красное - Mojo, Python как Ruby отойдет в сторонку...
Мой прогноз: Питон будут и дальше интенсивно улучшать, за счет улучшений он ухудшится настолько, что придется выдумавать ему замену, без всех этих синтаксических сахаров, отказов от ГИЛ и т.д.
Кстати, вот эта фраза:
"без необходимости прибегать к громоздкому multiprocessing",
хорошо показывает, что автор не понимает самых основ устройства программ и операционных ситсем. Почему multiprocessing такой бронебойно устойчивый, а многопоточность - источник проблем с надежностью. Например браузеры были многопоточными, но потом пришлось их переделывать на мультипроцессорные.
Julia останется мощным, но нишевым инструментом в академической среде. Ее главная проблема — экосистема, которая на порядки уступает Python. Она не сможет составить конкуренцию Python в корпоративном Data Science и ML из-за колоссальной инерции существующих библиотек, фреймворков и обученных специалистов.
Ну так и бросите этот Python. Создали новый язык, круче, но сидят думают…
Так же и Python лет 15 назад не имел всю эту обвязку (инфраструктуру и библиотеки).
Будет интересно в 2035 на фоне Top-3 чартов с сабжем посмотреть опять эти комменты. На мой взгляд успех Питона в абсолютной невозмутимости его сообщества прогнозами, вангованием, "гвоздями в крышку" итп перлами, в изобилии плодящимися на всех крупных Инет-площадках.
То же касается совершенно спокойного отношения питонистов к факту что в большинстве программ на Питоне работают либы других языков (С++ итд), и от этого абсолютно ни у кого не подгорает. Ну чужое и ладно. И как же контрастно выглядят апологеты других языков в подобных случаях. Да, техно-ревность она такая.
Хотя... можно было бы пофантазировать о том, как мог бы выглядеть Python 4.0...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Python через 10 лет: Гонка за производительностью или закат эпохи?