Почему питон плохой язык

Почему Python не станет языком программирования будущего, даже если сейчас популярен

Python появился в мире программирования довольно давно, но с начала 2010 годов переживает бум — он уже обогнал по популярности C, C#, Java и JavaScript. До каких пор будет сохраняться тенденция роста, когда Python заменит какой-то другой язык и почему?

Перевели колонку Rhea Moutafi, он считает, что у Python есть несколько свойств, которые помогли ему стать популярным языком. Но есть и слабые места, они уничтожат его в будущем. Автор перевода не всегда разделяет мнение автора статьи.

Что делает Python популярным прямо сейчас

Популярность языка программирования можно отследить по динамике количества тегов на самом востребованном у разработчиков ресурсе — Stack Overflow. Так, судя по графику, рост Python начался с 2010 года, а стремительным он стал в 2015 году. В то время как R в течение последних нескольких лет находится на плато, а многие другие языки находятся в упадке. У такой популярности Python есть причины.

Время существования

Python можно смело назвать довольно старым языком — он появился в 1991 году, то есть практически 30 лет назад. За это время он постепенно собрал вокруг себя большое сообщество.

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

Простота

Python можно смело рекомендовать как первый язык программирования. И дело не только в том, что он существует давно и поэтому по нему есть много хороших учебников. У него понятный синтаксис, похожий на обычный, «человеческий» язык. и еще он прощает ошибки.

Например, в нем не нужно указывать тип данных, достаточно просто объявить переменную. Из контекста Python поймет, является ли она целым числом, числом с плавающей запятой, логическим значением или чем-то еще. Это огромное преимущество для начинающих.

Если вам когда-либо приходилось программировать на C++, вы знаете, как это печально, когда программа не компилируется только потому, что вы где-то поменяли число с плавающей точкой на целое число.

Код Python довольно просто читать. Просто сравните синтаксис Python и C++.

Универсальность

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

1. Для многомерных массивов и высокоуровневых матриц используйте NumPy.
2. Для расчетов в инженерном деле подойдет SciPy.
3. Для исследования, анализа и манипулирования данными попробуйте Pandas.
4. Для работы с искусственным интеллектом изучайте Scikit-Learn.

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

Недостатки Python, которые могут уничтожить этот язык

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

Скорость

Python медленный — в среднем, на операции на нем понадобится в два, а то и в десять раз больше времени, чем если бы вы выбрали другой язык. Для этого есть разные причины. Одна из них в том, что Python — язык с динамической типизацией. То есть на нем не нужно заранее определять тип данных, как в других языках. Конечно, это удобно разработчику, но такой подход требует большого резерва памяти для каждой переменной, чтобы она работала в любом случае. Соответственно, больше памяти означает больше времени на вычисления.

Python может выполнять только одну задачу за раз, как раз из-за того, что язык должен проверить тип данных. Параллельные процессы всё испортят. Для сравнения, обычный веб-браузер может запустить несколько десятков различных потоков одновременно.

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

Области видимости

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

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

Питон пытался перейти к статической области видимости, но ничего не вышло. Обычно внутренние области видимости — например, функции внутри функции — могут видеть и менять внешние области видимости. В Python внутренние области могут только видеть внешние области, но не менять их. Такой подход приводит к путанице.

Лямбда-функции

Несмотря на всю гибкость, использование лямбд в Python ограничено. Они могут быть только выражениями (expressions), но не инструкциями (statements). С другой стороны, объявления переменных и statements и есть инструкции. Проще говоря, добавление statements сделает лямбду многострочной, а синтаксис Python не позволяет так сделать.

Это различие между expressions и statements довольно произвольно, и не встречается в других языках.

Пробелы

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

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

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

Мобильная разработка

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

В Python такая возможность как бы есть — пакет под название Kivy. Но нужно учитывать, что Python не был создан для мобильных устройств. Использовать его можно, результат будет даже приемлемым, но зачем, когда можно взять более подходящий язык, созданный для разработки мобильных приложений. Например, фреймворки для кроссплатформенной мобильной разработки: React Native, Flutter, Iconic и Cordova.

Если вы планируете стать всесторонне развитым разработчиком, только знания Python недостаточно.

Ошибки во время выполнения (Runtime Errors)

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

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

Основные недостатки языка Python

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

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

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

