Доступен альфа выпуск языка программирования Python 3.13.0a6, который примечателен включением в состав ветки 3.13, на основе которой формируется осенний стабильный релиз Python 3.14, экспериментальной реализации JIT-компилятора, позволяющего добиться существенного повышения производительности. Для включения JIT в CPython добавлена сборочная опция "--enable-experimental-jit". Для работы JIT требуется установка LLVM в качестве дополнительной зависимости...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60966
Ну вот, то самое Счастливое Будущее уже наступило! Поздравляю всех товарищей питонистов!
> Ну вот, то самое Счастливое Будущее уже наступило! Поздравляю всех товарищей питонистов!Вот так плавно и постепенно, гадюка легким движением руки превратилась в элегантную... жабу!!!
ну не совсем. Собственно, чего удивительного - если аксолотля не п-дить раз в три дня палкой и воду ему нагреть в аквариуме до теплой - он отбрасывает свои чудесные веточки-жабры и пол-хвоста, и из аквариума вылазит мерзотная жырная ящерица, к тому же еще и ядовитая.Вот и получили.
саламандра :)
Один groovy у нас уже есть - да и тот уже нах не нужен
Ничего, вы его разгоняете, а он растягивается ;)
＼（＾∀＾）メ（＾∀＾）ノ
Ты про завязку на ллвм? Такое себе будущее.
странно что в питоне не было даже минимальных базовых нюансов
сколько же бабла ввалили на его продвижение...
Так это когда было, а сколько лет с тех пор прошло?
Спасибо что хоть что-то было!!
Да оспыдя. Большинство из тех, кому прямнадо было - брали кто pypy, кто pyston, а кто и вовсе (Ха-ха, неудачники!) nuitka'у - делов-то? Иное дело, что "прямнадо" оно не только лишь всем да и результат был не то, чтобы однозначно очень...
JIT - зло которое надо искоренять!
Насколько я помню, просто так JIT не бывает, и за его использование приходится платить небольшим оверхедом по процессору (счётчики вставлять), но и заметным оверхедом по памяти.Если питн продолжит развиваться в том направлении, то станет явой, и я не уверен, что это так уж и хорошо.
Вы бы лучше посчитали оверхед у JS, то не так сильно удивлялись бы.
Зачем мне JS? Я его ненавижу даже сильнее чем Python!
Чтобы ненавидеть
А что Вам по душе?
> Насколько я помню, просто так JIT не бывает, и за его использование приходится
> платить небольшим оверхедом по процессору (счётчики вставлять), но и заметным
> оверхедом по памяти.Во первых генерить оптимальный код - нифига не lightweight операция. И одно дело если это билдферма отпедалила, и другое - если лично вы. Во вторых RAM и CPU на это вполне себе уходит - и ява, или накрайняк, яваскрипт - таки получаются, да.
Имела жаба гадюку - а теперь, вот, вывелось нечто земноводное непонятного типа :)
Да, Python движется в сторону становления Java-подобным языком. Возможно, и vm будет единой.
>>код работает на 50% быстрее.То есть код будет тормознее не в 200 раз, а всего лишь в 133 раза
200 - 100%
133 - X%я в 3 классе, но мне кажется, что X точно не 50%
Достаточно, что оно в 65000 раз медленнее, чем С.
норм, еще 535 раз в запасе
Если не уметь писать, то и С медленнее, чем С
Ты так мудр, будь моим сенсеем. Я преисполнился в твоей философии
Я как-то раз ускорил побайтовый перебор текста (и собственно исполнение наиболее тормозной части) в 10050 раз добавив register к переменной-счётчику, компилятор до этого догадывался только с PGO. Уметь писать мало, надо быть умнее компилятора, и это уже доступно не каждому. После встраивания этого кода в код на питоне, исполнение было всё ещё быстрее и эффективнее, чем просто на си.
>быть умнее компиляторак примеру, компилятор имеет право игнорировать register, и тут придётся его натягивать.
Писал перебор текста на ассемблере, это было быстро. И оперу совсем не ел лишнего.
Так, если ты в ассемблере не клал в оперу ничего, то там и нет.
А системные вызовы потребляют оперу системы, а не процесса.
Ну ок, плохо что таблица сисколов разная для 64 битных и 32 битных систем это капец.
Дело не только в этом. Джит может подхватить текущую архитектуру цпу со всеми бонусными фишками типа последних SIMD и ещё бг знае чего. Что ему как правило не помогает, но учтите!!
Как бы Вы хорошо не писали на Си, догадываетесь же, что есть области и где Си неуместен.
И точно так же, Питоны и Jit'ы применимы не везде.Но у Питона, в виде тормозного скрипта, есть существенный плюс, когда в ПО легко изменить скриптовые части.
А если ПО тяжелое, и компиляция крайне желательна, так для этого есть и более эффективные языки.
Походу, задачку про сушёные грибы ты во втором классе прогулял.
То есть каждый раз компилировать и выполнять инструкции быстрее, чем интерпретировать? Хм...
Зачем каждый раз? Один раз функцию скомпилировал и исполняй её хоть 100 000 раз.
Но код питона динамический, eval() там, все дела. Заново компилировать.
> То есть каждый раз компилировать и выполнять инструкции быстрее, чем интерпретировать? Хм...А ты не догадываешься, что код может выполняться в цикле?
Что делать те у кого нет циклов? Может например использовать нормальный язык? Например го.
Отвечаю для всех кто не знает как работает JIT. Обычно компилируется не весь код, а код который вызывался много раз и который будет выгоднее сначала скомплировать, а потом быстро исполнять.
JIT в среднем работает быстрее интерпретатора, иногда можно ускорить еще принудительно отключая JIT для некоторых функций.
Дубль два. Зачем тебе интерпретатор если ты куда-то торопишься? Может сразу брать нормальны
й быстрый язык. Например го.
Да не вопрос. Одна проблема, то что на питоне реализуется 10-ю строками кода, на go не умещается в 30.
Бывает и наоборот
Обычно так говорят "разработчики", которые выучили один только пэйфон.Код на нём занимает ровно столько, сколько на любом современном языке программирования.
Так что не надо врать тут
Gо, нормальный язык? /0
Да - нормальный. +100500*100500 :-р
А то что у неГо есть свои закидоны ... а у кого их нет? Но струнимент - рабочий.
На нем к примеру софта написано неслабо, которым _уже_ миллионы мух пользуются :)
... в отличие от к примеру раста, который почти ровесник, а софта нетЪ, акромя парочки утилит импортозамещающих такое-же, но на С\С++ :)))
PS: Из питона делают js ... ну такое ... один js у нас уже есть, и "там своя атмосфЭра"(С)
> в отличие от к примеру раста, который почти ровесник, а софта нетЪ"Фантазё-о-о-о-ор, ты меня называла-а-а-а-а"
Спроси хотя бы у гугла (компании, а не поисковика), в чем ты неправ насчёт раста.
Как тебе там, в твоём отсталом маня-мирке, живётся?
Ну зачем вы прикалываетесь над вьюношей? Мальчик долго изучал Go, и теперь не знает что будет, если Go не будет. Он просто боится и свои страхи транслирует здесь в хвалебных речах для Go - языка корпорации Google, собирающей ваши личные данные, письма, запросы... пусть даже, если это они делают в последнее время на Rust.
Вряд ли он долго изучал Go. Он создавался лёгким для изучения. И с начала хайпа по нему очень быстро появилось много программ, что говорит о лёгкости изучения.
Ну вон, растдеск хорошо скаммеры используют
Можно даже сказать единственный нормальный. Там нет таких закидонов как сабж из новости.
Он не просто нормальный, он практически идеальный. Я когда залезаю в гирлянды async await в JS и Питоне, мне после этого в душ хочется сходить.
Спасибо Робу Пайку за горутины и каналы!
Гирлянды и async await? Вы точно про js?
Если изучить один раз, то ничего сложного. Видишь async def? Это сопрограмма. Видишь await? Это вызывают сопрограмму. А в каком-нибудь __main__ все сопрограммы помещаются в задания и вызывается asyncio.run.
Ты вообще видел Го? Там к корням UNIX и Plan 9 возвращена функциональность конкурентности и горутины общаются между собой каналами, а не вот этим вот плохой вещью.
https://habr.com/ru/articles/466337/
Если ты считаешь, идеологию конкурентности в JS и Питоне - ок, то рекомендую немного поделать вещей на Го, и ты поймешь, насколько это тупая вещь.
Сопрограммы вообще нетипичная вещь. Обычные подпрограммы с возможностью по желанию левой пятки сохранять переменные, стек и регистры куда-то, а потом также возвращать обратно. Поэтому жди 100500 реализация сопрограмм, как со строками вышло. И в питоне async/await - это просто синтаксис, за которым может быть любая реализация, в том числе гошная.
go - куцый кастрат, работающий медленнее C#если принципиально нужно страдать, то хотя бы за что-то существенное - Rust
> если принципиально нужно страдать, то хотя бы за что-то существенное - Rustа где здесь "существенное"?
Админы, напишите про PEP 730 (https://peps.python.org/pep-0730/) и PEP 738 (https://peps.python.org/pep-0738/), довольно таки интересная тема.
>позволяющего добиться существенного повышения производительностипруф или не было, на типичных применениях jit это жор памяти, процессора, и тормоза, к чему эти фантазии в тексте?
Точна! Его господа наши придумали всем на погибель!
> на типичных применениях jit это жор памяти, процессора, и тормозаНу так сообщи об этом разработчикам CPython. Ты же видишь: они там все идиоты, без тебя ничего не понимают.
А то они не в курсе. У майкрософта не типичные применения для питона.
У них много ресурсов есть что жрать.
Им надо чтоб твой инстанс в Azure крутящий твою крстылемещалку-на-пеЙтоне жрал х10 :)
Но если подкрутить только у себя - все уйдут в AWS\GCP ... но это же луДший друг опенсорца, поэтому подкрутят ВСЕМ, чтоб ВСЕМ стало луДше! :-D
посмотри сравнения скорости бидона с PHP или Ruby, где JIT применяется уже очень давно
Jit наиболее хорошо для сервера подходит, где процесс запускается один раз а потом неделю пашет.Но кто в здравом рассудке будет на пайфоне сервер писать?
>Для работы JIT требуется установка LLVM в качестве дополнительной зависимости.Ясно, понятно, обойдусь без такого JIT. Если нужно будет ускорить, тогда уж лчше Анютка.
llvm зачастую и так есть в системе. Например, его mesa тянет за собой.
У меня нет.
На локалхосте может и так, а на серверах llvm обычно нет
>Для сборки CPython с JIT требуется установка LLVM в качестве дополнительной зависимости.шо не ясно? просто новый питон без LLVM не установится.
так и появится LLVM на сервере.
Так это девелоп машина. На девайсе ни месона ничего
> llvm зачастую и так есть в системе. Например, его mesa тянет за собой.Он ща весит более 60 метров. Это уже скоро начнет реально, жабу, догонять.
Мхва-ха-ха! Вот так вы, "ускорятели", и палитесь...
Разве его там раньше не было? Очень странно. Как же он стал таким популярным без JIT?
Были сторонние JIT, тот же PyPy.
потому что jit нужен большим долго работающим программам, пистон имно вообще не про это. питон это современный кроссплатформенный бейсик, в этом виде он очень не плох, зачем из него делать java понять сложно.
JIT нужен всем, кто заботится о производительности и отзывчивости. К тому же JIT уже давно научили сохранять результат своей работы, что делает его актуальным не только для больших и долго работающих программ.
Фраза греть кеши заиграла новыми красками.
> JIT нужен всем, кто заботится о ... отзывчивости.Вот им как раз JIT не нужен, JIT даёт только доплнительные задержки и ухудшает ~ 99 % -ый персентиль. Хорошая особенность CPython это равномерные и предсказуемые тормоза. Для отзывчивости можно использовать только ЯП без JIT и без GC.
> JIT нужен всем, кто заботится о производительности и отзывчивости. К тому же
> JIT уже давно научили сохранять результат своей работы, что делает его
> актуальным не только для больших и долго работающих программ.Хлупость. От jit производительность могут получить только большие и долгоработающие приложения, остальные её не получат, да и бейсику не нужна производительность, а нужна понятность и быстроекодонаписание, а отзывчивость вообще не про jit ни в каком виде.
Есть мнение, что jit это какая-то манта. Мало кто понимает, что это и как работает, но все уверены, что она решает все проблемы.
Потому что питон второй лучший язык для всего.
Удобный ЯП для нетребовательной автоматизации, нормальная замена bash портянкам. И хорошая стандартная библиотека. Так и взлетел
Вообще изначально он предназначался для прототипирования, типа - пришли к клиенту, пообщались, выяснили требования, что-то по-быстрому набросали на Python, показали клиенту, клиент доволен, переписали полностью на С++ или только критические участки.А потом производительность процессоров так рванула, что мелко-средних клиентов удовлетворял и тормознутый Python, который оказался тормознутее даже полностью интерпретируемого VBScript, не говоря уже о VBA с его p-кодои или cкомпилированном в нейтив Visual Basic.
И я просто был в шоке, когда это "чудо" начало захватывать ИТ-область с его повадками и неправильными парадигмами написания каких-хочешь программ левым пальцем недоучившегося студентоса.
вообще то ученые проталкивали, удобно данные экспериментов обрабатывать не изучая ассемблеры, кстати именно по этому в питоне мат. библиотеки такие развитые и вылизанные. Так же как и WWW от них.
> Вообще изначально он предназначался для прототипирования...Нет. В наше же время все могут воспользрваться хотя бы википедией и посмотрпеть как было на самом деле. Зачем выдумываешь? Ладно, чукча, видимо, не читатель, давай помогу...
> We needed a better way to do system administration than by writing either C programs or Bourne shell scripts, since Amoeba had its own system call interface which wasn’t easily accessible from the Bourne shell. My experience with error handling in Amoeba made me acutely aware of the importance of exceptions as a programming language feature.
Придумать они его могли по любому поводу, типа чтобы за пивом коллегам не бегать. Суть не в этом. А суть в том, что когда они начали продвигать это поделие в массы, то лозунг Гвидо и его подельников был "Python - язык для быстрого прототипирования", пока ваши конкуренты пишут на С++ вы уже показываете клиенту свою программу. Best Time to Market. Как-то так.
И суть его осталась ровно такой же ибо для прототипирования абсолютно не подходит. На любом другом ЯП разработку нужно начинать полностью с нуля, наработки на питоне нельзя больше никуда перенести.
... но приводить подтверждения своим словам я конечно же не буду.
Он стал популярным как язык-клей, писать код где не упираемся в проц (когда вы ждете чего-то из сети или читаете с диска, нет разницы, есть jit или нет). А где упираемся - этот кусок переписывается на C или берется из готовых библиотек с нативным кодом.Т.к. питон не джава и не C#, там нет виртуальной машины / сэндбокса / причин использовать managed-реализацию вместо нативной. Приличная часть стандартной библиотеки написана нативным кодом. И реальные программы используют кучу библиотек написанных на C - везде, где критична производительность. А перекидывать данные между C'шными реализациями и писать высокоуровневую логику он и без JIT прекрасно справляется.
5-7 лет назад инфоцыгане резко открывать курсы по пайфону "стань программистом за две недели".Люди ломанулись туда и всё начало реверберировать. По сути пэйфон популярен потому что популярен.
Кто не согласен - пожалуйста поясните, какие у пэйфона конкурентные приемущества?
Ты, видимо, всё-таки Пайтон имел ввиду, говоря "пэйфон". Популярен он потому, что прост в обучении, прост в сопровождении, и его библиотека стандартная довольно-таки богата на функциональность, что позволяет очень быстро писать код в разных областях, при условии, что высокая производительность конечного продукта не нужна, а она таки не нужна примерно в 70-80 процентах от общего числа программ (где-то видел диаграмму такую).
Большое количество курсов в случае Пайтона - это уже производная от факторов, перечисленных выше.
Самое интересное как приняли изменение: без pep, что без обсуждений в рассылках, просто чел из мс пришёл, сделал пр и его приняли. Не зря мс взяли Гвидо на работу, не зря!Жду подключены к работе Андреаса Хелсберга.
PEP это изменения в ЯП, а в новости опционально добавляется новый режим работы реализации без изменений в самом ЯП и его инфраструктуре.
Не надо оправданий, все все понимают. Кстати, про pep даже релиз инженер из гугла возмутился в pr. Им явно виднее ю, чем тебе.Ну и есть два новых Пепа про поддержку мобилок, так что ты не прав.
А подскажите плз, знающие, .pyc файлы - это что ? Не тоже ли самое ?
Это байт-код, ускоряющий частую загрузку, не то.
спасибо!
Это байткод он только чтобы каждый раз не парсить текст.
О, ну так если теперь пихтон компилится в нативный код, может и ai стаф не будет требовать суперкомпьютер для работы?)
AI будет в Mojo
Mojet и будет, а может и нет. А то Юлия уже обещала Петон из науки изгнать.
Не будет. Он и так на с/с++ написан. На Python лишь биндинги.
Когда уберут табы?
+, было бы киллер фичей наконец таки сделать диалект питона на { }
Не, это уже будет НеПитон.
Играйтесь в скобочки в я языках со скобочками. Их более чем достаточно.
Ага, а то ещё желающие begin/end прибегут.
https://pypi.org/project/Bython/
> +, было бы киллер фичей наконец таки сделать диалект питона на { }Открой для себя go :). Для кого гугол старался, спрашивается?!
Для себя, вестимо. И за вычетом достаточно узкой ниши - примерно "не конкурент".
Свой JIT не могли написать что ли? Теперь всем эту монструозную либу компилять каждый раз по миллиарду часов при сборке (сейчвс пока необязательна, но в будущем будет).
Хи-хи ха-ха, делов-то
Можно подсмотреть в PyPi и даже что-то скопипастить.
Не знаком, но предвижу
Вот что Mojo животворящий делает! Как только появился единый перспективный язык программирования способный заменить Python и Rust, засидевшиеся разработчики сразу зашевелились и начали вводить новые фичи, фиксить уязвимости.
Тырят друг у друга идеи. Это Open Source животворящий.
В научных вычислений сейчас лучшая связка Julia + Rust
Научные вычисления приговорены к вечному страданию на мусорных ЯП. Это про Julia, если что. Показательно, что среди всей этой кодлы не находится достаточное кол-во вменяемых людей для разработки нормального ЯП
а всё почему - там недостаточно денег и корпораций, на потсоянной основе. разовые гранты не способствуют созданию/исправлению языков
Перцы, которые пилят Julia изначально пилили какую-то версию Lisp. Потом они решили, что надо сверху накидать процедурно-обектного синтаксиса, обозвать это Julia и продать. Получилось не очень. Фортран как-то целостнее смотрится и логичнее (но конечно более ограничен своими границами, заложенными еще ранее - в основном вектора и матрицы, остальное много труднее, хотя и легкий ООП туда завезли)
Вменяемых языков бесконечное количество на самом деле. Просто у научных работников как правило нету понимания, какой инструмент выбрать. Они же не программисты.Возьмите хоть тот же f#. Строго типизированный, притом не требует указания типов, конпелируется в АОТ. синтаксис крайне лаконичный. По идее он должен быть на месте пэйфона сейчас. Но, увы, микрософт допилили дотнет только недавно, а ниша уже занята
Не знаю, вроде все любят питона, а я не особо.. Какой-то он то тут то там, вечно проблемы какие-то.
Любят, потому что на питоне быстро делается рабочая программа. И выполняет любые задачи. А скорость и безопасность можно и потом допилить уже, если задача того стоит.
>Любят, потому что на питоне быстро делается рабочая программа.Быстро - да, рабочая - "это вам повезло"(С)Профессор анатомии
>И выполняет любые задачи.Выкладывай свой девайс драйвер для ведра :) Обосрамс?
>А скорость и безопасность можно и потом допилить уже, если задача того стоит.Перевожу с айтишного на русский:
А скорость и безопасность идут лесом, у меня в жЫре ещё 20 тасок весит, а вертухаям привесли новенькие ногайки! :(
Впрочем - перебор. Такая бнопня будет хоть на чём пиши :)
>>Любят, потому что на питоне быстро делается рабочая программа.
> Быстро - да, рабочая - "это вам повезло"(С)Профессор анатомииЭто явно профессор кислых щей писал /_-
На питоне рабочая программа получится в разы чаще чем на дыряшке.> Выкладывай свой девайс драйвер для ведра :) Обосрамс?
Тут люди пишут дрова для видях на питоне, а ты куракекаешь что-то невнятное.
На почитай для чего нужно быстрое прототипирование и отладка, может умнее станешь (но это не точно)
asahilinux.org/2022/11/tales-of-the-m1-gpu/>>А скорость и безопасность можно и потом допилить уже, если задача того стоит.
> Перевожу с айтишного на русский:Я тебе пример выше скинул, как на питоне пишется код, а потом переписывается на быстрый и безопастный раст.
> А скорость и безопасность идут лесом, у меня в жЫре ещё 20 тасок весит, а вертухаям привесли новенькие ногайки! :(
Если тебе бьют, то наверное ты просто трепила. Ну или с генами что-то не то.
Тебя там за просроченные спринты на стеклотару не сажают?
Может тебе хотя бы почитать, как в нормальных коллективах работают?
Ты что в бюджетных организациях никогда не работал?
> Выкладывай свой девайс драйвер для ведратак там эти... армотрахатели почти ж выложили (в смысле у них на самом деле был и работал прототип на впихоне - к счастью для нас, все же они использовали язык быстрого прототяпляпирования по назначению и потом пошли все переписывать на хруст, с чем и пропали)
> с чем и пропалиВ смысле пропали?
Они как раз его закончили и даже прошли сертификацию Кроноса.
Это тебе не хухры-мухры.
"И вот все об этом человеке".Ачивка анлокнута, можно продаваться подорого какому-нибудь ibm.
> "И вот все об этом человеке".
> Ачивка анлокнута, можно продаваться подорого какому-нибудь ibm.Зачем IBM спец по эпловским GPU? Что они будут с ним и его макетами на питоне делать? Да даже и на хрусте - повод дать этому туловищу денег в чем состоит?!
Этот Кронос сертифицирует всё что шевелится. Что не шевелится он толкает и сертифицирует.
А потом просто включается правило: работает - не трогай!
Устраивает - не трогай.
Проблема в том что если ты не поторопился с установкой новехонького дистра, потому что у тебя уже на этом всё настроено, свежие прожки начинают отваливаться, пип не фурычит при попытке достать очередную либу, компиляешь свежего питона чтобы просто запустеть этот самый скрипт, танцуешь с папками и путями, потом там что-то ещё и так далее.
У коллеги арч и он вообще давно забил на попытки пользования скриптой, в общем вакханалия.
Я это без ненависте, чисто статистически, много такого на питони встречалл
Господи, что за ранние 200е? Вроде ж у всех лет десять как - у кого по venv с каким poetry ыщщо, у кого по контейнерам все - но обязательно найдется "знакомый арчевод"(ТМ), у которого три версии сконпелированного питона (Одна из них не иначе как 2я) ниработаит!
Рекомендую pipenv. Он в отличии от Poetry не мусорит в pyproject.toml, а создаёт свои Pipenv и Pipenv.lock, которые ни с чем не конфликтуют.
Да, компилируешь питон. И что такого? Питон очень просто компилируется.
Вот вы насоветовали тут, а как насчёт чтобы и так работало?
Мне нада скрипт запустить чтобы доки сгенерил, и забыть, а там начинается докеры, поетри, пайэнвы,
Щас ещё такая тема новая, что через пакетны менеджер не поставишь, говорит ставь через пип а пип не может, и так далее. А там ещё нада из месона запустеть, это ещё история..Такой вот жанр питоненья.
Разраб может и кайфанул, хотя не факт, но я так эту хрень и не осилил, после нескольких часов юзер забил и пошёл спать, ну и хрен с ними, да?
Вот poetry и pyenv не советую. Первый лезет ручонками в pyproject.toml. А я хочу собирать пакет через hatch. Второй просто устарел.Можно и без виртуальных окружений совсем. Тогда просто в одну папки кидаются все зависимости. Но никто зависимости вместе с программой не таскает.
Когда я только сел за линукс, тогда ещё пакетов толком не было. А в игрушки поиграть и разные программки хотелось. Приходилось качать исходники, configure и потом качать всё, что не нашёл configure. Где-то через полчаса лишь заветный make. Обычно собиралось без ошибок, потому что ошибки я точно не пытался исправлять.
Звучит приемлемо. Я так гном-шелл как-то собрал во времена автотулза, было забавно. А теперь вот месон билд и готово. И работала.
> А скорость и безопасность можно и потом допилить уже, если задача того стоит.Строители "замков на песке" характеризуются уверенностью, что фундамент и коммуникации подводятся после сдачи сооружения в эксплуатацию.
Ты когда-нибудь про прототипирование слышал? Или ты все свои идеи сразу в граните выбиваешь?
> Ты когда-нибудь про прототипирование слышал? Или ты все свои идеи сразу в
> граните выбиваешь?прототипирование это миф. программы написанные на недоязычках в этом стиле так и не вылезают из прототипа, только носят уже гордое название "program" с "version=01.02.24". Другое дело когда ты "прототипируешь" на каком-нибудь clisp'e, где код рефакторится потом до неузнаваемости, включая ассемблерные вставки, или ядро/либу на C/C++ и обвязываешь скриптами. Требуется продумывание архитектуры и интерфейсов/апи на стадии проектирования, что немного вылезает из практики "прототипирования" в 90% случаев. Примерно в стольких же процентах случаев, пихон-прожекты либо сдохли так и не переведя с 2 на 3 версию, либо перевели но так и остались на пихоне. Даже на го переписали единицы, т.к. требуют от зрелого гнокода немало количества бабла для переписывания.
> Давайте сменим традиционный подход к построению программ: будем считать, что наша цель — не дать указания компьютеру о ходе его работы, а объяснить человеку, что именно мы хотим добиться от компьютера.(c) Дональд Кнут
>> Давайте сменим традиционный подход к построению программ: будем считать, что наша цель — не дать указания компьютеру о ходе его работы, а объяснить человеку, что именно мы хотим добиться от компьютера.
> (c) Дональд Кнутне прикрывайся Кнутом.
Скриптота - problem oriented approach, решает проблему быстрого тяп-ляп, ака "прототипирования". Как только оно вылезает в паблик и тестируется/запускается на миллионах машин - имеем боль, страдания, тормоза, стэктрейсы, сломанные модули, переписывания с 1.х на 2.х, с 2.х на 3.х, а то и между иксами переписываем, типа 2.4 < 2.6 < 2.8 и так далее, типичные такие проблемы. "Прототипирование" не вылезает из прототипа, вот я о чём, потому что сама скриптота создана для "прототипирования". Представь как ты придумываешь архитектуру, пишешь ядро, выносишь коммон-код в либы, думаешь об апи, и всё на "прототипированном" языке: это нонсенс в 90% случаев. Чаще всего, ты как все мы: херачишь, чтоб работало (с), а далее - если решает бизнес задачу и есть отдача - можно вылизать стрёмные места, или переоформить код, сделав по подобию чего-нибудь архитектурного... разбить на модули, утилиты, сделать 2.0, сломав совместимость, а там, посмотрим, докупить железа если слишком тормозит, бо дешевле переписывания, или на краааааайний случай, который случится примерно никогда - переписать на Го. :-D
угу именно так, по факту вечная мечта о том чтобы программировать нечто абстрактное а потом придет какой то волшебник и оптимизирует под конкретное физическое железо так и не взлетела. Просто люди получили много раз обратный эффект, смирились и делают вид что так и должно быть. Что в программе всегда есть ошибка, что оптимизатор оптимизирует, что вечное сияние чистого разума это первично а то как сделать из песка микросхему это для неудачников. Так и варятся в каком то абстрактном болоте.
> Ты когда-нибудь про прототипирование слышал? Или ты все свои идеи сразу в
> граните выбиваешь?Да. Слышал.
И даже видел прототипы в граните и мраморе:
http://stranymira.com/uploads/posts/2008-09/1221408037_2_lar...
Москва не сразу строилась.
> быстро делается рабочая программасправедливо для любого популярного языка
Вот только в случае пэйфона, сопровождение после второй недели разработки становится адом в динамике
>становится адом в динамикеНе становится, если правильно всё изначально делать (написание комментариев, аннотаций) и высокая скорость не нужна.
Другое дело, если начинают вылазить бока с низкой производительностью, о которой мало кто думает изначально, потому что преждевременная оптимизация - корень всех зол. Вот тогда уже начинаются пляски с бубном, потому что код на Пайтоне не особо хорошо поддаётся ускорению.
> написание комментариевКомментарии сопровождать надо. Они теряют актуальность примерно так сразу. И вообще, во многих проектах комментарии запрещены.
> аннотаций
Давай за место использования типизированных технологий попытаемся прикрутить типы к пайфону.
> преждевременная оптимизация - корень всех зол.
Никто не говорил про преждевременную оптимизацию. Просто пишешь не на пайфоне и работает примерно в 50-100 раз быстрее.
tl;drВо сколько раз медленнее С++?
> Во сколько раз медленнее С++?CPython по тестам в сотни раз медленнее C++. Другие варианты Python, более оптимизированные - PyPy, например, - в десятки раз медленнее C++. И кто-то ведь использует его для обработки данных, и даже книги издаются на эту тему... Полная жесть, короче...
Так это все равно быстрее чем на си. Написание программы на питоне плюс ожидание ее выполнения суммарно меньше, чем написание программы на си.
Это зависит от того, что программа должна делать. Большинство задач, которые в ML решают, на C пишутся не сложнее. Просто у C синтаксис поприятнее будет.
"Hello, World!", да, на C пишется быстрее. Синтаксис поприятнее, да. Только этого синтаксиса не хватает, поэтому вспоминают, что есть C++.
Если запустить 1 раз с 1кб данных, то да. А если запускать миллионы раз с террабайтами данных, тут С/C++ вне конкуренции. Ну ты меня, надеюсь, понял.
Миллионы раз запускать, это уже не прототипирование. Здесь стоит переписать с Питона, если десятки раз удачно отработало.
> Здесь стоит переписать с ПитонаА зачем тогда вообще начинать писать на пэйфоне?
Затем, что речь идёт о прототипе. Пайтон в этом плане очень хорош по сравнению с тем же Си - намного более лаконичный язык, который к тому же проще читать и понимать (при условии, что код аннотациями типов снабжён).
> Затем, что речь идёт о прототипе. Пайтон в этом плане очень хорош по сравнению с тем же СиДавай предположим, что между самой низкопроизводительной технологией (пэйфон) и самой быстрой (СИ) есть 2-3 промежуточных решения, на которых можно и прототипы писать быстро и работать будет хорошо?
Можешь мне, глупому, объяснить, зачем вообще нужен пэйфон?
> намного более лаконичный язык, который к тому же проще читать и пониматьЭто очередной миф. Лаконичность - это приятный бонус к читаемости, но не более.
Хорошо читаемый код - это:
- когда ты можешь понять зависимости любого отдельно взятого участка кода.
- когда ты можешь быстро понять, как поле ввода на экране соотносится с колонкой в базе данных.
- когда ты можешь безопасно переименовать свойство в классе, или изменить сигнатуру метода.
- когда ты можешь гарантировать, что кусок кода можно выкинуть, потому что он больше не используется.
- когда IDE наравне с человеком может читать код и предупреждать о потенциальных ошибках и рефакторингах.
И пайфон со своей динамической структурой тут очень плох.Да, ты можешь быстрее стартануть проект на пайфоне и меньше ПЕЧАТАТЬ в первую неделю разработки. Но уже на второй месяц разработки ты получаешь doubtfull решение. Ты ни в чём не уверен и сидишь как бабка у корыта.
Всё это проходили уже много раз.
Всё это проходили уже много раз.
> И кто-то ведь использует его для обработки данных, и даже книги издаются на эту тему... Полная жесть, короче...Ты бы глянул на чем питонячие библиотеки для данных написаны под копотом для начала.
Для обработки данных на С++ чаще всего вообще никакие библиотеки не нужны. А вот в питоне без сишных либ вообще никакая обработка больших данных невозможна из-за его сверхнизкой производительности. И даже с сишными библиотеками он всё-равно очень медленный.
С библиотеками его медлительность уже не заметна, потому что в оставшихся местах (не покрываемых библиотекой) часто не нужна.
Библиотеки в программе обычно делают лишь незначительную часть работы. Это лишь вспомогательный инструмент. Основной алгоритм пишется руками и обычно именно он определяет производительность. Даже между компиляторами С++ может быть большая разница в производительности генерируемого кода. Многое может зависеть от опций компиляции. У некоторых компиляторов С++ есть возможность делать ассемблерные вставки в коде С++. И в этом во всём огромный потенциал увеличения производительности. Да, готовые библиотеки предоставляют определённый функционал, но чаще всего неоптимальны в плане производительности. Короче, те, кто пишет на Питоне, даже не подозревают насколько код может быть быстрый.
> Да, готовые библиотеки предоставляют определённый функционал, но чаще всего неоптимальны в плане производительностидоооо, расскажи это авторам numpy, scipy, pandas - ты в жизни не напишешь ничего даже близкого по уровню оптимизации и производительности, тем более на крестах (такие как ты не знают не их, ни других яп, но мнение имеют)
Приходите обсудить этот вопрос когда перестанете null освобождать, т.е. никогда
Ну что за чушь! От криворукости, рукожопости и слабоумия никакой язык не спасает!
Вот ведь проблема, что за 40 (или уже 50?) лет программисты на Си от всего перечисленного так и не излечились почему-то. И если верить Гуглу с Микрософт ом (а зачем бы им врать), 70% ошибок програми на Си - это некорректная работа с памятью. Именно по этой причине и начали появляться языки с автоматическим управлением памятью.
А так - да, от всех ошибок дёшево не отделаешься с любым языком.
> Вот ведь проблема, что за 40 (или уже 50?) лет программисты на
> Си от всего перечисленного так и не излечились почему-то. И если
> верить Гуглу с Микрософт ом (а зачем бы им врать), 70%
> ошибок програми на Си - это некорректная работа с памятью. Именно
> по этой причине и начали появляться языки с автоматическим управлением памятью.Как всегда, есть дилемма... Указатели на память - это ведь фича Си, а не его недостаток. Это именно то, что приближает его к ассемблеру, позволяя писать на нём очень производительный код даже без привлечения ассемблера, хотя при необходимости в программу на Си/Си++ можно вставлять ассемблерные блоки (прямо блоки или отдельные ассемблерные инструкции, а не вызывать функции на ассемблере! правда не все компиляторы позволяют это делать, но тем не менее...). Языки более высокого уровня вводят абстракции для работы с памятью, что отчасти служит подушкой безопасности, но в то же время лишний контроль неизбежно снижает производительность. Например, в С/С++ мы можем изменить какие-то данные, потом вставить ассемблерную команду, которая изменит эти данные, потом на С/С++ ещё как-то изменить эти данные и т.д. и всё это будет практически бесплатно без каких-либо значимых накладных расходов. Я не знаю другого языка, где подобные трюки были бы возможны. Поэтому да, на С++ и особенно на С нужно быть внимательным и чётко понимать, что делаешь, и лучше понимать, как работает процессор, память и компьютер в целом, т.е. нужна определённая квалификация. Зато, если всё грамотно делать, можно получить очень хорошую производительность достаточно простыми средствами - там, где программам на Питоне нужны дата-центры, взаимосвязь между многими компьютерами и т.п., программе на С/С++ может быть достаточно одного компьютера, и часто даже многопоточные программы не особенно актуальны, т.к. для решения задачи за приемлемое время хватает одного ядра процессора. Неоднократно на собственном опыте с подобным сталкивался. Так что на С/С++ какие-то вещи, возможно, немного сложнее, а какие-то проще и главное - намного проще получить хорошую производительность, причём простыми средствами. Такие вот дела...
man 3 free: ... If ptr is NULL, no operation is performed.Смысла в этом не много, но и проблемы нет.
Ни null а none
Лучше дождаться когда modjo дорастет до момента, когда он перекроет весь синтаксис питона.
Есть проблема. Людям сейчас надо работу работать.
Лучше бы архитектора толкового и с яйцами наняли, а то питон мотает в разные стороны, особенно в его библиотеках/расширениях.Втащили rust как зависимость некоторых базовых либ типа криптовой и оно и так то требовало возни для сборки, а теперь ещё и не на всех платформах это юзать можно будет.
И вот эти костыли с venv и ещё динамической работой pep когда он сам походу из инета подтягивает недостающие зависимости - это же треш и угар в плане поддержки и секурности.
Лучше не надо нового архитектора. А то, вероятнее всего, попадётся может и толковый, но бывший с яйцами. ;)
pip... Основная проблема всего этого колхоза это поставка so-ек вунтри pip и у каждого пакета свои одинаковые либы в разных версиях или даже совсем одинаковые. Здесь должен был бы быть нормальный пакетный менеджер, а не такое рукозадние
Это на каких платформах нелья? Просто интересно чем вы там упариваетесь?
А давно RUST стал работать на всех платформах где есть питон?
А давно у Питона зависимость стандартной библиотеки от Rust? Ты уж определись, чем ты там занимаешься, всё-таки.
>И вот эти костыли с venv и ещё динамической работой pep когда он сам походу из инета подтягивает недостающие зависимостиЭто что за бредятина? Где это pip работает динамически? И в чем конкретно проблемы с venv?
Вот радуете меня когда за нас, DS-тов, все подряд решают в чем нам надо работать, причем "еще 10-ть лет назад", когда ИИ было словом ругательным. Тыкают в "сотни раз более медленный" по несколько раз на дню.Прошу запомнить число "4" - примерно во столько раз медленнее весь runtime DS-стека на Python по сравнению с чем другим быстрым (С, С++, Julia итд) в реальной жизни.
Это не то чтобы предмет гордости, конечно же нет. Но признание проблемы - первый шаг к ее решению. На протяжении Python 3.4-3.12 мы видим последовательные шаги по ускорению на единицы процентов, теперь уже это десятки %%. Так что не надо нытья, кому надо быстрее и легче писать - пишут на простом и медленно ускоряющемся Python. Кому надо быстрее выполняться - сразу идут и пишут на чем-то сложном. Встретимся через год и сравним число проектов.
не-не, тут все больше по написанию комментариев соревнуются. Сишечка выигрывает за явным преимуществом, если что - так-то, Илон Муск!
> Кому надо быстрее выполняться - сразу идут и пишут на чем-то сложном. Встретимся через год и сравним число проектов.А почему проектов? А не строк кода? Логичнее оценивать по ним. Например, в питоне можно в 10 строк функцию написать, а в C для нее же потребуется сотня строк - т.е. получается для реализации той же задачи, в C можно в 10 раз больше кода написать, и впечатлить своего работодателя.
Именно поэтому проектов, а не строк кода.
Для сборки билда JIT требуется установка LLVM в качестве дополнительной зависимости. Для работы билда на конечной машине новых зависимостей нет. Грамотеи
