Реализация компилируемого Python возможна?

Зачем весь тред? тут есть вменяемые люди а есть клоуны вроде Вас с Dll. На клоунов время тратить жалко.

Но Вы можете рассказать афигительных историй про то насколько плюсы медленнее чем С. А я пойду чайку выпью.

В racket всё проверяется, что в обычном, что в типизированном. Хмммм…

хочу получить скорость на уровне C/C++/C#

Ну так тебе тогда и нужен C/C++

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

Можешь глянуть Rust.

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

Вот это

без намёка на обработку любых нестандартных ситуаций довольно быстро

само по себе на порядки облегчает написание кода, вне зависимости от вида типизации в языке. Не в ДТ дело

хочу получить скорость на уровне C/C++/C#

Ну и пиши на c#, вполне неплохой язык с уймой сахара. Работает в линуксах, для любителей змей (2.x) есть ironpython.

ТС опять троллингом занимается.

Ты внимательно на его ник глянь. Там походу не троллинг, а нечто другое)

к примеру C#

Ну я так глубоко не копал;-) Перегрузку в рантайме для py2 делал, было - но джаст фо фан, не пошло.

Вообще интересно что будет в четвертом питоне.

https://shizik.booru.org/index.php?page=post&s=view&id=67

возможна ли сишка с автоматическим подсчётом ссылок

Но ведь она возможна, в чём троллинг будет?

Но Вы можете рассказать афигительных историй про то насколько плюсы медленнее чем С. А я пойду чайку выпью.

И мне налей тоже…

ironpython

Он жив ли? Мне кажется, аналог на жабе шевелится лучше и умеет в трёшку.

но это никак не характеризует плюсы

А при чём тут вообще плюсы?

В том, что она не нужна в сишке, и такие вещи вызывают бугурт среди кодеров, ибо уже есть Objective-C, Swift, Rust и прочие вполне алекватные языки для замены Си при таких потребностях, как автоматическое управление памятью

В психушку набирает команду? Чтобы там писать свой питон на стероидах для запуска ракет КимЧеныром?

Он просто смузихлёб со стажем и не в курсе, что в том же glib есть ARC. Хотя про glib говорят, что она для таких, как он.

В том, что она не нужна

Но исходная тема звучала так:

возможна ли

Не сходится!

Не получается подумать?

За тебя? Нет?

А при чём тут вообще плюсы?

О_О

Реализация компилируемого Python возможна? (комментарий)

когда упрешься - биндишь модуль на С/плюсах/фортране и продолжаешь ковыряться

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

Нет

Спасибо, что признался

А, то есть, ты это имел в виду под

Высокая абстрактность.

Это её следствие.

Пожалуйста, обращайся ещё.

Ну да. Ты зачем-то начал говорить о плюсах, вот мне и интересно, с чего вдруг?

Это не следствие, по крайней мере, не в данном случае.

Ну если там HR, то ему можно, он не в теме. Не агрись на него. Поржем да разойдемся.

Не согласен. Возможность создавать абстрактные методы и свойства типов значительно уменьшает кол-во кода, которое нужно для решения задачи, т.к. его легко использовать для разных задач, без переписывания интерфейса. Да, я знаю, абстрактные типы есть и в фортране/c++/и т.д., но они не такие гибкие, как в питоне.

Наверное с того, что там есть статическая типизация? А вот с чего Вы обозвали их гавном мамонта я не очень понял - с учетом новых то стандартов…

в фортране/c++/и т.д.

Опять про говно мамонта. Сказал бы сразу: в питоне высокая абстракция ПО СРАВНЕНИЮ с фортраном, никто бы и не спорил.

Да. Даже при таком угрёбищном подходе

Чем же он угребищный то?! Отличный подход, в числодробилках там прямо вот вообще в кассу…

Сказал бы сразу: в питоне высокая абстракция ПО СРАВНЕНИЮ с фортраном, никто бы и не спорил.

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

Наверное с того, что там есть статическая типизация?

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

А вот с чего Вы обозвали их гавном мамонта я не очень понял - с учетом новых то стандартов…

На систему типов новые стандарты, увы, повлияли мало. Очень мало. Она как была убожеством, так и осталась. Справедливости ради, для того времени, когда она создавалась, это, возможно, было и очень здорово, но сейчас даже как-то неприлично в дискуссии про статическую типизацию приплетать плюсы. А то я тоже могу начать какой-нибудь Basic вместо питона подставлять.

Пойми что такое скриптуха, узнаешь ответ на свой вопрос.

Спойлер: да, но смысла около нуля.

