Фундаментальные ошибки дизайна синтаксиса языка программирования Python
Начну, конечно же, с отступов в синтаксисе Python... да-да-да, известная и избитая давно и многими тема, и тем не менее - этот архаизм в языке позволил мне сразу понять, что этот язык как-то "не очень", а при более детальном рассмотрении оказалось, что я был на 100% прав - Pyhon не стоит изучать, мало того, если вы действительно хотите изучать программирование, то он просто вреден для изучения, т.к. за скрытой внешней лёгкостью освоения кроются очень острые подводные камни, порочные методы и практики программирования. Я изучал множество языков программирования (из известных: Pascal, Assembler, C, C++, Java, Delphi, Perl, PHP, Ruby) и писал (пишу и ныне) программы на них, мой стаж программирования более 30 лет, и я прекрасно вижу, что Python - это худшее из всего, что я когда-либо наблюдал в программировании (ну, возможно, хуже только Бэйсик с номерами строк ;-) ).
Популярность Python в нынешнее время (2025 год) - это всего лишь дань моде, но что самое забавное - это не популярность Python, а популярность темы языковых моделей (ML-моделей) и искусственного интеллекта (ИИ, AI), где Python был выбран математиками из-за его простоты для них, из-за наличия уже готовых библиотек. А далее случился эффект сетевого маркетинга: если есть популярность и интерес, значит, надо успеть заработать деньги на обучении -> вдруг откуда ни возьмись появилось множество преподавателей (которые и сами то не сильны в программировании) Python, как грибы после дождя начали плодиться различные курсы обучению программированию -> появилось множество "программистов" Python (питонистов), которые знакомы с синтаксисом, но не знают программирования -> масса "программистов" ищущих в Интернет готовые решения, как следствие, увеличение запросов по теме Python в Интернет, а это в свою очередь влияет на рейтинги популярности языков программирования, вроде TIOBE, в итоге искусственно раздутая популярность Python привлекает ещё большее количество людей, желающих без особого труда легко и просто освоить программирование. Естественно (но в то же время довольно странно), интерес поддерживают и крупные гиганты IT-индустрии, которым почему-то проще нанять 100 Python-"программистов", чем 10 квалифицированных инженеров Rust.
В качестве примеров альтернативы я буду использовать Ruby, потому что по моему мнению это по-настоящему объектно-оринтированный язык программирования, с красивым, лаконичным и продуманным дизайном синтаксиса, точно так же интерпретируемый, и так же очень прост в изучении, а особенно понимании - код Ruby похож на английский - его сможет понять даже тот, кто ни разу не писал на Ruby.
Но всё же, давайте рассмотрим "прелести" этого чуда-юда мира языков программирования - Python, и разберём два главных архитектурных недостатка Python:
- self — неявное, но обязательное — антипаттерн
- __dunder__ — магия вместо ясности
И это не какие-то "особенности", а "дефекты дизайна" языка программирования, т.е. на фундаментальном уровне этот язык программирования уже содержит серьёзные недостатки.
self
class User: def __init__(self, name): self.name = name def greet(self): return "Hello, " + self.name
Кажется, что всё нормально, да? Но попробуйте забыть self
:
def greet(self): return "Hello, " + name # NameError: name 'name' is not defined
Или ещё забавнее, забыть self
в методе (хотя вроде бы это ООП, и методы объекта относятся к самому объекту как само собой разумеющееся... да!... но это не про Python) :
def greet(): return "Hello" # TypeError: greet() takes 0 positional arguments but 1 was given
Давайте сравним тот же код на Ruby:
class User def initialize(name) @name = name end def greet "Hello, #{@name}" end end
- @name — явно видно, что это переменная экземпляра
- нет никакого явного указания self в теле метода
- нет ошибок из-за забытого self
В Ruby — синтаксис поддерживает инкапсуляцию.
В Python — ты сам должен следить за тем, чтобы не сломать всё.
Почему это плохой дизайн?
self
— неявное, но обязательное: В метод передаётсяself
, но ты должен его писать вручную в сигнатуре. Ниthis
, ни@
, простоself.
- Нет инкапсуляции синтаксиса: В Ruby
@name
— сразу видно, что это переменная экземпляра. В Pythonself.name
— выглядит как обычный атрибут. - Можно случайно создать новую переменную:
self.nmae = "Alice"
— опечатка → создана новая переменная, старая остаётсяNone
. - Нет автоматического доступа к полям: В Ruby:
@name
— и всё. В Python:self.name
— в каждом методе, каждый раз, каждый раз - везде и всюдуself
,self
,self
...
__dunder__ — магия вместо API
Слово "dunder" (от double underscore) — уже само по себе как-бы говорит и показывает, что что-то тут не так. Нормальные языки не называют свои ключевые методы "дандер-инит" или "дандер-репр".
Примеры __dunder__ методов
__init__
— конструктор (в Ruby: initialize
)
__str__
— строковое представление (в Ruby: to_s
)
__repr__
— "официальное" строковое представление (в Ruby: inspect)
__len__
— длина объекта (в Ruby: size
, length
)
__add__
— a + b
(в Ruby: +
(через def +
))
__call__
— объект ведёт себя как функция (call
, __call__
в Ruby тоже есть, но редко используется)
__getitem__
— obj[key]
(в Ruby: []
)
__setitem__
— obj[key] = value
(в Ruby: []=
)
Почему это — плохой дизайн?
- __ — это не API, это магия. Нет документации "какие __ методы нужно реализовать", ты должен запомнить или гуглить.
- Неочевидно, что вызывается:
len(obj)
→ вызываетobj.__len__()
, но ты этого не видишь. - Нет централизованного интерфейса: В Ruby:
Enumerable
— ты видишь, какие методы нужно реализовать. В Python — ты должен угадать, какие __ нужны. - __ — нечитаемо:
__str__
→ "дандер-стр"? "дабл-андер-стр"? Это не для людей, а для машин. - Легко сломать:
__del__
— деструктор, но он не гарантирует вызов, и его использование не рекомендуется.
В Ruby: всё явно, читаемо, как английский.
В Python: len()
— глобальная функция, которая на самом деле вызывает __len__
— нелогично.
Контраргумент Python: "зато можно писать len()
вместо .length
"
Да, но:
- Это не экономия, а скрытие
len()
— работает только с объектами, у которых есть__len__
- В Ruby:
length
,size
,count
— могут быть разными, в зависимости от контекста. - А
len()
— один на всё, какsizeof
в C.
Это не гибкость, а упрощение до примитива!
Ответ на распространённое «Python — это же просто и понятно!»
Просто для новичка — не значит хорошо для профессионала
Да, print("Hello")
просто, но чем это проще puts "Hello"
в Ruby ? Но когда ты пишешь систему с 50 классами, где в каждом методе надо указывать self.
, это не простота — это штраф за каждый символ, это мучение — это как если бы ты платил 1 рубль за каждую точку в коде — в итоге получишь архитектурный долг. Когда-то в своей дипломной работе (1996 год) я точно так же писал систему на C в стиле ООП C++ , где первый аргумент "метода" - это ссылка на объект, но C - это далеко не объектно-ориентированный язык программирования, а в том проекте была явная имитация ООП, но в Python всё это преподностится как якобы какой-то стиль. И и уж если говорить о каком-то стиле, то повсеместное указание self — это, скорее антистиль, антипаттерн.
Dunder — это не API, это магия
Если тебе нужно знать, что len()
вызывает __len__
, str()
вызывает __str__
, +
вызывает __add__
, []
вызывает __getitem__
— это не язык, это головоломка! В Ruby всё это — естественные методы: to_s
, +
, []
— и они работают как ожидается, без всяких __.
Python учит плохим практикам
Python учит:
- писать
self.
везде - использовать __ вместо нормальных имён
- полагаться на
__name__ == "__main__"
как на точку входа - писать
if __name__ == "__main__"
: — это не код, это ритуал
А Ruby учит:
- писать чисто
- использовать
if __FILE__ == $0
— редко - писать DSL
- думать о коде как о живом объекте
Python — это не ООП, это C с классами
Python — это C с добавлением class
и self
. Настоящее ООП — это когда объекты "говорят" друг с другом, а не когда ты вручную передаёшь self
как первый аргумент. В Ruby self
— неявный получатель, в Python — явный параметр, который обязательно должен быть прописан в коде. Это и есть разница между объектно-ориентированным и процедурным с обёртками.
Python — язык для написания скриптов
Python — это не просто язык, а инструмент формирования определённого типа мышления, и это мышление — не программистское, а скриптовое.
Неопределённости с типами в сравнениях
def process(data): if data: return data.upper()
Кажется просто, но!... что такое if data?
len(data) > 0
?
data is not None
?
bool(data)
?
что если data = "0" ? data = [0]
? data = 0
?
Если в Ruby понятно однозначно, что nil
и false
— "ложь", а остальное — "истина", а вот в Python — ты должен помнить поведение 10 типов.
Рефлексия, замаскированная под функции
len(obj) # → obj.__len__() str(obj) # → obj.__str__() obj[0] # → obj.__getitem__(0) obj() # → obj.__call__()
Python - это антипрограммирование
Изучение Python — это антипрограммирование и "поломка мозга" с самого начала. Python — это язык, который учит делать, а не думать, поэтому и распространены практики поиска готовых решений, а потом, как результат — это работает, и хорошо, но я не знаю как это работает.
Изучение программирования на Python - порочная практика
Люди сами порой не знают, что выбирают, они думают: «Python — это модно», а на самом деле: «Python — это удобно для Google, Apple, Meta, чтобы держать разработчиков в экосистеме». Новички не видят разницы между "просто" и "хорошо", как и не видят разницы между: self.name = name
и @name = name
, __init__
и initialize
, len(obj)
и obj.length
. Выпускники вузов не могут писать на C++, Rust, Haskell, Ruby — потому что их мозг перепрограммирован на "магию" Python.
Python — это не вакцина, это вирус. Он распространяется через вузы, заражает мозги, превращает разработчиков в скриптовых магов.
Почему Python доминирует в образовании?
- Низкая квалификация самих преподавателей, которые освоили "простой" Python — и им этого достаточно, чтобы получать деньги за свою преподавательскую деятельность.
- Экономика времени: минимум синтаксиса для первого «Hello, World!» → иллюзия быстрого обучения.
- Data Science hype: библиотеки вроде numpy и pandas создали миф, что Python — это «язык науки» (хотя ядра написаны на C).
- Лоббизм корпораций: Google, Meta и другие инвестируют в Python-инструменты, чтобы снизить порог входа для новых сотрудников.
Мне искренне жаль тех студентов, которым в ВУЗ-ах преподают Python - вы всё дальше и дальше от этой прекрасной науки и исскусства, которым и является программирование!