The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Опубликован план избавления CPython от глобальной блокировки интерпретатора, opennews (??), 29-Июл-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


193. "Опубликован план избавления CPython от глобальной блокировки..."  +1 +/–
Сообщение от Аноним (193), 31-Июл-23, 18:39 
Я искренне ненавижу^W завидую Python, и это выражается в том, что в сраном Python:
1. Нет нормального маршалинга и стандартизации байткода. Вместо этого https://docs.python.org/3.11/library/marshal.html
2. Нет нормального JIT-компилятора, чтобы работала вся грамматика, но зато есть 1001 который частично работает почти со всеми языковыми конструкциями и который увеличивает производительность в паре краевых случаев, но в паре других все ухудшает
3. Нет нормальной сериализации в XML. Вместо этого есть это: https://docs.python.org/3/library/pickle.html
Барахло, которое 5 раз меняло спецификацию и которое полный NIH. Вместо того чтобы использовать стандарт W3.org вроде XML, они пишут гадость.
4. Python и кроссплатформенность - это шутка такая. Этот язык работает предсказуемо только на Linux, другие ОС поддерживаются так, что нужно писать тонну обвязок и изменять семантику действий.
5. Сообщество дурачков. Там правда сидят люди которые скажут, зачем тебе XML, если есть JSON.
Уровень образования настолько низок, что они не понимают:
- что такое SAX-парсер и почему DOM-а не хватает.
- не видели больших XML-выгрузок БД размером в пару сотен гигабайт, которые JSON-сериализатор не способен прожевать, потому что JSON должен всё это сначала загрузить в память, а XML работает и так через XPath и XSLT
- не видят жизни за пределами RESTful API, потому что других никогда не видели, а из-за убогости всех без исключения XML-библиотек в питоне, использование SOAP - это опять тонна рутины.

Я к своему огромному сожалению поддерживал и дорабатывал 2 внутренних "бизнес-продукта" на питоне каждый по 10k и 20k строк кода. Считаю это время самым потерянным в моей жизни, потому что в основном писал обвязки, проверки ОС, проверки интерпретатора, разборы XML вручную, ручную сериализацию в текстовый документик, чтобы поддерживало API на другом конце. А бараны из "сообщества", рассказывают сказки, что "мне это не нужно", "есть Python way", "поменяй/перепиши продукты на другой стороне API". Фантазёры, думал я. А потом я последовал их настойчивому совету и мы просто сели с пацанами и переписали... Переписали на .NET 6. И кода меньше и работает быстрее и сопровождать не надо столько.

Единственное что я могу сказать точно, что конкретно GIL - это абсолютно незначительно по сравнению с проблемой в п.1 и п.2. Отсутствие стандартизации, и как следствие отсутствие JIT в сочетании с AOT компиляцией приводят к тому, что это барахло работает так медленно, что выпиливание GIL вообще ничего не решает.

> Работать должен компьютер, а не человек.

Вот точно! Но не понятно при чем тут Python. Мерзкая дрянь, которая тратит время на написание бойлерплейта до такой степени, что там в некоторых модулях 60% обвязок, и 40% функционала.

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

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

201. "Опубликован план избавления CPython от глобальной блокировки..."  +/–
Сообщение от BeLord (ok), 01-Авг-23, 10:43 
Причем тут язык, если вся проблема, что вы выбрали ту работу, которая вам не заходит, вас под дулом пистолета туда привели и к батарее приковали?-)))
А за последние 25 лет, я много видел мусорного кода, что на Питон, что на Java EE, что на С. Проблема не в языках, а в прямых руках кодеров и мозгах архитекторов.
Ответить | Правка | Наверх | Cообщить модератору

204. "Опубликован план избавления CPython от глобальной блокировки..."  +/–
Сообщение от Аноним (193), 01-Авг-23, 13:45 
>> Сообщество дурачков.
> Причем тут язык, если вся проблема, что вы выбрали ту работу, которая вам не заходит

Вот именно про такую дурацкость в сообществе я и пишу.

Проблемы, которые я описал в п.1 - п.4 - это проблема именно языка, его интерпретатора и его стандартной библиотеки. Они не привязаны к моей работе лично или чьим либо проектам вообще. Наоборот, эти проблемы усложняют написание качественного и быстрого кода на питоне!