Чем же он угребищный то?!

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

Не то что бы я сильно следил за новыми стандартами, но auto и decltype уже являются большим шагом вперед. Там ЕМНИП была еще какая то мулька с автовыведением типа функции, но я этим пока не пользовался.

сейчас даже как-то неприлично в дискуссии про статическую типизацию приплетать плюсы.

Де-факто плюсы до сих пор являются менйстримом, в ряде областей они просто безальтернативны. Так что вполне себе прилично.

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

И со всеми их достоинствами. Можно так не делать, но если вы хотите быстрое вычислительное ядро и удобный и компактный интерфейс, то либо используете связку из двух ЯП, либо упарываетесь по всяким плюсовым извращениям что бы получить что то похожее на простой питоний интерфейс который идет почти из коробки (ну с парой своих либ м.б.).

Там джулия вроде обещает более элегантное решение проблем. Я потыкал, почитал доки, вроде бы имеет больше смысла, чем питон для моих задач. Уже год упрашиваю админов установить таки на кластере, попробовать на реальных задачах. Всё у них руки не доходят. Пока что напрягают всех переделывать древние скрипты на питон3. Что же, переделываем.

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

ЗЫ да, переход на py3 это подстава;-(

Я не верю в чудеса.

Там никаких чудес. Всё по науке. Всё логично.

ну так это будет работать медленнее чем тот же фортран сделанный прямыми руками.

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

С «чистым» питоном сравниваться вообще нет смысла. Да, numpy какой нить они обгонят, это несложно. Связку питон-плюсы/фортран (правильно написанные) обогнать не смогут, даже приблизится не смогут.

Ну да, наверное имеет какой то смысл… Не, больше ЯП хороших и разных это всегда хорошо!

Связку питон-плюсы/фортран (правильно написанные) обогнать не смогут, даже приблизится не смогут.

По производительности наврядли обогнать, сравняться - легко на многих тестах. А вот по скорости разработки - это надо посмотреть. Я согласен, что можно изолировать медленные куски кода на питоне, ускорить их, и это не так сложно, поскольку соответствующие инструменты есть. Но все эти f2py/cython/numba добавляют таки гемороя в процесс разработки.

Одна из фич питона увеличивающая скорость разработки это как раз динамическая типизация

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

То, о чем ты хотел на самом деле сказать - это что-то вроде «отсутствие необходимости помнить типы и загромождать их объявлениями код», но это не есть определение динамической типизации. Сама по себе же динамическая типизация даже в питоне считается плохим тоном, вместо нее в переменных и параметрах хранятся данные строго ограниченного числа типов.

за счёт чего ДТ увеличивает скорость разработки

за счет того, что не приходится бороться с ограничениями статической типизации + нужно банально писать меньше букофф

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

Статическая типизация в питоне уже давно есть - это cython. Cython - это костыли, цель которых преодолеть непреодолимые косяки питона

Код на чистом Cython — это Си с синтаксисом питона. Из преимуществ разве что удобное создание прокладок между питоновым и сишным кодом, но это уже скорее проблема CPython, в котором за столько лет так и не смогли высрать ничего удобнее, чем «arguments clinic».

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

Это заблуждение. Статическая типизация никак не помогает обнаруживать ошибки. Я на этих ошибках собаку съел. Статическая типизация нужна только тогда, когда нужно распространять бинарники под разные платформы клиентам. Больше ни для чего она не нужна. Делать бинарники ahead of time возможно и в динамических языках, но несколько сложнее, чем в статических.

Я бы предпочел для начала дать определение статическое/динамичекой типизации

Они уже давно даны;-)

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

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

Сама по себе же динамическая типизация даже в питоне считается плохим тоном

Если не считать всякие попытки проверки типов которые в новые питоны вроде притащили и которыми я не знаю кто пользуется, то в питоне сплошь и рядом динамическая типизация.

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

Бесспорно, но на маленьких проектах это замедление некритично.

За счёт высокой абстрактности. Всё, что можно сделать на питоне, можно сделать и на фортране, только будет раз в 10 больше кода. А на сях раз в 50 больше кода

Очень смелое высказывание, но ничем не подкрепленное. На хабре была статья с экспериментальным сравнением, и даже с самыми грязнющими хаками программа на питоне оказалась лишь в 6 раза меньше, чем самый большой вариант той же программы, написанный на расте: https://habr.com/ru/post/456638/

Очень смелое высказывание, но ничем не подкрепленное.

Это высказывание подкреплено только личным опытом, больше ничем.

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

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