https://www.opennet.me/openforum/vsluhforumID3/133380.html Доступен альфа выпуск языка программирования Python 3.13.0a6, который примечателен включением в состав ветки 3.13, на основе которой формируется осенний стабильный релиз Python 3.14, экспериментальной реализации JIT-компилятора, позволяющего добиться существенного повышения производительности. Для включения JIT в CPython добавлена сборочная опция "--enable-experimental-jit". Для работы JIT требуется установка LLVM в качестве дополнительной зависимости...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60966<br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#246 Tue, 30 Apr 2024 13:06:10 GMT &gt; Да, готовые библиотеки предоставляют определённый функционал, но чаще всего неоптимальны в плане производительности<br><br>доооо, расскажи это авторам numpy, scipy, pandas - ты в жизни не напишешь ничего даже близкого по уровню оптимизации и производительности, тем более на крестах (такие как ты не знают не их, ни других яп, но мнение имеют)<br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#244 Sun, 14 Apr 2024 23:32:38 GMT &gt; Вот ведь проблема, что за 40 (или уже 50?) лет программисты на <br>&gt; Си от всего перечисленного так и не излечились почему-то. И если <br>&gt; верить Гуглу с Микрософт ом (а зачем бы им врать), 70% <br>&gt; ошибок програми на Си - это некорректная работа с памятью. Именно <br>&gt; по этой причине и начали появляться языки с автоматическим управлением памятью. <br><br>Как всегда, есть дилемма... Указатели на память - это ведь фича Си, а не его недостаток. Это именно то, что приближает его к ассемблеру, позволяя писать на нём очень производительный код даже без привлечения ассемблера, хотя при необходимости в программу на Си/Си++ можно вставлять ассемблерные блоки (прямо блоки или отдельные ассемблерные инструкции, а не вызывать функции на ассемблере! правда не все компиляторы позволяют это делать, но тем не менее...). Языки более высокого уровня вводят абстракции для работы с памятью, что отчасти служит подушкой безопасности, но в то же время лишний контроль неизбежно снижает производительность. Например, в С/С++ мы можем изменит https://www.opennet.me/openforum/vsluhforumID3/133380.html#243 Sun, 14 Apr 2024 23:14:28 GMT Библиотеки в программе обычно делают лишь незначительную часть работы. Это лишь вспомогательный инструмент. Основной алгоритм пишется руками и обычно именно он определяет производительность. Даже между компиляторами С++ может быть большая разница в производительности генерируемого кода. Многое может зависеть от опций компиляции. У некоторых компиляторов С++ есть возможность делать ассемблерные вставки в коде С++. И в этом во всём огромный потенциал увеличения производительности. Да, готовые библиотеки предоставляют определённый функционал, но чаще всего неоптимальны в плане производительности. Короче, те, кто пишет на Питоне, даже не подозревают насколько код может быть быстрый.<br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#242 Sun, 14 Apr 2024 08:01:49 GMT &gt; написание комментариев<br><br>Комментарии сопровождать надо. Они теряют актуальность примерно так сразу. И вообще, во многих проектах комментарии запрещены.<br><br>&gt; аннотаций<br><br>Давай за место использования типизированных технологий попытаемся прикрутить типы к пайфону.<br><br>&gt; преждевременная оптимизация - корень всех зол. <br><br>Никто не говорил про преждевременную оптимизацию. Просто пишешь не на пайфоне и работает примерно в 50-100 раз быстрее. <br><br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#241 Sun, 14 Apr 2024 07:49:52 GMT &gt; намного более лаконичный язык, который к тому же проще читать и понимать<br><br>Это очередной миф. Лаконичность - это приятный бонус к читаемости, но не более.<br><br>Хорошо читаемый код - это:<br>- когда ты можешь понять зависимости любого отдельно взятого участка кода.<br>- когда ты можешь быстро понять, как поле ввода на экране соотносится с колонкой в базе данных. <br>- когда ты можешь безопасно переименовать свойство в классе, или изменить сигнатуру метода. <br>- когда ты можешь гарантировать, что кусок кода можно выкинуть, потому что он больше не используется.<br>- когда IDE наравне с человеком может читать код и предупреждать о потенциальных ошибках и рефакторингах.<br><br><br>И пайфон со своей динамической структурой тут очень плох.<br><br>Да, ты можешь быстрее стартануть проект на пайфоне и меньше ПЕЧАТАТЬ в первую неделю разработки. Но уже на второй месяц разработки ты получаешь doubtfull решение. Ты ни в чём не уверен и сидишь как бабка у корыта. <br><br>Всё это проходили уже много раз. <br>Всё это проходили уже много раз. <br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#240 Sun, 14 Apr 2024 07:17:03 GMT &gt; Затем, что речь идёт о прототипе. Пайтон в этом плане очень хорош по сравнению с тем же Си<br><br>Давай предположим, что между самой низкопроизводительной технологией (пэйфон) и самой быстрой (СИ) есть 2-3 промежуточных решения, на которых можно и прототипы писать быстро и работать будет хорошо?<br><br>Можешь мне, глупому, объяснить, зачем вообще нужен пэйфон?<br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#239 Sun, 14 Apr 2024 04:47:52 GMT &gt;И вот эти костыли с venv и ещё динамической работой pep когда он сам походу из инета подтягивает недостающие зависимости<br><br>Это что за бредятина? Где это pip работает динамически? И в чем конкретно проблемы с venv? <br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#238 Sun, 14 Apr 2024 04:45:37 GMT А давно у Питона зависимость стандартной библиотеки от Rust? Ты уж определись, чем ты там занимаешься, всё-таки.<br> https://www.opennet.me/openforum/vsluhforumID3/133380.html#237 Sun, 14 Apr 2024 04:41:25 GMT Есть проблема. Людям сейчас надо работу работать. <br>