Сейчас это убогий по скорости, нестандартизированный, некроссплатформенный язык без поддержки сериализации не умеющий толком ничего кроме REST. Тут даже "jack of all trades" и универсальность языка не аргументы, потому что кто мешал написать стандарт байткода при переходе от 2 к 3? Кто мешал написать SAX-парсер для классов питона? Кто мешал прикрутить аннотирование к функциям и конструкторам?

Это тот самый случай культивирования культа карго. Питонисты не понимают, зачем это всё нужно, поэтому выкаблучиваются про то что "задача не та", "проект не тот", "работа не та" и прочее "не нужно". Они реально не понимают, потому что не видели задач. А задачу перед ними никто не ставит, потому что язык ни черта не умеет и спроектирован комитетом. Его "архитектура" нечто среднее между С++ и COBOL по мерзотности. При этом авторы не меняют ничего, потому что нет запроса на изменение. Это средневековье, мрак и культ карго.

Я, без шуток, проще найду общий язык на эту тему с разработчиками 1С. Они пусть и знают что они "погромисты" одной платформы, но им не нужно объяснять, что такое DTO и почему некоторые проливки лучше делать через SOAP. И про отчеты знают.

> Проблема не в языках, а в прямых руках кодеров и мозгах архитекторов.

Вот тебе одна из таких историй. Собственно та самая, когда проект от аутсорсера перевалили мне.
Наняла фирма как-то 8 лет назад (по глупости) группу как выяснилось позже питон-разрабов (2 пацана / ИП), которых попросила написать модуль отчетности для нескольких корпоративных АТС (телефонные продажи и саппорт). В форме внутрикорпоративного вебсайтика и задачей в стиле "вы сами лучше знаете как это писать, мы вам скажем что в выводимых таблицах".

При этом она этим аутсорсерам исправно платила за работу. И программа работала первые 2 года. Но как и любая отчетность эта тоже не стояла на месте. Были заказаны и оплачивались доработки на изменения отчетов и доработки на добавление новых отчетов. Со временем росло напряжение, потому что внезапно они не захотели поддерживать свой собственный продукт ни за какие вменяемые деньги! А когда их попросили помочь добавить их базу в ETL, чтобы сделать общий кубик (OLAP), эти придурки сбежали в истерике, разругались и не захотели больше работать, благо свой код они отдали без конфликта. Вот такое барахло мы с пацанами и переписывали на .NET, благо смогли найти контакт с истеричными аутсорсерами через год после того как они слились (у них реально был нервный срыв тогда от объема задач по этой статистике).

Казалось бы, а почему так, да? А потому что Python + Django + PostgreSQL.
- Когда ты используешь язык, который не работает по-нормальному ни с какой сериализацией, то каждый дополнительный ендпоинт обмена данными - это рукописный ад.
- Когда ты используешь MVC-фреимворк, то бизнеслогика отчетов смешана с техническим кодом и сопровождать это, когда много изменений логики и добавляются источники - сущий ад. Причем Django - "нитакиекаквсе" , они даже свое MVC называют иначе, просто потому что придурки^W "python way".
https://docs.djangoproject.com/en/4.2/faq/general/#django-ap...
Но это все равно MVC со всеми его плюсами и минусами.
- PostgreSQL - пожалуй самая плохая из всех возможных баз данных, когда дело доходит до визуализации и предварительной трансформации отчетности, пусть даже OLTP. Она пухнет, она тупит от Time Series, ей кластеризация - это набор костылей. И вот когда из этого барахла нужно кубы строить, то она понятное дело сама пролить данные и трансформировать не умеет. И в те годы не было Apache Airflow или был, но был молод. В общем кончилось это все переписыванием на ASP.NET Core + Angular + MSSQL для функициональных компонентов из которой проливалось все в PowerBI где были отчеты и дашборды наряду с другими отчетами компании.

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

Ответить | Правка | Наверх | Cообщить модератору

213. "Опубликован план избавления CPython от глобальной блокировки..."  +/–
Сообщение от agent_007 (ok), 07-Авг-23, 16:39 
> Мораль: не используйте Python и его фреимворки для динамичных внутрикорпоративных проектов.

Любопытное чтиво, но мораль несколько другая получается. Смотри:

1. контора наняла пацанов сделать простую штуку, они сделали, штука работала
2. контора усложнила штуку, пацаны не справились

Мораль: дело не в инструментах, а в требованиях к продукту. С простыми требованиями справились пацаны попроще, требования подросли, пришлось нанять пацанов посложнее.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру