Чем плох Python?

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

Тут написана неправда.

Во-первых модули это не часть ES2015, они появились гораздо позднее. Во-вторых динамический импорт никуда не делся. Модули так же могут грузиться условно, внутри функция или блока кода, в циклах, и даже не обязательно быть синглтонами (их идентити соответствует url, и достаточно добавить к адресу модуля любой get-параметр ?1 ?2 ?3, чтобы один и тот же модуль грузился сколько угодно раз).

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

А я разве писал, что старые модули были запрещены к применению? Однако же, старые и новые модули не взаимозаменяемы. По крайней мере, совместимость не идеальная, и то, что удалось загрузить по require, может не получится подключить через import — и наоборот. Это касается как обработки экспортов по умолчанию, так и хитрости поведения конкретных загрузчиков.

То что прогнулись и стали вводить имитацию статической типизации. Сюда же и всякие паттерн-матчинги относятся. Я понимаю, что не могли не прогнуться, но это не отменяет моего разочарования.

Чего в этом плохого?

При чем тут require? Новые es-модули, которые через import подгружаются, могут быть подгружены динамически.

if(a > b) import('./some module')

То что прогнулись и стали вводить имитацию статической типизации. Сюда же и всякие паттерн-матчинги относятся. Я понимаю, что не могли не прогнуться, но это не отменяет моего разочарования

Чего в этом плохого?

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

Паттерн-матчинг — это вообще какой-то карго культ, типа «у них есть — почему у нас нету?». А то, что смотрится оно в питоне как сова на глобусе — никого не волнует. По крайней мере создателей фичи не волнует.

А то, что смотрится оно в питоне как сова на глобусе — никого не волнует. По крайней мере создателей фичи не волнует.

Чо-т в голос. Как же ты прав.

Чего в этом плохого?

Я в своё время перешёл на питон чтобы лишний раз не указывать типы, но тут на язык набежала какая-то свора жабистов-хаскеллистов и всё испортила.

При чем тут require? Новые es-модули, которые через import подгружаются, могут быть подгружены динамически.
if(a > b) import('./some module')

Да, только это опять-таки будут синглетоны, поскольку механизм загрузки отличается от старого:

https://tc39.es/ecma262/#sec-hostimportmoduledynamically

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

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

и вообще не рекомендуется к применению

Это снова неправда. Который раз.

Я в своё время перешёл на питон чтобы лишний раз не указывать типы, но тут на язык набежала какая-то свора жабистов-хаскеллистов и всё испортила

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

Но 10 тысяч строк на Python, это 40 тысяч строк на Java. Вопрос: если Вы пишете в одиночку и проект предполагается небольшим (менее 10 тысяч питонячих строк), то не будет ли чудачеством в этом случае использовать Java вместо Python?

В 2к21 сравнивать приходится не с java, а с kotlin. И тут python не выигрывает никак.

А то, что смотрится оно в питоне как сова на глобусе — никого не волнует

Так можно сказать про любую фичу питона. Но если смотреть на питон как на учебный язык, то всё логично. Как-то же надо студентам показывать что за зверь такой паттерн-матчинг. Число для лаб годится вполне.

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

Читай ссылку на стандарт, которую я дал, особенно эту часть:

«The completion value of any subsequent call to HostResolveImportedModule after FinishDynamicImport has completed, given the arguments referencingScriptOrModule and specifier, must be a module which has already been evaluated, i.e. whose Evaluate concrete method has already been called and returned a normal completion.»

Если кто-то при динамическом импорте ES6 модулей выполняет их несколько раз — это нестандартное поведение.

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

Если кто-то при динамическом импорте ES6 модулей выполняет их несколько раз — это нестандартное поведение.

Это стандартное поведение.

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

Если кто-то при динамическом импорте ES6 модулей выполняет их несколько раз — это нестандартное поведение.

Это стандартное поведение

Но пруфов не будет — пиши стандарт дальше.

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

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

Даже при классической компиляции вовсе не обязательно гнать по всем алгоритмам оптимизации весь исходник, достаточно прогнать те 20%, в которых программа проводит 80% времени исполнения.

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

Про JS и Python я тебе сразу сказал, что в силу выбранной модели там невозможна полноценная работа оптимизатора. Разница между ними не качественная, а в количестве костылей реализации. Но я думаю, что в будущем эти языки придут к двухфазной модели исполнения compile time — run time, как в том же лиспе. Просто это будет сделано как внедренный поддиалект, который на 99% совместим с динамическим диалектом, но не допускает модификации классов в run time.

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

Но пруфов не будет — пиши стандарт дальше

...зато пруфы будут у меня:

$ echo "console.log('loaded')" > test.js
$ node
Welcome to Node.js v13.6.0.
Type ".help" for more information.
> let p1 = import('./test.js')
undefined
> (node:1704) ExperimentalWarning: The ESM module loader is experimental.
loaded
> let p2 = import('./test.js')
undefined

Ну и удачи писать стандарты. Видимо, это проще, чем читать их.

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

Да я же писал выше, что это уже есть. MSVC достаточно давно умеет делать профилирующее выполнение для определения оптимизаций.

Про JS и Python я тебе сразу сказал, что в силу выбранной модели там невозможна полноценная работа оптимизатора. Разница между ними не качественная, а в количестве костылей реализации. Но я думаю, что в будущем эти языки придут к двухфазной модели исполнения compile time — run time, как в том же лиспе

Но это уже будет другой язык. Вроде Nim. С лиспом тоже была аналогичная история, и совместимости между старыми диалектами и новыми нет.

Спасибо за демонстрацию количества собственных извилин.

Отправляйся выше по ветке к моему сообщению, и попытайся еще раз. Я верю, ты справишься.

И всё, питон умирает

Не, ну после VBA всё равно очень хорошо.

byko3y и PolarFox уже ответили.

Попытаюсь дополнить. Вот тут говорили про одиночку пишущего 10к строк. Мы приняли как аксиому, что динамическая типизация хороша, пока эти условия не нарушаются. Предположим, проект перерос 10к строк. Тут у нас появляется дилемма: либо переписать код на языке со статической типизацией, либо пытаться уродовать имеющийся код на питоне. Я сторонник первого пути.

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

В 2к21 сравнивать приходится не с java, а с kotlin. И тут python не выигрывает никак.

Да, kotlin выглядит симпатично. Даже немного жаль что, скорее всего, я на нём ничего никогда не напишу.

питонщик навсегда?

Нет. Пишу на C# и чистом C. Иногда на C++. Питон активно использовал где-то до 2013 года. Сейчас очень редко с ним работаю.

Чем он хуже по сравнению с

Perl

Тем что ответ на этот вопрос уже не важен. Perl помер, будь он в 100 раз лушче или хуже. Живость сообщества - фича языка.

Ruby

Ничем. Python лучше.

Javascript

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

другими подобными языками?

Например?

Никто не знает как Тиобе приходит к рейтингу где Classic Visual Basic и Go одинаково популярны, а просто Visual Basic живее JavaScript.

По поему они поехали башкой

Так что нужно то? UnboundMethod что ли? Какие-то придирки слабенькие. Если питоновское ООП разбирать, то там столько чудес вылезет. Начиная с множественного наследования.

Например?

Lua, tcl, julia, groovy. Я их всех обобщил до «другие ЯП», поскольку сравнивать с каждым в отдельности особого смысла нет - это все нишевые языки, и каждый в своей нише будет лучше питона, который претендует на универсальность. Тем более, что на форуме вряд ли много знатоков того же тикля

Если оторвать башку от корыта со смузи и немного подумать, то можно прикинуть сколько в мире легаси на VB или перле. Кто-то с этим работает и гуглит тему. Но думать это же не твой конёк. Все ресурсы мозга сожрал синтаксис раста.

Javascript

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

Вопрос с последней парты: а чем асинхронность динамического интерпретируемого языка лучше? Я прекрасно понимаю, почему она лучше в случае nginx — это была оптимизация взаимодействия с ядром, в том числе избавление от неисправимо кривого ядерного планировщика, взамен которому nginx по сути работает в режиме зеленых потоков. А вот зачем асинхронность питону? Там же десяток-другой строк кода с легкостью перекроют стоимость переключения контекста, а делать на питоне сверхбыстрые и сверхтонкие сервера без логики не имеет вообще никакого смысла. Разве что ради бенчей на techempower.

И я бы не говорил так оптимистично про JS, потому что есть два языка — это node.js и браузер. Код между которыми довольно плохо портируется, как между Jython и CPython. И не в последнюю очередь потому, что в ноде нагородили асинхронных потоков, на которых много чего написано, которых нет в браузерном JS, и которые сделаны в древнем стиле колбэков, вместо более современных промисов и async/await. Да, в последнее время идет тенденция к унификации, но в наследии всё печально, а это наследие еще долго не будет переписано.

