В том, что она не нужна в сишке, и такие вещи вызывают бугурт среди кодеров, ибо уже есть Objective-C, Swift, Rust и прочие вполне алекватные языки для замены Си при таких потребностях, как автоматическое управление памятью
Не согласен. Возможность создавать абстрактные методы и свойства типов значительно уменьшает кол-во кода, которое нужно для решения задачи, т.к. его легко использовать для разных задач, без переписывания интерфейса. Да, я знаю, абстрактные типы есть и в фортране/c++/и т.д., но они не такие гибкие, как в питоне.
Сказал бы сразу: в питоне высокая абстракция ПО СРАВНЕНИЮ с фортраном, никто бы и не спорил.
Да, именно это и имел ввиду. В сообщении выше так и сказал кстати. Хипстерскими новоязыками не пользуюсь (пока что), поскольку для них нет нужных мне библиотек (тоже пока что).
Наверное с того, что там есть статическая типизация?
Как я уже сказал, это всего лишь делает их статически типизированным говном мамонта.
А вот с чего Вы обозвали их гавном мамонта я не очень понял - с учетом новых то стандартов…
На систему типов новые стандарты, увы, повлияли мало. Очень мало. Она как была убожеством, так и осталась. Справедливости ради, для того времени, когда она создавалась, это, возможно, было и очень здорово, но сейчас даже как-то неприлично в дискуссии про статическую типизацию приплетать плюсы. А то я тоже могу начать какой-нибудь Basic вместо питона подставлять.
Угрёбищный тем, что нужно использовать компот из разных языков, со всеми их недостатками. Это конечно работает, но по слухам так делать совсем не обязательно, в теории.
Не то что бы я сильно следил за новыми стандартами, но auto и decltype уже являются большим шагом вперед. Там ЕМНИП была еще какая то мулька с автовыведением типа функции, но я этим пока не пользовался.
сейчас даже как-то неприлично в дискуссии про статическую типизацию приплетать плюсы.
Де-факто плюсы до сих пор являются менйстримом, в ряде областей они просто безальтернативны. Так что вполне себе прилично.
нужно использовать компот из разных языков, со всеми их недостатками.
И со всеми их достоинствами. Можно так не делать, но если вы хотите быстрое вычислительное ядро и удобный и компактный интерфейс, то либо используете связку из двух ЯП, либо упарываетесь по всяким плюсовым извращениям что бы получить что то похожее на простой питоний интерфейс который идет почти из коробки (ну с парой своих либ м.б.).
Там джулия вроде обещает более элегантное решение проблем. Я потыкал, почитал доки, вроде бы имеет больше смысла, чем питон для моих задач. Уже год упрашиваю админов установить таки на кластере, попробовать на реальных задачах. Всё у них руки не доходят. Пока что напрягают всех переделывать древние скрипты на питон3. Что же, переделываем.
Я не верю в чудеса. Динамическая типизация это накладные расходы в райнтайм, автоматическое распараллеливание априори будут сливать решениям которые в которых распараллеливание сделано руками с учетом специфики задачи.
Медленнее чем интел фортран, это наверняка, с ним тяжело спорить на интел платформах. Насчёт других версий фортрана не уверен. Да даже если медленнее фортрана, но не настолько как питон, это уже имеет смысл для большого круга задач.
С «чистым» питоном сравниваться вообще нет смысла. Да, numpy какой нить они обгонят, это несложно. Связку питон-плюсы/фортран (правильно написанные) обогнать не смогут, даже приблизится не смогут.
Ну да, наверное имеет какой то смысл… Не, больше ЯП хороших и разных это всегда хорошо!
Связку питон-плюсы/фортран (правильно написанные) обогнать не смогут, даже приблизится не смогут.
По производительности наврядли обогнать, сравняться - легко на многих тестах. А вот по скорости разработки - это надо посмотреть. Я согласен, что можно изолировать медленные куски кода на питоне, ускорить их, и это не так сложно, поскольку соответствующие инструменты есть. Но все эти f2py/cython/numba добавляют таки гемороя в процесс разработки.
Одна из фич питона увеличивающая скорость разработки это как раз динамическая типизация
Я бы предпочел для начала дать определение статическое/динамичекой типизации, иначе о чем-то конкретно говорить. Современные статически типизированные языки позволяют совать в переменные и аргументы значения произвольных типов без предварительного объявления этих типов, и, тем не менее, многие зовут это статической типизацией.
То, о чем ты хотел на самом деле сказать - это что-то вроде «отсутствие необходимости помнить типы и загромождать их объявлениями код», но это не есть определение динамической типизации. Сама по себе же динамическая типизация даже в питоне считается плохим тоном, вместо нее в переменных и параметрах хранятся данные строго ограниченного числа типов.
за счет того, что не приходится бороться с ограничениями статической типизации + нужно банально писать меньше букофф
Контраргумент: динамическая типизация замедляет разработку, потому что сразу обнаруживаемые ошибки при статической типизации ошибки приходится обнаруживать отладкой.
Статическая типизация в питоне уже давно есть - это cython. Cython - это костыли, цель которых преодолеть непреодолимые косяки питона
Код на чистом Cython — это Си с синтаксисом питона. Из преимуществ разве что удобное создание прокладок между питоновым и сишным кодом, но это уже скорее проблема CPython, в котором за столько лет так и не смогли высрать ничего удобнее, чем «arguments clinic».
Контраргумент: динамическая типизация замедляет разработку, потому что сразу обнаруживаемые ошибки при статической типизации ошибки приходится обнаруживать отладкой.
Это заблуждение. Статическая типизация никак не помогает обнаруживать ошибки. Я на этих ошибках собаку съел. Статическая типизация нужна только тогда, когда нужно распространять бинарники под разные платформы клиентам. Больше ни для чего она не нужна. Делать бинарники ahead of time возможно и в динамических языках, но несколько сложнее, чем в статических.
Я бы предпочел для начала дать определение статическое/динамичекой типизации
Они уже давно даны;-)
Современные статически типизированные языки позволяют совать в переменные и аргументы значения произвольных типов без предварительного объявления этих типов, и, тем не менее, многие зовут это статической типизацией.
Это и есть статическая типизация, просто не так сильно ограничивающая разработчика как в старых ЯП. Я согласен с тем, что она настолько же удобна и при этом позволяет овить ошибки на этапе компиляции, в некотором смысле это идеал.
Сама по себе же динамическая типизация даже в питоне считается плохим тоном
Если не считать всякие попытки проверки типов которые в новые питоны вроде притащили и которыми я не знаю кто пользуется, то в питоне сплошь и рядом динамическая типизация.
Контраргумент: динамическая типизация замедляет разработку, потому что сразу обнаруживаемые ошибки при статической типизации ошибки приходится обнаруживать отладкой.
Бесспорно, но на маленьких проектах это замедление некритично.
За счёт высокой абстрактности. Всё, что можно сделать на питоне, можно сделать и на фортране, только будет раз в 10 больше кода. А на сях раз в 50 больше кода
Очень смелое высказывание, но ничем не подкрепленное. На хабре была статья с экспериментальным сравнением, и даже с самыми грязнющими хаками программа на питоне оказалась лишь в 6 раза меньше, чем самый большой вариант той же программы, написанный на расте: https://habr.com/ru/post/456638/
Очень смелое высказывание, но ничем не подкрепленное.
Это высказывание подкреплено только личным опытом, больше ничем.
На хабре была статья с экспериментальным сравнением, и даже с самыми грязнющими хаками программа на питоне оказалась лишь в 6 раза меньше, чем самый большой вариант той же программы, написанный на расте
Я лично на расте опыта не имею, так что про раст высказываться не буду. Ну и делать мощные выводы на основании одной программы с хабра тоже не буду.