ормальные языки с достаточно юзабельным type inference не так давно появились/стали популярными, поэтому большинство считают, что статическая типизация — это что-то вроде java со всеми вытекающими
Да, и я хочу подчеркнуть, что type inference уже частично есть и в жаве.
Вообще то это зависит от задачи. В некоторых задачах питон даже длиннее может оказаться, понятно что речь идет о неком среднем которое может плавать от области к области.
возможна ли сишка с автоматическим подсчётом ссылок
Но ведь она возможна, в чём троллинг будет? В том, что она не нужна в сишке, и такие вещи вызывают бугурт среди кодеров, ибо уже есть Objective-C, Swift, Rust и прочие вполне алекватные языки для замены Си при таких потребностях, как автоматическое управление памятью
Да Swift хорош. Но есть слухи, что Си побыстрее будет.
Пойми что такое скриптуха, узнаешь ответ на свой вопрос. Спойлер: да, но смысла около нуля
Lua имеет скорость выполнения, сравнимую с жавой/шарпом. Проблемы статической типизации и скорости выполнения являются специфичными именно для питона, даже васик от них не так сильно страдает.
Я не верю в чудеса. Динамическая типизация это накладные расходы в райнтайм, автоматическое распараллеливание априори будут сливать решениям которые в которых распараллеливание сделано руками с учетом специфики задачи
Жуля хоть и не делает чудеса, но все равно позволяет писать достаточно быстрый код без запарок, и, самое главное, без лютого гемора питоньих биндингов, которые представляют из себя «третий язык».
Это, в каком-то смысле, интересная задачка: взять кусок дерьма и попытаться сделать из него конфетку.
Академический интерес есть, не поспоришь. Но нужно ли это индустрии? Вернее быстро работающий интерпретируемый язык конечно нужен, но кто этот банкет оплатит?
Lua
А этот язык в продакшене есть? Честно говоря ничерта о нем не знаю
Ничерта подобного. luajit да (и то, я бы не сказал сравнимую, правильней будет сказать «сопоставимую», ибо заметно медленней, там нечего сравнивать), референсный интерпретатор нет, при этом PyPy тоже не сильно медленней. Дефолтный будет быстрее CPython ну раза в полтора отсилы, при том, что язык убогий и немощный в отличие от питона.
А что тут думать, писать надо! (старый анекдот). Учитывая как много уже готового библиотечного кода есть на С, возможно будет и не так уж и долго, если конечно использовать такой код, а не писать в сотый раз обертку на выделение памяти, нультерминированные строки, не сочинять свои реализации общеизвестных структур данных, не писать пулы и т.д. и т.п. Хотя с завидным постоянством это все в сотый раз пишут, взять любой проект на С и там обязательно будет авторский костыль на проблемы языка С.
Статическая типизация никак не помогает обнаруживать ошибки. Я на этих ошибках собаку съел. Статическая типизация нужна только тогда, когда нужно распространять бинарники под разные платформы клиентам.
Здесь есть много людей, которые собаку съели на языках со статической типизацией, так что это не аргумент. И я в том числе не вижу прямой связи кроссплатформенности со статической типизацией.
Это и есть статическая типизация, просто не так сильно ограничивающая разработчика как в старых ЯП. Я согласен с тем, что она настолько же удобна и при этом позволяет овить ошибки на этапе компиляции, в некотором смысле это идеал
Нет, это динамическая типизация по определению из википедии, поскольку тип аргумента/переменной не проверяется на этапе компиляции. О чем я и пытался сказать, когда писал про определения. Более того, JavaScript приобретает элементы статической типизации при JIT-компиляции.
Если не считать всякие попытки проверки типов которые в новые питоны вроде притащили и которыми я не знаю кто пользуется, то в питоне сплошь и рядом динамическая типизация
Еще раз советую опираться на конкретное определение. В питоне определнно есть динамическая типизация как проверка типа во время выполнения, но также в нем есть отсутствие проверки типа в виде утиной типизации.
Контраргумент: динамическая типизация замедляет разработку, потому что сразу обнаруживаемые ошибки при статической типизации ошибки приходится обнаруживать отладкой.
Бесспорно, но на маленьких проектах это замедление некритично
Да. Но изначально я не видел никаких условий «только на маленьких проектах».
Статическая типизация никак не помогает обнаруживать ошибки
в одноразовом коде. Зато позволяет менять код с заметно большей уверенностью что не сломается что-то совершенно в другой части приложения.
Ну и в 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 ну раза в полтора отсилы, при том, что язык убогий и немощный в отличие от питона
Можно спорить по поводу убогости либо неоправданной перегруженности и отсутствия целостности архитектуры.
Нет, это динамическая типизация по определению из википедии, поскольку тип аргумента/переменной не проверяется на этапе компиляции.
Вполне себе проверяется.
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")); // упадет при сборке
В питоне определнно есть динамическая типизация как проверка типа во время выполнения, но также в нем есть отсутствие проверки типа в виде утиной типизации.
раскройте пожалуйста чем одно отличается от другого.
Да. Но изначально я не видел никаких условий «только на маленьких проектах».
Да, питон будет короче, если в нем задача уже реализована в виде готового решения, и остается только дернуть функцию с параметром
Нет, притон вообще в среднем короче чем С/С++ для условно средней задачи. Для некоторых задач сильно короче. Для немногих задач С/С++ окажутся короче, главным образом если нужны какие то хитрые императивные циклы со сложной индексной арифметикой. На питон это ложится плохо, ну или приходится много думать.
У меня весь биндинг обычно занимает три строки (включая вообще всю сборку), дальше работает swig и давно написанный шаблонный Makefile. ЧЯНТД?
Так и есть, если нужно вызывать пару функций с примитивными аргументами. Если типов аргумента больше одного, если значения составные, то начинается веселая развлекуха.
Не, ну можно написать какую угодно дичь, даже на питоне. Но зачем? Если использование языка более высокого уровня, чем си, не помогает тебе писать более компактный код, с меньшим кол-вом бойлерплейт, то наверное для твоих задач больше подходит си. У меня например несколько иные задачи
Мне написали голословное утверждение «Си в 50 раз больше питона». Я ответил, что это голословное утверждение, и на питоне можно написать программу объемнее, чем на Си — это зависит от программиста, а не от языка. Если же программист просто пишет код и не выёживается, то соотношение объемов C/Python получается всего несколько раз.
Соотношение объемов не очень релевантно, нужно смотреть на скорость разработки. Условно считается (на основе моего опыта и опыта коллег) что разница по скорости разработки составляет порядок. Но это неточная цифра, и понятно что все очень сильно зависит от задачи (как я уже писал).
Нет, это динамическая типизация по определению из википедии, поскольку тип аргумента/переменной не проверяется на этапе компиляции
Вполне себе проверяется
В питоне определнно есть динамическая типизация как проверка типа во время выполнения, но также в нем есть отсутствие проверки типа в виде утиной типизации.
раскройте пожалуйста чем одно отличается от другого.
Пример из питона является статической типизацией, однако с таким же успехом в питоне существуют функции, которые не проверяют типы, и даже могут не выдавать ошибки. Потому я и писал про утиную типизацию.
И я не отрицаю наличия статической типизации в C++. Я писал только том, что наряду со статической типизацией там есть и динамическая типизаций, и код без типизации вообще.
Да. Но изначально я не видел никаких условий «только на маленьких проектах».