Здравствуйте, Masterspline, Вы писали:

M>JS лучше как язык у которого более предсказуемый процесс развития. Без всяких "Ой, я устал — я ухожу" и нарушения обратной совместимости. Использование в конкретных нишах, которые ты перечислил, определяется наличием удобных библиотек. Тут где-то JS всех победил, где-то еще только на подходе.

У Python очень даже предсказуемое развитие. Какое еще "я устал — я ухожу", если 2.7 до сих пор жива?! JS — браузерный язык и очень хорош в этом деле, но зачем его тащить туда, где ему не место? Отсутствие библиотек ведь тоже не спроста, многообразие языков, отчасти, связанно с разнообразием доменных областей. Я не считаю что JS хорошо ложится на все доменные области, где сейчас царит Python.

M>Скала и кожура толком так и не стали мейнстримом. А у Котлина, разумные прагматичные разработчики и аккуратное эффективное продвижение (Kotlin объявлен основным языком для Android и Java оттуда уйдет за пару лет думаю). Также у него довольно много полезных возможностей и полная совместимость с Java (в версии JRE), хотя в энтерпрайзе и написании backend он не так широко распространен, как в Android. Например, в Котлине сделали корутины, которые позволяют довольно удобно писать асинхронный код (отправлять задачи на отдельный пул потоков, чтобы по окончанию выполнения, например, вызвать какой-то код в GUI потоке). GoLang активно используют из-за его go-рутин и удобной асинхронщины. Так вот Kotlin позволяет делать то же самое, только еще удобнее (в том числе и Native версия). Технически нет разницы, передавать данные через канал или передать корутину (данные с кодом) пулу потоков, при этом интерфейс корутин гибче (передаются не только данные в фиксированную горутину, а данные с кодом) и удобнее (интерфейс проще). Хотя, конечно, GoLang Котлину не подвинуть . И это только один пример. Также есть Kotlin (Native), в котором можно писать кроссплатформенные приложения, где не нужна мегапроизводительность и не хочется заниматься ручным управлением памятью. Разумеется Kotlin не идеален, но, IMHO, лучшее, что есть в этой сфере, как в техническом плане, так и продвижения.

Очень странно сравнивать подход Kotlin и Go, еще Erlang/Elixir не хватает. Корутины и CSP/Actors про сильно разные, по большому счету не пересекающиеся вещи, как их можно в одну кучу валить? Kotlin Native, потенциально, очень интересная штука, но, как мне кажется поздно уже, этот рынок давно и плотно поделен. А уж если говорить про JVM языки, то Clojure дает пожалуй больше преимуществ в скорости разработки и простоте решения по сравнению с остальными JVM-языками.

M>Для понимания, как все устроено на низком уровне и для написания высокопроизводительного кода. А также чтобы не казалось, что я вот написал код, а дальше происходит "магия" и на выходе получается результат. И если "вообще не вперся он в современном мире", то зачем ты на нем разрабатываешь?

Магия и результат вообще-то перпендикулярны языку, такие и у C++ разработчиков бывает, лично наблюдал. И, да, в современном мире C++ очень мало где нужен и часто, по инерции, используется там, где можно куда проще и дешевле сделать. А пишу я на нем потому (кстати, все меньше и меньше), что 18 лет опыта это довольно хорошо продаваемая штука, а компаний по инерции берущих C++ там, где он не нужен, до чертиков (хоть и количество стремительно сокращается).

M>>JS лучше как язык у которого более предсказуемый процесс развития. Без всяких "Ой, я устал — я ухожу" и нарушения обратной совместимости. Использование в конкретных нишах, которые ты перечислил, определяется наличием удобных библиотек. Тут где-то JS всех победил, где-то еще только на подходе.

KP>У Python очень даже предсказуемое развитие. Какое еще "я устал — я ухожу", если 2.7 до сих пор жива?! JS — браузерный язык и очень хорош в этом деле, но зачем его тащить туда, где ему не место? Отсутствие библиотек ведь тоже не спроста, многообразие языков, отчасти, связанно с разнообразием доменных областей. Я не считаю что JS хорошо ложится на все доменные области, где сейчас царит Python.