Более искушённые программисты ценят этот язык за удобные средства для построения пайплайнов отложенных, или как ещё говорят — ленивых, вычислений. В Python эта функциональность реализуется итераторами и т.н. генераторами. Библиотека асинхронного программирования также довольно хороша.

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

Скорость

Основным среди таковых принято считать его медлительность, хотя это с определённой долей справедливости парируется тем, что скриптовому языку скорость особо и не нужна. В задачах, требующих высокой производительности, он выступает лишь как обёртка для манипуляций с API низкоуровневых библиотек, написанных на языках с поддержкой AOT-компиляции. Самыми популярными из таких языков на данный момент являются, конечно же, C и C++. На первом, например, реализована широкоиспользуемая библиотека NumPy , созданная для математических операций с массивами произвольной размерности. На втором — набирающий популярность фреймворк для обучения нейросетей PyTorch .

Как бы то ни было, что-то высокопроизводительное на чистом Питоне написать не получится. Для этого требуется прибегать к помощи других языков или использовать статически типизированные расширения, такие как, например, Cython , на которых писать, мягко говоря, неприятно.

В общем, недостаток в скорости ограничивает область применения этого языка задачами, в которых время операций ожидания ответа на запрос многократно превышает время работы тела скрипта. Среди них можно выделить:

• Использование Python в качестве языка командной строки и управления взаимодействия между другими программами. Здесь он имеет определённое преимущество перед Bash , Sh и прочими языками оболочки, лишёнными удобной работы с массивами и строками и имеющими плохочитаемый синтаксис. Тем не менее описывать конвейеры в последних намного удобнее. Пример: управляющие скрипты большинства дистрибутивов Linux.
• Конфигурация и управление базами данных. Примеры: модуль sqlite3 , Django и т.д.
• Манипуляция потоками вычислений, в которых расчёты производятся глубоко оптимизированным кодом, скомпилированным в непосредственные инструкции процессора. Python тут выступает лишь как среда для взаимодействия с API по инициализации и описанию структуры взаимодействия этих потоков. Примеры: NumPy , CuPy , PyTorch и т.д.

Почему Python медленный

Тут есть два основных фактора:

• В нём практически всё аллоцируется на куче.
• Перед выполнением операций с любым объектом интерпретатор проверяет его тип.

Давайте взглянем на примерную реализацию структуры в коде CPython , которая является обязательной частью всех питоновских объектов:

Переменная ob_refcnt отвечает за подсчёт ссылок, указывающих на данный объект. Если их количество становится равным нулю, это становится сигналом для сборщика о том, что память, занимаемую этим объектом, можно освободить. ob_type указывает на тип данного объекта. Плюс к этому, если объект владеет сущностью нефиксированного размера, указатель на тип дополняется указателем на область памяти, где эта сущность хранится, и переменной, отвечающей за её размер.

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

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

Оптимизации векторизации тут тоже не работают. Как пример, обычный питоновский массив вида [100, 200, 300, 400, 500] , на самом деле, как было показано выше, хранит не целые числа, а указатели на объекты типа int , каждый из которых хранит указатель на область памяти, в которой записано соответствующее ему число. Даже один косвенный указатель ломает векторизацию, а тут для доступа к информации о числе нужно пройтись, как минимум, по двум. Лиха беда начало, перед каждой операцией с объектом интерпретатор Питона должен перейти в область памяти с реализацией соответствующего метода для текущего типа, и переход этот делается опять же по указателю.

Динамика

Как мы видим, безопасность, которая обеспечивается моделью памяти языка Python, сводит на нет большое число возможных процессорных оптимизаций. Тем не менее знающие читатели могут заметить, что, например, в Java все объекты, за исключением примитивных типов, так же аллоцируются на куче, но код на этом языке работает гораздо быстрее. Так почему бы интерпретатору Питона не реализовать оптимизации, присущие виртуальной машине Java, — например, копцепцию JIT-компиляции?

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

Во-первых, это динамическая типизация

Данное словосочетание означает тот факт, что переменная, объявленная в этом языке, не имеет привязанного к ней типа. То же самое касается сигнатур функций и полей классов.

Писать что-то подобное возможно только в динамически типизированных языках:

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

Вторая такая особенность — это пространство имён.

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

Третьим фактором является широкая гибкость в динамическом переопределении процесса создания объектов. В Питоне возможно такое:

Этот код требует пояснения. Дело в том, что в Питоне все сущности, существующие в рантайме, являются объектами. Объекты, в свою очередь, являются реализациями, или как их ещё называют — инстансами, классов. Но классы же ведь тоже являются объектами.

Как вы можете догадаться, те сущности, инстансами которых являются классы, называются метаклассами.

В данном конкретном примере классы Foo и Bar имеют общий метакласс Meta , который подменяет тип, от которого пытается наследоваться класс. Так, при попытке отнаследоваться от типа list , класс, на самом деле, станет наследником типа tuple , а в противном случае — типа list .

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

Ну и наконец, четвёртой сложностью является возможность создавать классы динамически.

Все эти особенности негативно влияют на возможность предоставления статических гарантий относительно поведения кода на языке Python. Существующие анализаторы, основным из которых является MyPy , нельзя назвать законченными. Особенной проблемой является то, что на данный момент они имеют крайне ограниченную функциональность при анализе случаев, подобных взятым из последних двух примеров. Ситуация осложняется тем фактом, что, несмотря на все те правильные инициативы, связанные с внедрением модуля typing в предыдущих релизах, система аннотации типов в Питоне остаётся невыразительной. Например, для указания интерфейса типа возвращаемого аргумента функции wrap_class из последнего примера требуется поддержка типов-пересечений, которой на текущий момент нет.

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

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

Выводы

В данной статье были рассмотрены два основных недостатка языка Python, а именно: его малое быстродействие и недостаточные возможности статического анализа кода. Эти проблемы взаимосвязаны, и решение последней автоматически откроет дорогу для решения первой.

Уже сейчас в мире существуют динамически типизированные языки с опциональной компиляцией, основанной на уточнении типов. Самым интересным из них, на мой взгляд, является Julia. Возьмут ли разработчики CPython его пример на вооружение — покажет время.

Как бы то ни было, язык Python является отличным инструментом для быстрого написания кода. Его широкие динамические возможности, а также понятность и, я не побоюсь этого слова, красота синтаксиса обуславливают то, что процесс составления программ на нём действительно вызывает удовлетворение. Тем не менее, как и любой инструмент, этот язык имеет свои недостатки и о них полезно помнить перед началом своих проектов.

Python — отстой: разочарованный разработчик обрушился с критикой на популярный язык программирования

Разработчику программного обеспечения Майклу Морено не угодил Python. Чем именно, специалист написал в блоге на Medium, чем привлек внимание более 6,5 тысяч пользователей. Что, по мнению разработчика, такого плохого в детище Гвидо ван Россума — узнаете далее.

Собираем на дрон для штурмовиков Николаевской области. Он поможет найти и уничтожить врага

«Повторю еще раз: Python — плохой язык программирования», — с таких слов начал свой пост возмущенный разработчик. Главная причина, по которой язык настолько популярен, в том, что Google сильно продвигала его в первой декаде «нулевых», уверен Майкл Морено. Вот что он написал.

Все началось в Google

Создатель Python работал в Google с 2005 по 2012 год. Таких языков, как Go и Dart, тогда еще не было, или, по крайней мере, они не были широко известны, а с учетом того, что C# набирал популярность, в Google, вероятно, поняли, что им нужен собственный язык. По сути, можно было использовать Java, но тогда бы они не миновали очередных юридических проблем с Oracle . Тогда, по неизвестным причинам, боссы компании выбрали Python.

Пруф, что Гвидо ван Россум работал на Google

Позвольте объяснить, почему Python — отстой. Да, будет трудно, учитывая его популярность, но постараюсь. Я расскажу не о самом языке, не о его производительности или возможностях реализации, в основном моя цель — сравнить его с Java и C#. Почему? Потому что эти два известных, зрелых языка программирования уже более 15 лет находят широкое применение в мире разработки программного обеспечения.

Язык фрагментарного программирования

В течение очень долгого времени у Python было две основные версии — Python 2 и 3, которые, к слову, несовместимы друг с другом. Таким образом, разработчики попадали в странную ситуацию. В Google призывали всех изучать Python, потому что это «круто». Кто-то скачивал вторую версию, кто-то третью, и только потом выяснялось, что, например, у Python 3 почти нет совместимых библиотек, и никто не использует эту версию. Единственная причина, зачем ее разрабатывали, — это добавление круглых скобок в функцию print() и поддержка эмодзи. Что до Python 2, то из-за множества ошибок (около 3300), в Ubuntu, например, вообще решили отказаться от его использования.

