Это неловкое чувство

когда нужно делать скоростной код и ты пишешь на Питоне

Зависит от задачи, конечно. Но задач, где питону не хватает производительности, очень мало.

Обычно всё наоборот: надо не написать быстрое решение, а быстро написать решение. И вот тут питон хорош.

А оптимизировать можно и позже — у питона много путей оптимизации. От jit-ов вроде pypy, до компиляции в нативные бинарники cython-ом.

А ведь первого раза должно было хватить, чтобы понять, что памяти не хватает.

Так я на разных компах (и в сильно разное время) собирал с разным (и всё более возрастающим) количеством памяти и с совершенно одинаковым результатом. Но, твой стиль мышления мне вполне понятен.

Отступы починили? Многострочные лямбды есть?

Отступы и не ломались. А многострочные лямбды, в принципе, есть... но я не знаю случаев кода, который с многострочной лямбдой был бы лучше, чем без неё.

Проблема руби, что он от Питона отличается слабо, но при этом имеет много более слабую экосистему.

В смысле батареек мало? В своей нише более чем, а тянуть руби куда-то кроме веба глупо, никто и не пытался особо, т.е. там адекватное сообщество.

Отступы и не ломались. А многострочные лямбды, в принципе, есть...

Эта песня хороша, начинай сначала.

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

Только благодаря сишным модулям. Без них любая элементарная задача стала бы проблемой. В то время как с нормальным языком можно просто писать либы на этом языке, а не скакать с бубном вокруг сишного апи на любой чих. Проблема питоноадептов: вы все время забываете, что у вас недоязычок-клей, а не ЯП общего назначения. Очень легко впасть в это заблуждение, потому что питон сильно похож на такой ЯП, но не является им. Вот с перлом, луа или жс все хорошо в этом плане, а рубисты как-то держат себя в руках (их недоязычок тоже похож на настоящий).

не ЯП общего назначения

Не, это вы всё время забываете, что «язык общего назначения» означает,, что его нужно применять только если никто из специальных не годится.

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

Правда, только в мире с ограниченными ресурсами, но других пока не обнаружили,

Код для перевода внутреннего представления строк на UTF-8 в релиз не вошёл

Это ученый изнасиловал журналиста или в чем идея менять внутреннее представление строк на utf8?

я выбираю С#

да ты же поехавший

Мне кажется более целесообразным писать на Python только тот код, который не требует высокой производительности. Куски кода в котором нужна производительность нужно писать на си, собирать в so, и подключать к Python через cffi

Отступы и не ломались. А многострочные лямбды, в принципе, есть...

Эта песня хороша, начинай сначала.

Не тот кусок цитируешь. Правильный кусок:

но я не знаю случаев кода, который с многострочной лямбдой был бы лучше

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

Если не знаешь питона — предложи на любом другом языке, я переведу.

Интересно, почему офтопик только 32? Где 64?

Куски кода в котором нужна производительность нужно писать на си

Обычно, да. И это справедливо для любого языка, не только для питона.

Но в случае питона есть три особенности.

Во-первых, очень редко нужна «максимально возможная производительность». В большинстве задач нужна «достаточная производительность». Если питонокод выдаёт результат за секунду, и этого достаточно, то глупо тратить время и оптимизировать его до четверти секунды. Оптимизируют — когда это нужно.

Во-вторых, если не хватает совсем немного скорости, то, чтобы не переписывать, можно запустить этот же код jit-ом вроде pypy. Вот в этом и хорош PyPy — прирост скорости без траты времени на оптимизацию.

В-третьих, если и этого не хватило, то не надо переписывать на си, можно сгенерировать сишный код, если расставить типы и пройтись cython-ом. Он сам конвертирует данные из питоновых типов в сишные и обратно.

Python — не самый быстрый язык, но от медленного питона до быстрого си — пара шагов.

Да.

Это неловкое чувство

когда нужно делать скоростной код и ты пишешь на Питоне

Это чувство характерно для всех интерпретаторов

Ну ладно.

Отступы починили? Многострочные лямбды есть?

Вы хоть бы реальные проблемы упоминали, а не какую-то вкусовщину.

То, что PyPy интерпретирует питон - побочный эффект. Цель pypy - удобный jit для произвольных языков. Но писать jit на Сях - упороться: долго и больно. Поэтому его написали на промежуточном языке, который оказался похож на питон. Поэтому и прикрутили питона.