Никто не знает как Тиобе приходит к рейтингу где Classic Visual Basic и Go одинаково популярны, а просто Visual Basic живее JavaScript

Классический васик вообще никому не нужен, но работы по VBA валом.

Classic Visual Basic это скорее всего и есть VBA с вкраплениями VB6 и олдскульного ASP.

Под Visual Basic они скорее всего имеют vb.net, на котором тоже тонны легаси успело накопиться.

А вот зачем асинхронность питону?

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

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

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

Lua

Ну его создавали наверное не как general purpose, а так хз

tcl

Смотрим выше - Perl

julia,

Она соревнуется в нише и там я бы даже топил за ее успех. Хорошая задумка, хотя заставляет REPL тормозить

groovy

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

Lua

Ну его создавали наверное не как general purpose, а так хз

Так а кто из этих языков в своих истоках был по-настоящему Генералом Цель? «Perl was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier», «I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers», PHP и вовсе тяжело было назвать языком программирования — это был скорее веб-сервер для домашней странички со встроенным примитивным языком конфигурации. Все эти языки были достаточно специализированными языками общего назначения, но не создавались изначально для написания всего на свете. В отлчиие, например, от создания Java и Pascal, у которых вообще не было конкретного назначения.

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

Дай я тебя расцелую. Пожалуйста, пойди и объясни это разрабам CPython.

Времена другие тогда были. Софта не было. Высрал говно, все, это самый гениальный язык программирования всех времен и народов, молимся на него, какие сладкие эти золотые капли. Студент написал какое-то всратое ядро, так его до 2021го года все фиксим, а 12209 еще там.

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

В итоге выиграет какая-то, но не потому что лучше, а потому что просто договорились в нее вкладывать. Хайп это фича. Больше хайпа - больше рук, библиотек, инструментов, книг. Больше этого всего - лучше язык. Вон фича того же Rust кроме того что это уже качественный продукт - хайп. Был бы хайп по поводу Crystal, Zig, V, даже «хорошее или ничего» D - то ради прогресса нужно было бы в них инвестировать. Главное чтобы не оказаться в ситуации когда будешь лететь в ракете на Марс, а там весь софт на С или С++. А из ракеты уже не спастись, так в бога возверуешь

Дай я тебя расцелую. Пожалуйста, пойди и объясни это разрабам CPython

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

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

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

А если мы делаем что-то более креативное модное клиент-микросерверное, ну или пишем банальную скрейпилку, то тут уже профит есть. С тысячей-другой открытых сокетов управляться проще чем с таким же количеством потоков, особенно если им надо как-то обмениваться данными. В своё время даже популярен был костыль gevent (он в отличие от нынешних async/await), который именно для оптимизации и использовался (в отличие от нынешних паттернов он правда не прибавлял коду в наглядности, использовался сугубо для оптимизации).

gevent

Да он и щас…. гм… используется.

А если мы делаем что-то более креативное модное клиент-микросерверное, ну или пишем банальную скрейпилку, то тут уже профит есть

Но это не значит, что нужно всегда всё делать через жоасинк и подгонять под это язык. Юзкейсов для асинхронщины не очень много, а шума многовато. Есть такие две темы в IT шумные: ФП и асинхронность. Когда пограмисту делать нечего, он начинает их вылизывать и оценивать технологии по уровню зацикленности на ФП и асинхроне. И отсюда неожиданные властители дум появляются вроде эзотерического хаскеля или ничтожного жаваскрипта.

Студент написал какое-то всратое ядро, так его до 2021го года все фиксим, а 12209 еще там

Не совсем понял, что за 12209. Подозреваю, что это какое-то CVE, но оно не гуглится.

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

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

Теперь по поводу рыночка, который порешал. IT не сводится к опенсорсу — аналогичная картина с захватом рынков происходит и в коммерческой разработке. Lotus 1-2-3, изначально VisiCalc, доминировал на рынке электронных таблиц, загнав Multiplan (кто про него помнит?) на задворки рынка. Но пришла винда, под которую задержался выпуск лотуса — и MS Excel обогнал лотус. Аналогично с Ami, WordPerfect, StarWriter. Был ли это хайп? Это корректнее назвать «сетевой эффект», то есть, рост ценности продукта с ростом его популярности.

