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

ормальные языки с достаточно юзабельным type inference не так давно появились/стали популярными, поэтому большинство считают, что статическая типизация — это что-то вроде java со всеми вытекающими

Да, и я хочу подчеркнуть, что type inference уже частично есть и в жаве.

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

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

Уже возможна, ибо RAII завезли в GCC/clang.

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

Зато индустрия их не освоит. Это, в каком-то смысле, интересная задачка: взять кусок дерьма и попытаться сделать из него конфетку.

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

JS стал вторым языком после Lua, который смог по скорости выполнения сравняться с жавой/шарпом.

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

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

Да Swift хорош. Но есть слухи, что Си побыстрее будет.

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

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

Уже есть, называется Cython

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

Жуля хоть и не делает чудеса, но все равно позволяет писать достаточно быстрый код без запарок, и, самое главное, без лютого гемора питоньих биндингов, которые представляют из себя «третий язык».

Это, в каком-то смысле, интересная задачка: взять кусок дерьма и попытаться сделать из него конфетку.

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

Lua

А этот язык в продакшене есть? Честно говоря ничерта о нем не знаю

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

OpenResty и Tarantool, а так, только встройка в играх.

Lua имеет скорость выполнения, сравнимую с жавой/шарпом.

Не имеет.

Чушь. Luajit наибыстрейший. Реально. Это самая быстрая vm на планете. C#|Java даже рядом не валялись

лютого гемора питоньих биндингов,

У меня весь биндинг обычно занимает три строки (включая вообще всю сборку), дальше работает swig и давно написанный шаблонный Makefile. ЧЯНТД?

Пруфца бы.

Ты же не маленький, поищи в инете тесты luajit на алгоритмах и java jit

— Luajit наибыстрейший! Кококо!
— Пруфы?
— Ну, ты сам поищи, где-то там в синтетике…

Предложи что тебе нужно? Написать тебе не синтетические тесты? А какие, мне реально интересно

Парсер хттп напиши

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

Цитата месяца. Что у вас за каша в голове - даже не представляю.

https://eklausmeier.wordpress.com/2016/04/05/performance-comparison-c-vs-lua-vs-luajit-vs-java/

Вот в этом бенчер LuaJIT по скорости равен Go

Всё уже написано, надо только поискать и самому сравнить, прошу: https://github.com/luvit/luvit/tree/master/examples

Покажи что-то из синтетики хотя бы уровня benchmark-game.

А слив в реальных задачах — OpenResty — можешь понаблюдать глянув бенчи techempower.

Оно даже fib рекурсивно быстрее жавы не может, чо уж там, тут поискать можешь.

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

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

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

Если ты вот это имел ввиду, так себе бэнч:

local PORT = 8080
local HOST = «127.0.0.1»
...
local request = «GET / HTTP/1.1\r\n\r\n»

Даже если бы нормальный хттп был бы, а не один start line, всё равно есть подозрение, что оно в io упираться будет

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

Поржал, спасибо.

И я в том числе не вижу прямой связи кроссплатформенности со статической типизацией.

Не, не нужно перевирать слова. Речь не о кросс-платформенности, с которой у питона например всё в порядке, а о AOT компиляции. Это разные вещи.

Во-первых, 1.7, во вторых, есть GCC Go. В третьих я это бенчил, luajit слил Go, а джаве вообще вдвое.

Код-инжекшены в убогом питон (комментарий)

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

Нет, это динамическая типизация по определению из википедии, поскольку тип аргумента/переменной не проверяется на этапе компиляции. О чем я и пытался сказать, когда писал про определения. Более того, JavaScript приобретает элементы статической типизации при JIT-компиляции.

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

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

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

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

Да. Но изначально я не видел никаких условий «только на маленьких проектах».

Силушка, однако.

Хаха, оно даже питону слил в лице numba.

Статическая типизация никак не помогает обнаруживать ошибки

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

Ну и в IDE (включая vim/emacs) заметно удобнее когда jump to definition на каком-нибудь методе с популярным методом вроде .update() прыгает именно на нужную имплементацию вместо того, чтобы показать выбор из 300 в разных частях проекта.

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

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