Уродливая ориентация объекта

Класс в Python выглядит так:

Обратите внимание на ключевое слово self . Оно в Python везде! Это способ обращения к переменным экземпляра класса. Чем-то похоже на this в Java и С#, только в Python оно обязательно.

Но это приведет к тому, что интерпретатор Python исказит имя переменной так, что она станет недоступной за пределами класса. Так или иначе, она не станет частной переменой, но имя исказится 100%. Оно вам надо?

Кстати, если спросить об этом Python-разработчика, он лишь ухмыльнется и посоветует не обращаться к переменным экземпляра другого класса. Будьте готовы, разработчики Python враждебны и беспощадны к тем, кто указывает на недостатки их «родного» языка программирования.

Пробелы — то, чего нельзя увидеть

Еще одна причина, по которой Python — это мусор. В нормальном языке для разграничения области видимости используются фигурные скобки или ключевые слова BEGIN и END . Но не в Python! Создатели языка решили, что было бы здорово придать пробельным символам семантическое значение. Но с какой стати они придали семантическое значение тому, чего нельзя увидеть? Кто решил, что это хорошая идея?

Динамическая типизация — это лук и стрелы

Динамическая типизация — это плохо. Любой, кто со мной не согласен, вероятно, написал еще недостаточно программного обеспечения, чтобы это понять. При динамической типизации, чем больше программа, тем выше вероятность, что она необслуживаемая. Вангую, в будущем все основные языки программирования будут статически типизированными, а использование динамически типизированного языка будет похоже на использование лука и стрел. Не удивлюсь, если видео, как люди программируют на динамических типизированных языках, есть на YouTube-канале Primitive Technology . Языки, появившиеся совсем недавно, такие как TypeScript, вселяют в меня надежду.

Кодинг на Python равен процессу создания первобытного орудия, уверен автор

Некоторые питонисты поняли, что динамическая типизация — это плохо, следствием чего стало создание модуля mypy . Но! Если вы собираетесь добавить аннотации типов в Python, почему бы вам просто не использовать Java или C#?

Константы. Точнее их отсутствие.

В Python нет констант. А чего вы еще ожидали, дочитав до этого места? Кстати, вопрос о том, как сделать переменную постоянной, задали на Stack Overflow, и совет разработчика Python был « просто не меняйте ее ».

Заключение и взгляд в будущее

Python — это пример того, как люди пытаются жить с чем-то, приспособиться и заставить себя полюбить что-то, вместо того, чтобы избавиться от этого и перейти на что-то лучшее. Может быть, это все история про любовь, надежду или что-то еще? Каким-то образом этот некачественный язык превзошел несколько более современных языков, и, возможно, уже слишком поздно что-то с этим делать.

В 2014 году Python стал самым популярным вводным учебным языком в университетах. Так что в ближайшее время мы начнем видеть все больше детей, приходящих в индустрию с Python в качестве основного языка, и его популярность будет только расти по мере того, как на нем будет писаться все больше и больше программ. На момент написания материала он занимает второе место в индексе TIOBE , и эта компания назвала Python «языком программирования 2020 года».

Да, если хотите заниматься машинным обучением и наукой о данных в 2021-м, используйте Python, поскольку это язык с наибольшим количеством библиотек. По крайней мере, мы можем быть благодарны Google за то, что они не стали продвигать Brainfuck .

Насколько конструктивна критика автора? Согласны с его словами? Пишите об этом в комментариях.

Почему питон — плохой язык

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

Низкая производительность Питона — также нельзя сказать, что так уж плохо, потому что 90% времени исполняются 10% кода, а 81% времени — соответственно, 1%. И, переписав этот 1% на С, мы получим почти такой же выигрыш, как если бы писали всю программу на C с самого начала.

Но перейдём, собственно, к проблемам.