"Я устал — я ухожу", это про Гвидо, который отошел от "пожизненного диктаторства". Про совместимость — это переход 2->3. Современный JS (стандарт 2015, поддерживающий совместимость с предыдущей версией), на мой взгляд, ничем не хуже Python. Этот стандарт поддерживается повсеместно, т.е. сейчас пользоваться старым JS совсем нет смысла. До этого JS был недоязыком, недостатки которого пытался исправить Dart, например. Но сейчас в JS есть все, что есть в Python (из того, что сразу в голову приходит: полноценные переменные, модули, асинхронщина). На нем пишут GUI (такой же тормозной, как и на Python), консольные приложения, бакенд. При этом в Python постоянные терки в комитете, его вытеснили из Google и вытесняют из разных ниш, которые он занимает, а в JS все довольно стабильно и он медленно но верно занимает новые для себя ниши. Как я уже сказал, JS до сих пор для многих недоязык по привычке, но по факту — это новый Python с более стабильным фундаментом постепенно захватывающий новые ниши. У него более стабильный комитет его развивающий, фронтэнд из которого его никто не вытеснит и в котором куча разработчиков, постепенно захватывающих другие ниши (нода, консольные приложения для ноды и не только). Так что от написания скриптов для интеграции чего-либо JS останавливает то, что это никому не приходит в голову (ну, и наверняка, там не так много библиотек). Но, стоит это начать и Python постепенно подвинется (на обочину ).

Мое мнение, что "деды" переучиваться с Python не станут, а молодежь организует хайп для JS во многих сферах и Python станет новым Perl'ом. Потому что JS можно использовать почти везде, где есть Python, а наоборот не выйдет. Кроме того, у JS ниша сильно шире, поэтому при вопросе, какой язык изучать более подходящий выбор — JS. Ну, а Python будут использовать больше по привычке.

Здравствуйте, Masterspline, Вы писали:

M>Мое мнение, что "деды" переучиваться с Python не станут, а молодежь организует хайп для JS во многих сферах и Python станет новым Perl'ом. Потому что JS можно использовать почти везде, где есть Python, а наоборот не выйдет. Кроме того, у JS ниша сильно шире, поэтому при вопросе, какой язык изучать более подходящий выбор — JS. Ну, а Python будут использовать больше по привычке.

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

Здравствуйте, _hum_, Вы писали:
>И, думаю, если нет принципиальных достоинств в Python перед Typescript. то со временем многие все же предпочтут не изучать новый скриптовый язык Python, а использовать уже известный JS/Typescript

И, думаю, если нет принципиальных достоинств JS/Typescript перед Python. то со временем многие все же предпочтут не изучать новый скриптовый язык JS/Typescript, а использовать уже известный Python

Здравствуйте, Masterspline, Вы писали:

N>>У питона в wasm шансов намного больше.
M>Зачем Python запихивать в wasm, если можно использовать JS, который умеет все то же, что и Python?
Нет не умеет. Библиотек нормальных нет, экосистема из говна и палок. Собственно js сейчас нужен исключительно как байткод для TS и Scala.js.

Здравствуйте, Mamut, Вы писали:

__>>Собственно, subj. Насколько можно ожидать, что современный JS в варианте TypeScript (с дополнительной сильной типизацией) cможет заменить Python во всех областях, где тот господствует сейчас?
__>>Просто как-то не видно принципиальных преимуществ Python перед современным JS/Typescript, что, с учетом роста распространенности JS, как раз и наводит на мысль о подобном сценарии развития событий.


M>«Может ли в сферовакуумных задачах сферовакуумный TS/JS вытеснпть сферовакуумный питон?» Именно так выглядит твой вопрос. То есть он уже не имеет смысла. А на фоне «не ну а чо, люди с удовольствием побегут переписывать библиотеки они же опенсорсные» он не просто бессмысленный, он еще и глупый.

M>Где-то может вытеснить, где -то нет. Где-то их обоих вытеснит какой-нибудь другой (третий, пятый, десятый) язык.

Вы невнимательно читаете. Речь шла о вытеснении иp тех областей, где сейчас Python господствует (в первую очередь научсофт, обработка данных).

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, _hum_, Вы писали:

__>>Так Typescript хорош тем, что JS является его подмножеством, что позволят постепенно менять степень статичности типизации в своем коде от нуля (чистый JS) до полной. Тем самым достигается органическое сочетание достоинств как языков со статической, так и с динамической типизациями.