Вообще pypy он self-hosted то есть написан сам на себе. Это примерно также как gcc написан на gcc (они сами свои расширения используют и, например, msvc'ой не собираются) но может принять пару других языков потом.

Что вообще происходит?

новаторский подход к этим вашим цифрам, кажется

Он ыкзе из программы умеет делать?

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

И это справедливо для любого языка, не только для питона

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

да ты же поехавший

Ну и что? Пистон от этого лучше не становится. Может кому-то нравится писать на C обмазываясь недоязычком, ну это такое... Чем то поприличней хоть бы обмазывались.

нужны только два языка - асм для скррости и эффективности, и питон для быстроты и простоты

Оба мимо. Асм не нужен если ты не компилятор, питон нифига не простой, а наоборот переусложнен.

Но асм же позволяет наиболее маленький и быстрый код создавать?

Что есть проще, но сравнимео по возможностям с питоном?

Но асм же позволяет наиболее маленький и быстрый код создавать?

Или маленький, или быстрый. И тот и другой создаётся оптимизатором, смотря какую опцию указать.

Но ты, наверное, очень много кода на асме написал...

Что есть проще, но сравнимео по возможностям с питоном?

Жабаскрипт.

Он ыкзе из программы умеет делать?

JIT-интерпретатор же. Ыкзе делаются компиляторами. На худой конец есть AOT.

А почему компиляторов питона нет? Даже у бейсика были компиляторы, а тут...? 😬

Сделать exe есть куча способом http://nuitka.net/ например.

А cython чё такое по-твоему? Другое дело что они все libpython линкуют и автоматически збс не сделать, но это и не нужно. Зачастую достаточно пару букв написать чтобы получить ускорение в 10000+ раз.

Куйзнает, что есть этот цитон, как я из разного понял - чтото си- подобное приделывается к питону, и нативные питоновые проги там не компилируются?

Ну, да, нуитка ещё. И всё...

C и родственников (будь то плюсы или прочий раст) выводим из класса «языков общего назначения»? Не, я могу понять вашу мысль, это языки заточенные на написание эффективного кода, но их принято считать именно что языками общего назначения, а что они не, это, что называется «а мужики-то не знают».

Бейсик статически типизированный язык. Ничего, что требовало бы именно интерпретации в Бейсике попросту нет.

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

Таак, а можно пойти от начала? В юности я читал что язык может преобразовыватся в машинный код либо интерпретатором, либо компилятором

Что мешает любой язык и так и этак транслировать?

А я в юности читал древнюю (уже тогда далеко не новую, хотя потом было четыре пересмотренных переиздания) книжку Теренса Пратта «Языки программирования: разработка и реализация». Там языки сравниваются по времени связывания чего-то с чем-то. В языках со статической типизацией переменная связывается с типом во время компиляции, с динамической — во время исполнения. Более позднее время связывания влечёт за собой усложнение рантайма (и, следовательно, результат трансляции будет больше похож на интерпретатор, напомню, что чистый интерпретатор, это разве что какой-то bash, все языки программирования используют трансляцию исходного текста в некий промежуточный код). А ещё есть время связывания во время определения языка. Как знаки операций в C (но не C++). Такое время связывание позволяет писать быстрые и простые компиляторы (к С это относится, см. к примеру tcc, C++, очевидно, не из таких). Это если вкратце.

зы. В Питоне динамики/позднего связывания хватает.

В моей юности были бк0010, двк3 и тотальный дефицит книг по этим темам в магазинах.

Насчёт связывания - энивей невижу никаких причин.

А, в моей тоже. Хотя ещё программируемый микрокалькулятор и ZX-клоны (а ещё я видел работающие БЭСМ-6 и Наири). Книжку купил в букинистическом отделе магазина тех.книга в центре моего города (точнее областного центра, в пригороде которого живу). Хотя TurboPascal учил по изданной в Польше на польском языке книге, купленной в «Глобусе».

Второе предложение слегка не распарсил? Причин для чего?

Вот когда (если?) в институт поступишь на соответствующую специальность, расскажут. Ещё и свой компилятор придется написать.

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

Спектрумы были позже, в районе 92-93-го. А конец восьмидесятых были микроши за 600, чтоли, рублей - сумасшедшие деньги...

Ну я в 1990 видел у человека собранный им лично (в 1989) клон спектрума. Массово да, 1992, брат мой младший на таком в игры играл.

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

И да, на всякий случай, машкод i8086 уже был заметно тяжелее человекочитаем, чем система команд PDP-11 (как в БК-0010, ДВК 2-3, Электроника-60 и УКНЦ). x86-64 с кучей слоёв legacy и подавно тяжёл. Это к тому, что на тех машинах бэкенд компиляторов было определённо легче писать.

Мне кажется более целесообразным писать... на си, собирать в so, и подключать к Python через cffi

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

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

асм для скррости и эффективности, и питон для быстроты и простоты

Ты забыл про переносимость

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

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

java и производные, javascript, php, perl, tcl, lisp, bash... Смотря какой язык считать языком «общего назначения», и что считать «не состоятельным». Сишные экстеншны и библиотеки почти во всех языках используются.

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

4.2, 4.2, мб, 4.2, юзают полтора инвалида, ололо, не язык общего назначения.

которые не используют модули или библиотеки на сях?

Я даже отвечать на эту тупость не буду.

yCTPOy_Destroy

это чья реинкарнация интересно скор фармит

4.2, 4.2, мб, 4.2, юзают полтора инвалида, ололо, не язык общего назначения.

Хм... Прямо 4.2? И на чём же там пишут высокопроизводительный код? Например, в каком из этих языков есть быстрая арифметика произвольной точности без сишных расширений?

языки заточенные на написание эффективного кода

Буквальное определение DSLя же?

Однако то, что си и родственники, на самом деле, заточены на написание эффективного кода - весьма спорно. Во первых, эффективности бывают разные, и часто конфликтующие — на поверхности сознания, в произвольном порядке: 1. размер рантайма, 2. время выполнения, 3. потребляемая память, 4. скорость написания, 5. стоимость поддержки

Си — можно считать, заточен на первое — просто потому, что почти не отсебятит. Но это нужно только редким встроителям. И он точно ничего не делает для 2  — авторам компилеров приходится изрядно изобретательствовать, чтобы сохранить смысл кода при оптимизации. 3 - полностью на совести автора, «Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out!»

C++ продажа 1-2 за немножко 4, числится в списке «быстрых» только потому, что осторожные программисты могут найти выгодный балланс,

И т.д. Суть сего в том, что «не мешать добиться Ф» и «быть заточенным для Ф» - разные вещи.

их принято считать именно что языками общего назначения

Формально, «язык общего назначания» — язык, одинаково плохо подходящий для любых(широкого круга, как минимум) задач. Язык, в котором нет специфичных вкусностей. Наличие/отсутствие способов добиться какой-то из эффективностей доменной спецификой считать не получается — эффективность везде приятна.

«а мужики-то не знаютзабыли»

что разница возможностей «получить приемлемо работающий за приемлемое время код» и «получить за приемлемое время приемлемо работающий код» — никак не относится к понятию «общего назначения».