1. GIL. Ребята, вы серьезно предлагаете для промышленного использования среду исполнения с такой штукой?
2. Замена байтовых строк на юникодные при переходе от питона 2 к питону 3. Обратная совместимость? Не, не слышали.
3. Скобочки у print. Дебилизм, конечно. Но — .
4. При таком трепетном отношении к обратной совместимости, довольно странно наблюдать три разных вида оператора format с разными синтаксисами форматной строки.
5. . И всю эту шнягу с «объектами старого типа» и «объектами нового типа».
6. Тому, кто будет мне рассказывать про то, как в питоне все хорошо и симметрично и все на свете объект, я предложу выпить из дуршлага получить ссылку на переменную. Или на элемент массива. Что это за симметрия, когда все объект, а переменная — не объект?
7. Еще на тему консистентности. Конструкция [i for i in range(10)] возвращает список. Логично. Думаете, (i for i in range(10)) вам вернет тупль? Хе хе хе.
8. И еще хуже. [True]*10 вернет вам список из 10 значений True. Логично. Теперь попробуйте аналогичным образом проинициализировать двумерный массив 10×10. Да, у вас получится матрица 10×10 из значений True. Но попробуйте в ней что-нибудь поменять.
9. Почему функции и генераторные объекты определяются одним и тем же ключевым словом def? Ведь это объекты разной природы и с разными ограничениями на возможное использование. Но единственный способ отличить их один от другого в коде — это искать ключевое слово yield, которое может быть где угодно. Ключевых слов пожалели? Нет, серьезно?
10. Почти на ту же тему: какой смысл в разрешении использовать в качестве декоратора любую функцию? Ведь результат приложения «нормальной» функции как декоратора, практически по определению, деструктивен. Осмысленно работающие декораторы надо писать специально. Опять ключевых слов пожалели?
11. Приватные атрибуты через подчерк. Мне снова сложно сказать что-то, кроме «ребята, вы серьезно?».
12. У атрибутов с одним подчерком имена не манглятся. А с двумя подчерками — манглятся. Кто тут что говорил про простоту, логику и консистентность?
13. Управление видимостью имен на уровне модуля — вообще какой-то горький катаклизм. Нет, я понимаю, что импорты с перечислением спасают от полной катастрофы. Но для больших модулей это как-то довольно грустно. И все-таки, почему бы не разрешить было разработчику модуля описывать нормально выглядящие (без кучи подчерков) имена как неэкспортируемые? Все равно же иногда вы делаете манглинг, но почему только в одном случае, а не в других, когда это было бы полезно?
14. Идиома __name__ вообще не имеет иного объяснения, кроме «ключевых слов пожалели».
15. И еще на тему пространств имен:

Ну ладно, здесь еще легко понять, в чем дело. Но представим себе большой проект с кучей существующих файлов, и вы подключаете к нему ранее не использовавшуюся библиотеку, а внутре этой библиотеки используется еще библиотека, совпадающая по имени с одним из файлов вашего проекта. В С над этой проблемой еще в 70е годы задумались и решение предложили, а тут — .
16. И вообще, динамическая сборка с принудительным началом поиска в текущем каталоге — это довольно серьезная дыра в безопасности.
17. Классы с наследованием, которые не зовут конструкторы родителей — это сильная и неожиданная идея.
18. Синтаксис для обращения к атрибутам предковых классов тоже не вызывает ассоциаций с простотой и логичностью.
19. Ребята, вы, наверное, не в курсе, но во всех нормальных языках со смесью динамической и статической типизаций, статические типы дают повышение производительности.
20. Совсем уж очевидный вопрос: ребята, а где у вас цикл с постусловием. while True: . if x break? Вы бы тогда уж и goto бы добавили, для полной чистоты идеологии?
21. Ну и на сладкое — это, конечно, синтаксис с выравниванием. Да, идея, возможно, была благая (заставить учащихся выравнивать код красиво). Но в результате мы имеем язык, на котором можно писать только в IDE или, хотя бы, LSE. Потому что простые вещи — например, окружить цикл условным оператором или вынести кусок кода в функцию — осуществимы только в IDE с поддержкой рефакторинга.
22. По той же причине, «пробелы vs табуляции» из повода для хихонек и религиозных войн превращается в мощный источник не только синтаксических, но и семантических ошибок (видя табуляцию не на месте, далеко не всегда можно понять, что же тут хотели написать).
23. А вы задумывались, почему в Питоне нету многострочных лямбд? Хе хе хе.

Продолжение

Главная угроза безопасности в сетях канального уровня — это широковещательные штормы. Они возникают от петель в сети. Будучи студентом, работал…

От универа загнали на курсы повышения квалификации

Узнал много нового. Тема называется Сетевые устройства L2/Работа коммутатора. У нас очень умное устройство которое называется свитч. Оно ведет…

И еще объявление

Нужны семинаристы на курс «Операционные системы». В большом количестве (по хорошему, три-четыре человека или два человека, которые могут взять две…