Б>Питон, как и множество динамических языков тянется в сторону статики (также как и статические тянутся в сторону динамических).

Б>В питоне тоже есть типы — type hints. И они также являются "надмножеством" питона. Т.е. "органическое сочетание достоинств как языков со статической, так и с динамической типизациями" есть и в питон, уже сейчас. И непонятно, почему надо предпочесть js.

в Python, насколько я слышал, полностью ввести естественную статическую типизацию с ходу пока не удалось (там есть свои трудности для сложных типов данных). В TS с этим как-то полегче.

__>>Ну...Тот же tensorflow, насколько я знаю, есть и на js. И, думаю, если нет принципиальных достоинств в Python перед Typescript. то со временем многие все же предпочтут не изучать новый скриптовый язык Python, а использовать уже известный JS/Typescript (а JS в настоящее время становится языком must know).
__>>(Я кстати сам столкнулся с этим вопросом — начать для своих научно-инженерных целей изучать Python, или остановиться на JS/Typescript + Wolfram, поскольку они в перспективе покроют все, что нужно)

Б>Зря, для научно-инженерных изучай лучше питон. Простота питона позволила привлечь в язык "непрограммистов", в частности математиков и инженеров. Позже, именно эти люди (непрограммисты) явились инициаторами создания библиотеки для своих нужд (numpy, scipy, etc). В javascript же все иначе, в научно-инженерную сферу ее тащат не математики и инженеры, а программисты, которые хотят все делать на одном языке. Поэтому, считаю, что "научная" часть в питоне будет развиваться быстрее, чем в js, пока в js не появится что-то новое и особенно удобное для пользователей.