В качестве примера, который попал посередине между коммерческим софтом и опенсорсом, я бы привел C++, который изначально был коммерческой разработкой, но был подхвачен в виде альтернативных и несовместимых друг с другом реализаций. C++ выехал на IT гиганте того времени — AT&T. Гиганте, который довольно быстро сдулся, но продукт жизнедеятельности его в виде C++ мы хаваем по сей день.

Реально на голом хайпе взлетело не так много проектов. PHP — единственный пример, который с ходу вспоминается. У линукса не было хайпа, и линукс довольно долго был никому не нужной осью. По факту в 1999 линукс всё еще был нонейм поделкой студента:

https://en.wikipedia.org/wiki/File:Operating_systems_used_on_top_500_supercom...

Я подозреваю, что и линукс, и питон таки были запущены в массы именно гуглом. Особенно я подчеркиваю, что современные контейнеры — это на 99% разработка гугла и на 1% Docker inc, которые даже свой докер написали на языке гугла. Представьте, где был бы линукс сейчас без cgroups и контейнеров.

Хайп является следствием поддержки крупным игроком, игроком, который ввалил кучу ресурсов в запуск технологии. Как погибший Sun, который вложил миллиарды долларов в Java, ужасный язык программирования, но язык в итоге взлетел, и только из-за количества вложенных в него ресурсов.

Такая вот неутешная картинка получается для разработчиков фундаментальных технологий: если вы не гугл, не фейсбук, не майкрософт, не оракл, и даже не мозила, то ваши технологии, как правило, никому не нужны. За очень редкими исключениями. Так что я лично по поводу своей разработки раcширения питона особых надежд не питаю — авось она хотя бы поможет найти работу годную, а там дальше уже можно отправлять проект на свалку, к остальным подобным загнувшимся проектам.

на какаю работу рассчитываете после допилки питона?

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

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

Гвидо один раз рискнул мусор выкинуть, разрабатывая 3ю версию, но комьюнити это настолько не понравилось, что до сих пор воняет

Честно говоря, различия между второй и третьей версией настолько ничтожны, что даже сложно это назвать каким-то выбрасыванием мусора. Однако, мой опыт общения с питонистами хабра говорит, что 95% питонистов — полные кретины, которые самую бессмысленную фичу возведут в ранг идола и будут до последней капли крови биться за ее сохранение. Я был удивлен тому, сколько минусов я получил просто высказав мысль о необходимости убрать из питона бесполезный %фичанейм%. Я не знаю, есть ли в других сообществах настолько поехавшие неадекваты. Я абсолютно точно знаю, что среди эффективных менеджеров-секретарш очень популярно добавлять и не убирать — это такой бзик женской психологии, который может быть полезен в некоторых сферах, но зачастую деструктивен в IT.

«Асинхронный» он потому, что дальше писать на вложенных коллбеках уже было просто никак.

И async/await вкручивался уже поверх готовых промисов, которые сначала делали совсем не ради языка, а в библиотеках просто уже по нужде, во всех смыслах.

Но получилось таки неплохо.

Не понимаю ненависти к JS.

Это уже давно не тот JS, в котором даже map не было, а for работал только через особую уличную магию.

Честно говоря, различия между второй и третьей версией настолько ничтожны, что даже сложно это назвать каким-то выбрасыванием мусора.

+1

Вся спецоперация вообще непонятно с какой целью проводилась.

на какаю работу рассчитываете после допилки питона?

А хер его знает. Я плохо знаком с рыночком, и вообще ненавижу массовую разработку, потому что там планка квалификации разработчиков с каждым годом опускается всё ниже и ниже — яндекс уже курьеров садит писать код, скоро начнет нанимать уборщиц и грузчиков. Мои сверстники давным-давно уехали за бугор писать на C#/C++, а я вот сижу капризничаю: это мне не очень, то мне не то. С одной стороны это позволило мне развиться в совершенно не связанные с IT сферы и не стать полным аутистом, который ничего не знает в жизни, кроме карьеры в IT; с другой стороны — чот из меня не получился бизнесмен или хотя бы аналитик-консультант, с широким кругозором, способностью комбинировать знания из разных сфер, и обучаться новым вещам до того, как они станут модными. Причем, я даже знаю почему так получилось, причем, я даже не намерен ничего делать, чтобы это положение исправить. Я был бы рад аутично пердолиться с развитием собственного проекта, но шанс успеха крайне мал. Вот так и живем.

ради выкидывания однобайтных строк емнип