Я с ним никак не знаком. Зато я знаком со своим личным опытом, который говорит, что при желании можно писать

#include <stdlib.h>
...
fp = popen("ls *", "r");
if (fp != NULL)
{
  char *buffer = malloc(10*1024*1024);
  fgets(buffer, 10*1024*1024, fp);
  char s;
  while (s = strtok(buffer, "\n"))
    ...
}

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

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

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

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

Вообще-то в академической среде задачу вполне уже решена. А по поводу индустрии - это нужно было как минимум гуглу.

Lua

А этот язык в продакшене есть? Честно говоря ничерта о нем не знаю

Совсем недавно это был основным языком для логики игр.

luajit да (и то, я бы не сказал сравнимую, правильней будет сказать «сопоставимую», ибо заметно медленней, там нечего сравнивать), референсный интерпретатор нет

LuaJIT быстрее референса даже с отключенной JIT-компиляцией, если что. Когда говорят про скорость выполнения Lua, обычно имеют в виду именно LuaJIT. Знаешь почему? Потому что он компилирует код очень быстро, в отличие от PyPy, который обычно делает оптимизацию ближе к концу выполнения. Именно поэтому никто не спешит переходить на PyPy — он на некоторых задачах медленнее CPython.

Дефолтный будет быстрее CPython ну раза в полтора отсилы, при том, что язык убогий и немощный в отличие от питона

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

Чушь. Luajit наибыстрейший. Реально. Это самая быстрая vm на планете. C#|Java даже рядом не валялись

По бенчам примерно 2015 года выяснилось, что V8 приблизился к LuaJIT по производительности. Бабло побеждает зло.

Нет, это динамическая типизация по определению из википедии, поскольку тип аргумента/переменной не проверяется на этапе компиляции.

Вполне себе проверяется.

def f(x): return x*2 # динамическая типизация
...
y = f(open("test.dat")) # упадет в рантайме

template <typename T> T f(T x){ return x*2; } // статическая типизация
...
auto y = f(fopen("test.dat", "r")); // упадет при сборке

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

раскройте пожалуйста чем одно отличается от другого.

Да. Но изначально я не видел никаких условий «только на маленьких проектах».

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

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

Нет, притон вообще в среднем короче чем С/С++ для условно средней задачи. Для некоторых задач сильно короче. Для немногих задач С/С++ окажутся короче, главным образом если нужны какие то хитрые императивные циклы со сложной индексной арифметикой. На питон это ложится плохо, ну или приходится много думать.

У меня весь биндинг обычно занимает три строки (включая вообще всю сборку), дальше работает swig и давно написанный шаблонный Makefile. ЧЯНТД?

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

Вообще то я биндю классы со сложными полями и кучей функций со сложными аргументами.

Покажи что-то из синтетики хотя бы уровня benchmark-game

Это и есть тесты из benchmark game.

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

Мне написали голословное утверждение «Си в 50 раз больше питона». Я ответил, что это голословное утверждение, и на питоне можно написать программу объемнее, чем на Си — это зависит от программиста, а не от языка. Если же программист просто пишет код и не выёживается, то соотношение объемов C/Python получается всего несколько раз.

Да ему похер, он не адекватен. Он требовал бенчи, где ява слила луа, ему дали. А он: хи-хи-хаха, и убежал в закат. Типично.

Соотношение объемов не очень релевантно, нужно смотреть на скорость разработки. Условно считается (на основе моего опыта и опыта коллег) что разница по скорости разработки составляет порядок. Но это неточная цифра, и понятно что все очень сильно зависит от задачи (как я уже писал).

Нет, это динамическая типизация по определению из википедии, поскольку тип аргумента/переменной не проверяется на этапе компиляции

Вполне себе проверяется

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

раскройте пожалуйста чем одно отличается от другого.

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

И я не отрицаю наличия статической типизации в C++. Я писал только том, что наряду со статической типизацией там есть и динамическая типизаций, и код без типизации вообще.

Да. Но изначально я не видел никаких условий «только на маленьких проектах».

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

Принято.