А чем вам питонисты не угодили?😂

дауны

А почему именно питонисты

Кратко. Fasm хороший. Томаш - молодец. Столяров - луддит. За gas тебя закидают тряпками. С кт315 - не спорь. (Шучу).

Там вроде тоже свой псевдоасм есть, если не ошибаюсь.

Где? В питоне?

аксиома

столяров про nasm писал?

Да.

Не так не годится

Так исторически пошло. Если fasm это бетмен, то python - джокер. Выступает антагонистом в языковых спорах. Хотя с моей точки зрения основные пользователя питона - это вообще не разработчики а физики, дата сайнтисты, инженеры, биологи, гуманитарии, девопсы, и прочие, для кого язык как предмет изучения вообще не интересен

Никогда не было спора между ассемблером и питоном. Спор всегда был между ассемблером и Си

Был такой спор, потому что программисты на Python лезут в разработку прикладного и системного ПО, где ассемблер является вершиной. Они хотят вытеснить С и С++, потому что им сложно, а про ассемблер не помнят, потому что думают, что он вымер и на нём ничего не нужно писать, вот они и спорят с С-подобными языками, а с тыла нападают ассемблерщики и Rust, ну и Go где-то.

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

Ещё открою одну часть, есть такие люди на NodeJS, которые тоже решили писать программы, которые на самом деле полноценные отдельные браузеры.

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

Я полностью согласен что туда лезут дилетанты. Но мы стоим на пороге AI, где процент дилетантов станет ещё более ужасающим.

Вот с тобой они и поспорят. Может, потому что: 1. Python может собираться в исполняемый формат 2. В Python куча пакетов для разработки с уже готовым кодом, а ещё там нейросети знают его и все его пакеты как 2 пальца 3. В Python тоже можно вставлять ассемблерные вставки (но они скорее всего не понадобятся), и есть пакеты для компиляции прошивок на микроконтроллеры, модулей ядра для систем и прочих вещей.

Стикер

Стикер

кто подменил транзистора?

Я просто от их лица ответил, потому что приходилось с ними конфликтовать (с теми, которые хотя бы немного умные, а не "лол кек чебурек я на Python напишу за 5 сек а ты на ассемблере будешь миллион лет писать").

Стикер

с библиотеками может

Стикер

Потому что на это у них есть ещё вполне очевидные аргументы - им не важна скорость.

смотря чем собирать

Стикер

И размер, ага. Ну это им, конкретно им не важна скорость и размер

А им не важна скорость и размер. Вообще, у меня на ассемблере примерно такие же аргументы: Я хочу писать быстро, но не хочу писать на С или на Python -> пишу неоптимизированный код -> кто-то говорит "ты написал неоптимизированный код, компилятор бы лучше смог оптимизировать" -> я отвечаю "а я могу лучше компилятора, ассемблер позволяет это делать, но у меня нет цели гнаться за тактами, ассемблер позволяет и это, при этом ассемблер позволяет мне упрощать многие вещи, что не позволяет С или Python". Как если бы Сшник ответил на "у тебя программы все с огромным размером, а у меня по 10 килобайт выходит": "я могу заморочиться с линковщиком и получить тоже 10 килобайт, но у меня нет такой цели". И на Python, и на С, и на ассемблере можно заморачиваться и получать всегда результат лучше и лучше, никто этим не занимается, поэтому исходя из начальных значений получаем, что: С = среднестатистическая более-менее оптимизация Ассемблер = всегда маленький вес Python = быстрое написание кода При этом, и Python может быть с отличной оптимизацией, и С может быть с маленьким весом, и на ассемблере можно быстро писать код (макросы).

У питона ещё проблема с GIL

Это что?

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

И что это значит?

Не особо получится писать многопоточные приложения

всё нормально там с этим

мьютекс

во сколько потоков может выполнится одна отдельно взятая команда в ассемблере? ответ : в 1 поток тут такая же логика

Нет, 1 команда может выполниться в минимум 4 потока.

Речь про несколько одних и тех же команд, или про просто одну команду?

вот можно написав: mov eax, 6 сделать это в несколько потоков без использования других команд?

Как ты это представляешь? Как одна операция может выполняться в нескольких потоках? А главное - зачем?

такая же логика у пайтона

Понятно.

там нет многопоточности +- по этим причинам

Так там же есть библиотека thread.

ты с си путаешь

threading.

стандарт или нет? я просто базу пайтона знаю, но точно знаю что многопоточности нет от слова совсем

😂 Какой ещё стандарт, это что-то на Сшниковом?)) Раздражает уже это слово, честно говоря. Просто говорю, что оно есть, и даже используется в крупных популярных библиотеках (telebot, например, для разработки Телеграм-ботов), а вообще мне не интересно что там в Python, вот в ассемблере есть в новых процессорах аж от 4 исполнительных блоков арифметических операций, это значит что процессор может выполнить 4 независимых add за раз.

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

Убери мат.

я его скрыл ведь

Это так не работает.

Векторизация. Во первых. А во вторых ну ты слишком передёрнул. Никому mov eax не нужен в потоке. Так же как и не нужен 1 пассажир для взлета самолёта. Сделай функцию и тогда можно обсудить как она будет реально параллельно работать.

я привел пример того, как работает питон

Я боюсь что мы, обсуждая Python допускаем ту же ошибку, что м критики JavaScript, когда они решили, что браузер - это и есть эталонная реализации ecma стандарта.

не

Что-то мне вообще не верится, что интерпретатор Python не сможет проанализировать и исполнить две длинные независимые арифметические операции в разных потоках...

Эээ. Я тоже думаю что не может. Ну по крайней мере я не слышал о таком. Я просто товарищу акцентирую на том что не всегда параллелизм это единственное решение перформанса

так я об этом и не говорил😤

Хз языка разные все равно в реальности на одном си мало кто пишет если говорим про приложения

Это язык который входит в четверку по версии tiobe, Red monk.

это список того, сколько раз этот язык гуглят

А ты на других не смотри, на себя смотри, а то превратишься в девопёса на Rust по всем современным традициям, и 50% времени всего проекта будешь занят написанием скриптов для сборки.

До конца дочитай

по большей мере это из-за embedded

(Кстати, чисто на С проекты пишут, как и чисто на ассемблере, вопрос только в том, какие проекты для тебя являются авторитетными, и почему).

хотя там кастрированный с++ тоже приветствуется

все авторитетные

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

Ну я к слову ваще не разраб долгое время хотел им стать много где себя пробовал в плане разработки понял что ваще не для меня

Нам нужна метрика. Я не буду против новой. Давайте все варианты

hh

Такой не существует. Это как судить людей, как ты человека судить будешь? Слишком много факторов. Вот я пишу на ассемблере, а зачастую гуглю реализации на С, представляешь как я ломаю твою статистику Tiobe? А ещё я не использую GitHub, но у меня очень много проектов на ассемблере = сломал статистику GitHub (и s54820 говорил, что там очень много мусорных проектов, как и коммитов мусорных).

в любом случае ассемблер там в топ 20 входит, можешь радоваться)

Да. Проблемка. Но тогда у нас остаётся только субъективное видение популярности языка с позиции своей работы.

На 13 месте сейчас вообще, обгоняет PHP, Rust, Ruby, Kotlin даже. И я не радуюсь, потому что понимаю, что это вообще не показатель.

Тут то и оно... Просто пишешь на том, что нравится, и всё. Чем заразился - то и будет давать энергию.

мне как ассемблер нравится, так и с# и с++