так я же говорю, на своем примере (я и инженер, и математик — JS мне в любом случае пришлось бы выучить (потому что в вебе без него никуда, в свою очередь, и без вэба сейчас никуда). А начал смотреть в сторону Python для научных и инженерных приложений и вижу, что он во многих своих "плохих" качествах (отсутствие статической типизации, значительная завязка на ссылочные типы, не "классическое" ООП, медленность выполнения, невозможность контроля работы с памятью, сильная завязка на пакеты и т.п.) очень похож на JS. Пока принципиальное их отличие, которое я нашел — это, что JS — язык со слабой типизацией, а Python — с сильной. С этой точки зрения JS достигает максимума гибкости, ведь слабая типизация + динамическая = максимальная гибкость, потому он более привлекателен. С другой стороны такая гибкость чревата потерей надежности, но тут на выручку приходит TS. В итоге, получаем
динамический (+ статико-) язык со строгой типизацией (Python) vs статико-динамический язык со слабой типизацией (TS)
И не очень понятно, почему Python должен выиграть у TS. Тем более мне как перфекционисту нравится то, что JS в максимально возможной степени гибок, а TS еще и добавляет еще одну степень гибкости в возможности непрерывного перехода от динамической типизации к статической.
(Кстати, слышал, что во многом по этой причине в Python невозможно также хорошо организовать работу с функциями высших порядков и вообще функциональное программирование, как в JS)
p.s. На всякий случай — речь про современный JS (от 2016 года). Тот, который был до него, был ужасный ужас. Возможно, по этой причине, люди все еще относятся к новому JS по привычке, как к старому.

Здравствуйте, Artem Korneev, Вы писали:

AK>Здравствуйте, _hum_, Вы писали:

__>> Теперь же JS господствует и на бэке.

AK>Он там не господствует.

да, корректнее было бы сказать "активно распространяется".

Здравствуйте, student__, Вы писали:

__>Здравствуйте, _hum_, Вы писали:
>>И, думаю, если нет принципиальных достоинств в Python перед Typescript. то со временем многие все же предпочтут не изучать новый скриптовый язык Python, а использовать уже известный JS/Typescript

__>И, думаю, если нет принципиальных достоинств JS/Typescript перед Python. то со временем многие все же предпочтут не изучать новый скриптовый язык JS/Typescript, а использовать уже известный Python

нет, такая симметрия не проходит, потому что JS в любом случае придется учить (основы его необходимы для того, чтобы работать с Web), а вот Python — на выбор (пока(?)).

Здравствуйте, _hum_, Вы писали:

__>p.s. На всякий случай — речь про современный JS (от 2016 года). Тот, который был до него, был ужасный ужас. Возможно, по этой причине, люди все еще относятся к новому JS по
Ты о каких-то тонкостях рассуждаешь. Это все не важно.
На каком языке из двух можно быстрее разработать и удобно поддерживать модель/рассчет в вычислительной области? Ответ на питоне, js тут и рядом не садился.
Возможно ли доделать js, чтобы на нем было также? Возможно, но нужны миллионы человеко часов.
Будет ли результат сильно лучше? Нет, не будет, так как языки более менее одинаковые.

Кстати ты в курсе что для питона существует богатые вебморды, которые не требуют js? Например dash.

Здравствуйте, _hum_, Вы писали:

>в Python, насколько я слышал, полностью ввести естественную статическую типизацию с ходу пока не удалось (там есть свои трудности для сложных типов данных). В TS с этим как-то полегче.

Не понятно, о чем речь. Что такое естественная статическая типизация? И о каких сложных типах данных идет речь, в которых в TS полегче?

>так я же говорю, на своем примере (я и инженер, и математик — JS мне в любом случае пришлось бы выучить (потому что в вебе без него никуда, в свою очередь, и без вэба сейчас никуда).

В DS можно знать питон и не знать js — это нормально.

>(Кстати, слышал, что во многом по этой причине в Python невозможно также хорошо организовать работу с функциями высших порядков и вообще функциональное программирование, как в JS)

Это вовсе не из-за типизации. Просто в питоне лямбды более ограничены по сравнению с js — для сложных случаев предлагается описывать явную функцию (def). Хорошо это или плохо — зависит от.

Здравствуйте, novitk, Вы писали:


N>Ты о каких-то тонкостях рассуждаешь. Это все не важно.
N>На каком языке из двух можно быстрее разработать и удобно поддерживать модель/рассчет в вычислительной области? Ответ на питоне, js тут и рядом не садился.

Я не работал в таком ключе ни на одном из них (для прототипирования своих задач использовал Wolfram, для реализации и поддержки — C++), потому ничего не могу сказать. (Кстати, разве поддержка/сопровождение программы без статической типизации не является ужасной задачей. Я к тому, что как-то слабо верится, что в Python с этим все ОК, как вы говорите.)

N>Возможно ли доделать js, чтобы на нем было также? Возможно, но нужны миллионы человеко часов.
N>Будет ли результат сильно лучше? Нет, не будет, так как языки более менее одинаковые.

Ну вот я, в частности, и пытаюсь выяснить, можно ли о них говорить, что они "более менее одинаковые" Или все-таки та же нестрогая типизация и поддержка функционального программирования станут kill-features в будущем

N>Кстати ты в курсе что для питона существует богатые вебморды, которые не требуют js? Например dash.

Сильно не влезал, но там идет работа с DOM? Если нет, то веб-мордой это назвать нельзя


Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, _hum_, Вы писали:

>>в Python, насколько я слышал, полностью ввести естественную статическую типизацию с ходу пока не удалось (там есть свои трудности для сложных типов данных). В TS с этим как-то полегче.

Б>Не понятно, о чем речь. Что такое естественная статическая типизация? И о каких сложных типах данных идет речь, в которых в TS полегче?

"Естественная" — значит, такая же, как в мейнстрим языках со статической типизацией (то есть, не вызывающая реакции wtf). По этой теме то, что под рукой нашлось — это вот несколько минут из доклада:Типы: Python vs Typescript / Григорий Петров [Python Meetup 29.04.2016]

>>(Кстати, слышал, что во многом по этой причине в Python невозможно также хорошо организовать работу с функциями высших порядков и вообще функциональное программирование, как в JS)

Б>Это вовсе не из-за типизации. Просто в питоне лямбды более ограничены по сравнению с js — для сложных случаев предлагается описывать явную функцию (def). Хорошо это или плохо — зависит от.

Так а ограничения не из-за того ли, чтобы не войти в противоречие с сильной типизацией? В любом случае этот момент — серьезный минус в сторону Python.

В общем, если концептуально (а мы ведь, не забываем, в разделе "Философия программирования" ), то пока вопрос сводится к:

(статико-) динамический язык со строгой типизацией [Python] vs (статико-) динамический язык со слабой типизацией [TS]
в области инженерно-научных задач

Здравствуйте, _hum_, Вы писали:

>"Естественная" — значит, такая же, как в мейнстрим языках со статической типизацией (то есть, не вызывающая реакции wtf). По этой теме то, что под рукой нашлось — это вот несколько минут из доклада:Типы: Python vs Typescript / Григорий Петров [Python Meetup 29.04.2016]

Все мейнстрим языки разные, и они используют разную типизацию. Что у тебя вызывает wtf в питоне по сравнению с TS на примере доклада?
На указанном тобой месте доклада в питоне показывается "естественная" типизация — номинальная, как в большинстве языков. А вот в TS — структурные (structural) типы, неестественные для менйстрима. Но (внезапно!) такие типы в питон тоже есть. См. https://www.python.org/dev/peps/pep-0544/

>Так а ограничения не из-за того ли, чтобы не войти в противоречие с сильной типизацией?

Конечно нет. Как они могут войти в противоречие?

>В любом случае этот момент — серьезный минус в сторону Python.

Не понял про какой "этот момент" ты говоришь?

>В общем, если концептуально (а мы ведь, не забываем, в разделе "Философия программирования" ), то пока вопрос сводится к:
>(статико-) динамический язык со строгой типизацией [Python] vs (статико-) динамический язык со слабой типизацией [TS]
>в области инженерно-научных задач

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

Здравствуйте, _hum_, Вы писали:

__>(Кстати, разве поддержка/сопровождение программы без статической типизации не является ужасной задачей. Я к тому, что как-то слабо верится, что в Python с этим все ОК, как вы говорите.)
Не является, если код нормальный и тесты есть.

__>Или все-таки та же нестрогая типизация и поддержка функционального программирования станут kill-features в будущем
Термина "нестрогая типизация" нет. Типизация бывает динамическая и статическая. Если тебе нужна статическая, то там совсем другие языки и скорость разработки. Динамическая бывает хорошая, как у Питона. и говно, как у js. Да, возможно в последней версии js починили, но обратную совместимость никто не отменял и с этим говном придется жить много лет. Поддержка FP у js/py примерно одинакова. У питона есть некоторое неудобство в создании анонимных лямбд, но это мелочь. Разница, как я уже сказал, в экосистеме. Есть ровно три платформы с нормальной экосистемой: cpython, jvm и .net. Все остальное сильно хуже.

__>Сильно не влезал, но там идет работа с DOM? Если нет, то веб-мордой это назвать нельзя
Да, в py на сервере. Латентность выше чем у реакта и т.д., для игр не подходит, но для вычислительного софта нормально.

Здравствуйте, vmpire, Вы писали:

V>Не может. Под питон написано много библиотек, которых нет под js.
V>Говоря о замене, нужно рассматривать не просто язык, а всю его экосистему.

Кстати, вот вам и бизнес-идея — сделать переводчик с языка Python на JS.

__>Вы невнимательно читаете. Речь шла о вытеснении их тех областей, где сейчас Python господствует (в первую очередь научсофт, обработка данных).

Тогда ответ: нет, не вытеснит. Причины описаны в этой подветке: https://rsdn.org/forum/philosophy/7507679

Автор: vmpire
Дата: 31.07.19

__>в Python, насколько я слышал, полностью ввести естественную статическую типизацию с ходу пока не удалось (там есть свои трудности для сложных типов данных). В TS с этим как-то полегче.

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

__> что он во многих своих "плохих" качествах (отсутствие статической типизации, значительная завязка на ссылочные типы, не "классическое" ООП, медленность выполнения, невозможность контроля работы с памятью, сильная завязка на пакеты и т.п.) очень похож на JS. Пока принципиальное их отличие, которое я нашел — это, что JS — язык со слабой типизацией, а Python — с сильной.

Нет. Приниципальные отличия не эти. Принципиальные отличия:

Ключевое, и максимально важное для научсофта и обработки данных:
— в Питоне достаточно легкий interop с С/C++, что позволяет легко подключить любые уже существующие высокопроизводительные библиотеки.

Дополнительно:
— стандартная библиотека Питона гораздо шире
— количество готовых и обкатанных библиотек, в том числе для научсофта и обработки данных, гораздо больше

---

ЗЫ. Здесь не плоский форум, а древовидный. Поэтому надо отвечать в соотвествующих ветках, а не в одной, но сразу нескольким людям.

Здравствуйте, Mamut, Вы писали:

__>>в Python, насколько я слышал, полностью ввести естественную статическую типизацию с ходу пока не удалось (там есть свои трудности для сложных типов данных). В TS с этим как-то полегче.
M>И? Статическая типизация сама по себе — не цель. Как видно, питон господствует в научсофте и обработке данных, а он динамически типизирован. При этом статически типизированных языков — вагоны.
Почему-же не цель? По моему очень даже цель.

Почему-то все думают, что статическая типизация это как в C\С++\Java с выписыванием кучи объявлений типов переменных.
Но по факту статическая типизация это проверка типов без запуска программы. Её можно прикрутить даже к динамически типизированным языкам. Потому что для каждого выражения мы можем статически (без запуска) вычислить множество допустимых типов и проверить дальнейшие действия с этим выражением в рамках вычисленных типов.

Пример с JS это прекрасно показывает. Если вы не в курсе, то TS сейчас может проверять типы для JS-кода. И такая проверка иногда выявляет баги в старом коде, которые не были найдены сотнями пар глаз.

Здравствуйте, _hum_, Вы писали:

__>

__>(статико-) динамический язык со строгой типизацией [Python] vs (статико-) динамический язык со слабой типизацией [TS]
__>в области инженерно-научных задач

Один умный человек уже достаточно давно написал про строгую и слабую типизацию
https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/

Um. I don’t actually know what I mean by those terms, so perhaps that is the question I should be asking. What does it really mean for a language to be “weakly typed” or “strongly typed”?

“Weakly typed” means “this language uses a type verification system that I find distasteful“, and “strongly typed” means “this language uses a type system that I find attractive“.

Перевод

Хм, я точно не уверен что означают эти термины (строгая и слабая типизация — прим. пер.), так что возможно этот вопрос должен задавать я. Что на самом деле означает "слабая" и "строгая" типизация?

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

Здравствуйте, Shmj, Вы писали:

V>>Не может. Под питон написано много библиотек, которых нет под js.
V>>Говоря о замене, нужно рассматривать не просто язык, а всю его экосистему.

S>Кстати, вот вам и бизнес-идея — сделать переводчик с языка Python на JS.
Не вижу рынка сбыта данного продукта

__>>>в Python, насколько я слышал, полностью ввести естественную статическую типизацию с ходу пока не удалось (там есть свои трудности для сложных типов данных). В TS с этим как-то полегче.
M>>И? Статическая типизация сама по себе — не цель. Как видно, питон господствует в научсофте и обработке данных, а он динамически типизирован. При этом статически типизированных языков — вагоны.
G>Почему-же не цель? По моему очень даже цель.

Нет. Не цель.

G>Почему-то все думают, что статическая типизация это как в C\С++\Java с выписыванием кучи объявлений типов переменных.
G>Но по факту статическая типизация это проверка типов без запуска программы.

В каком месте С/С++/Java запускаются для проверки типов?

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

Можно. Так делают, например, в Эрланге при помощи Dialyzer'а.

G>Пример с JS это прекрасно показывает. Если вы не в курсе, то TS сейчас может проверять типы для JS-кода.

Я в курсе. И flow может. И? Дальше-то что? Кто-то из-за этого ломанется переписывать библиотеки с Питона на JS/TS?

Здравствуйте, _hum_, Вы писали:

__>p.s. На всякий случай — речь про современный JS (от 2016 года). Тот, который был до него, был ужасный ужас. Возможно, по этой причине, люди все еще относятся к новому JS по привычке, как к старому.

Кстати, даже в ES2016 в JS/TS отсутствует переопределение операторов. В DS-библиотеках в питоне такое переопределение используется очень часто. Да и в других библиотеках тоже.

Здравствуйте, _hum_, Вы писали:

Вся мощь питона — это несколько встроенных функций и многочисленные готовые биндинги к сишным библиотекам.

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

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

Но — питон весьма неплох как замена башу и прочим говношелам.

ЗЫ JS — тоже не нужен

Здравствуйте, _hum_, Вы писали:
__>нет, такая симметрия не проходит, потому что JS в любом случае придется учить (основы его необходимы для того, чтобы работать с Web), а вот Python — на выбор (пока(?)).

А кто сказал "Веб"? Вот мне, например, Веб нафиг не нужен.