[мегапузырь_IT] небольшой ликбез по просьбам трудящихся, не только про питон
Первоначальная запись: 2020-09-06, 2020, 16:00.
В силу шквального интереса запись подвергнута вылизыванию + добавлены ссылки.
[мегапузырь_IT] начало и оглавление
Просьба пришла в комменте. Придётся немного отвлечься -- по той же причине, по которой Наблюдатель ломается с другим, благотворительным проектом, включая спецкурс, бывшие слушатели которого стали возвращаться с поддержкой.
Тема дико важна (все эти "умные дома" и прочие беспилотники в воздухе, на земле и под водой, на простых батарейках и на ядерных, с пассажирами и с боеголовками ...), но затоплена мракобесием по самое буквально не могу под руководством контуперных идиотов.
Пишется экспромтом, поэтому какие-то пунктики могут быть забыты [Upd см. комменты]. Но главное сидит в печёнках.
***
Просьба пришла в ответ на констатацию, что язык программирования питон -- это полное говно.
Не случайно именно там -- именно языки программирования служат главной темой религиозных войн в сфере цифры. Для этого в приматическом мозге есть причины, о которых нужно говорить отдельно.
Оговорка. Языки программирования имеют аспект группового феномена, поэтому это говно кому-то приходится жрать за компанию, трофики ради-для. Тут ничего не поделаешь.
Но сей трофический аспект в иных случаях служит основанием для глубокомысленного вывода, что говно питон всё-таки не полное. -- А вот это уже дело вкуса. Потому что субъективное и даже попъективное восприятие говна не может отменить его объективную природу.
***
Первое и самое главное:
Говном является любой язык программирования, дизайн которого не предусматривал в числе приоритетов полноценную защиту программиста от ошибок.
Этот тезис раскрывается только с болезненным опытом пресловутой агонии отладки в процессе естественной эволюции программ (а программы на удивление живучи и растут как раковая опухоль). Разработка программы -- это частный случай такой эволюции.
Агония измеряется метафорической дробью, в числителе которой стоит количество разных фич языка (т. наз. "выразительная мощь"), причём в квадрате (потому что проблемы порождаются взаимодействием фич), а в знаменателе -- степень защиты, которую язык обеспечивает. О том, насколько сильно можно подавить агонию, уменьшая числитель и увеличивая знаменатель дроби, см. примеры в публичном рассуждении "Оберон -- серебряная пуля".
***
Вот три первые линии защиты программиста от ошибок, ни одна из которых не реализована в питоне (откуда атрибут "полное" при "говне"), причём не реализована принципиально, как сознательное проектное решение Гвидо ван Россума:
№0. Статическая типизация. Это когда каждая переменная имеет тип, приписанный ей программистом раз и навсегда (целое число, вещественное число, массив литер, ...). В идеале не просто строгая (как в производных Алгола-60 -- старом Паскале, Аде и т.п.), но и распространённая на динамические записи/объекты, как в Обероне a.k.a. Ультра Паскале (см. зелёненькую линию на знаменитой картинке). Типизация должна быть зашита в определение языка, и проверять типы должен компилятор на автомате по умолчанию.
Грамотные программеры (хотя бы прослушавшие с/к Наблюдателя) начинают каждую процедурку с батареи ассёртов для проверки типов всех используемых переменных. Понятно, что если в Обероне это делает компилятор, пока палец, нажавший соответствующую горячую клавишу, возвращается в исходное положение, -- то в питоне интерпретатор мучает эти проверки (до половины, сообщают, текста) при каждом вызове процедуры -- и всё равно программер оказывается в выигрыше, настолько важна строгая типизация.
№1. Инкапсуляция или упрятывание информации. Это когда у каждого программного объекта (не в смысле ООП, а вообще -- у переменной-константы-процедуры-...) есть некая естественная минимальная область видимости (часть программы, где этот объект определён, и т.п.), и доступ к нему извне этой области по умолчанию невозможен. Предоставление такого доступа ("экспорт") -- прерогатива проектировщика этой части программы, который может оценить соответствующие риски.
"Инкапсуляция в Python работает лишь на уровне соглашения между программистами" -- стыдливое словоблудие в попытке избежать позорного признания вслух, что её там нет. [ПРИМАТОЛ. ВОСКЛ.]
Как показывает опыт, оптимальная единица инкапсуляции (естественная локализация переменных в процедурах подразумевается) -- модуль в том простом и понятном как кирпич виде, в каком он реализован в Модуле-2 (a.k.a. Супер Паскаль) и Обероне (a.k.a. Ультра Паскаль). Многочисленные попытки обойтись чем-то другим ни разу добром не закончились -- всё равно приходится добавлять какие-нибудь namespaces, assemblies и проч. (ср. аж три таких эрзаца в C#) -- когда можно было с самого начала сделать нормальные модули и больше не париться.
№2. Надёжность компилятора/рантайма. Тут не одна сторона, но в главном дело сводится к точному минимализму языка. Вспоминаем Тони Хоара: "The price of reliability is the pursuit of the utmost simplicity" -- принцип, сознательно реализованный в Ford T, маленьком чёрном платье, АК-47, Обероне.
Ту же по сути идею можно переформулировать в виде фундаментального для любой конкурентной эволюции закона:
Принцип Калашникова
Избыточная сложность = уязвимость.
***
Миф о богатстве фич. Место этому богатству -- в библиотеках, а не в языке, где необязательные фичи подрывают надёжность и торпедируют эффективность. В язык их приходится запихивать, когда он так дурно спроектирован, что эффективно реализовать на нём это богатство не получается.
Золотой образец того, как богатый набор фич можно реализовать в библиотеках, если правильно выбрать минималистичный, тщательно спроектированный язык -- это компонентная библиотека (или framework = каркас) системы Блэкбокс -- популярного варианта Оберона. Эта библиотека послужила, напомним, базой для двух изданий международного бестселлера, доставившего его автору тёплое местечко в Майкрософт, см. фото в старой записи "А судьи кто".
Свежая "голая" версия системы Блэкбокс доступна здесь: https://wiki.oberon.org/blackbox
Новичкам лучше начинать с гуманизированной версии, зацепившей атомных программистов, доступной отсюда: http://www.inr.ac.ru/~info21/software.htm (грядёт большое обновление на основе свежей "голой" версии).
***
Миф о богатых библиотеках. Разные библиотеки с претензиями вынуждены реализовывать некоторые одинаковые базовые абстракции (всё в язык не запихнёшь, как бы ни хотелось). Но реализуют их немножко по-разному, что причиняет геморрой при совместном использовании. Касательно именно питона у нас есть свежее свидетельство из окопов от лидера небольшой команды разработчиков.
За этим прячется фундаментальная причина: чем сложнее объекты, тем больше у них разнообразия в деталях (ср. ос, которые как штампованные, против человеков, каждый из которых уникален).
Никакой дизайнер "богатой библиотеки" не может предусмотреть [>> Невообразимое] все особые случаи её применения. От попыток всё угадать -- тыщи параметров и настроек, неизбежная ненадёжность реализации -- и многоплановый геморрой при использовании.
В реальности нередко выгодней [Upd и даже нужно no matter what] отказаться от "богатой библиотеки" в пользу собственного относительно простого решения, точно сделанного под конкретный класс задач и полностью контролируемого (есть свидетельство того же лидера; но сам феномен известен давным-давно в контексте разных языков и отражён, например, в алгебраическом движке от Наблюдателя, не раз доказавшем эффективность такого подхода, см. пример в списке №3 и новый прорыв).
***
Тот факт, что Гвидо ван Россум является Dijkstra Fellow, -- оскорбление памяти Эдсгера Дейкстры, великого поборника дисциплины программирования. Причина награждения -- сугубо приматическая: они оба голландцы, а Голландия -- страна маленькая.
Слава Турбулентному, автору питона ни при какой погоде не светит тьюринг -- во всяком случае не за питон, а больше и не за что.
Upd Справедливости ради надо сказать, что у Гвидо, похоже, особых претензий никогда и не было -- пузырь раздулся резонансным образом на фоне фактического провала С++.
В силу шквального интереса запись подвергнута вылизыванию + добавлены ссылки.
[мегапузырь_IT] начало и оглавление
Просьба пришла в комменте. Придётся немного отвлечься -- по той же причине, по которой Наблюдатель ломается с другим, благотворительным проектом, включая спецкурс, бывшие слушатели которого стали возвращаться с поддержкой.
Тема дико важна (все эти "умные дома" и прочие беспилотники в воздухе, на земле и под водой, на простых батарейках и на ядерных, с пассажирами и с боеголовками ...), но затоплена мракобесием по самое буквально не могу под руководством контуперных идиотов.
Пишется экспромтом, поэтому какие-то пунктики могут быть забыты [Upd см. комменты]. Но главное сидит в печёнках.
***
Просьба пришла в ответ на констатацию, что язык программирования питон -- это полное говно.
Не случайно именно там -- именно языки программирования служат главной темой религиозных войн в сфере цифры. Для этого в приматическом мозге есть причины, о которых нужно говорить отдельно.
Оговорка. Языки программирования имеют аспект группового феномена, поэтому это говно кому-то приходится жрать за компанию, трофики ради-для. Тут ничего не поделаешь.
Но сей трофический аспект в иных случаях служит основанием для глубокомысленного вывода, что говно питон всё-таки не полное. -- А вот это уже дело вкуса. Потому что субъективное и даже попъективное восприятие говна не может отменить его объективную природу.
***
Первое и самое главное:
Говном является любой язык программирования, дизайн которого не предусматривал в числе приоритетов полноценную защиту программиста от ошибок.
Этот тезис раскрывается только с болезненным опытом пресловутой агонии отладки в процессе естественной эволюции программ (а программы на удивление живучи и растут как раковая опухоль). Разработка программы -- это частный случай такой эволюции.
Агония измеряется метафорической дробью, в числителе которой стоит количество разных фич языка (т. наз. "выразительная мощь"), причём в квадрате (потому что проблемы порождаются взаимодействием фич), а в знаменателе -- степень защиты, которую язык обеспечивает. О том, насколько сильно можно подавить агонию, уменьшая числитель и увеличивая знаменатель дроби, см. примеры в публичном рассуждении "Оберон -- серебряная пуля".
***
Вот три первые линии защиты программиста от ошибок, ни одна из которых не реализована в питоне (откуда атрибут "полное" при "говне"), причём не реализована принципиально, как сознательное проектное решение Гвидо ван Россума:
№0. Статическая типизация. Это когда каждая переменная имеет тип, приписанный ей программистом раз и навсегда (целое число, вещественное число, массив литер, ...). В идеале не просто строгая (как в производных Алгола-60 -- старом Паскале, Аде и т.п.), но и распространённая на динамические записи/объекты, как в Обероне a.k.a. Ультра Паскале (см. зелёненькую линию на знаменитой картинке). Типизация должна быть зашита в определение языка, и проверять типы должен компилятор на автомате по умолчанию.
Грамотные программеры (хотя бы прослушавшие с/к Наблюдателя) начинают каждую процедурку с батареи ассёртов для проверки типов всех используемых переменных. Понятно, что если в Обероне это делает компилятор, пока палец, нажавший соответствующую горячую клавишу, возвращается в исходное положение, -- то в питоне интерпретатор мучает эти проверки (до половины, сообщают, текста) при каждом вызове процедуры -- и всё равно программер оказывается в выигрыше, настолько важна строгая типизация.
№1. Инкапсуляция или упрятывание информации. Это когда у каждого программного объекта (не в смысле ООП, а вообще -- у переменной-константы-процедуры-...) есть некая естественная минимальная область видимости (часть программы, где этот объект определён, и т.п.), и доступ к нему извне этой области по умолчанию невозможен. Предоставление такого доступа ("экспорт") -- прерогатива проектировщика этой части программы, который может оценить соответствующие риски.
"Инкапсуляция в Python работает лишь на уровне соглашения между программистами" -- стыдливое словоблудие в попытке избежать позорного признания вслух, что её там нет. [ПРИМАТОЛ. ВОСКЛ.]
Как показывает опыт, оптимальная единица инкапсуляции (естественная локализация переменных в процедурах подразумевается) -- модуль в том простом и понятном как кирпич виде, в каком он реализован в Модуле-2 (a.k.a. Супер Паскаль) и Обероне (a.k.a. Ультра Паскаль). Многочисленные попытки обойтись чем-то другим ни разу добром не закончились -- всё равно приходится добавлять какие-нибудь namespaces, assemblies и проч. (ср. аж три таких эрзаца в C#) -- когда можно было с самого начала сделать нормальные модули и больше не париться.
№2. Надёжность компилятора/рантайма. Тут не одна сторона, но в главном дело сводится к точному минимализму языка. Вспоминаем Тони Хоара: "The price of reliability is the pursuit of the utmost simplicity" -- принцип, сознательно реализованный в Ford T, маленьком чёрном платье, АК-47, Обероне.
Ту же по сути идею можно переформулировать в виде фундаментального для любой конкурентной эволюции закона:
Принцип Калашникова
Избыточная сложность = уязвимость.
***
Миф о богатстве фич. Место этому богатству -- в библиотеках, а не в языке, где необязательные фичи подрывают надёжность и торпедируют эффективность. В язык их приходится запихивать, когда он так дурно спроектирован, что эффективно реализовать на нём это богатство не получается.
Золотой образец того, как богатый набор фич можно реализовать в библиотеках, если правильно выбрать минималистичный, тщательно спроектированный язык -- это компонентная библиотека (или framework = каркас) системы Блэкбокс -- популярного варианта Оберона. Эта библиотека послужила, напомним, базой для двух изданий международного бестселлера, доставившего его автору тёплое местечко в Майкрософт, см. фото в старой записи "А судьи кто".
Свежая "голая" версия системы Блэкбокс доступна здесь: https://wiki.oberon.org/blackbox
Новичкам лучше начинать с гуманизированной версии, зацепившей атомных программистов, доступной отсюда: http://www.inr.ac.ru/~info21/software.htm (грядёт большое обновление на основе свежей "голой" версии).
***
Миф о богатых библиотеках. Разные библиотеки с претензиями вынуждены реализовывать некоторые одинаковые базовые абстракции (всё в язык не запихнёшь, как бы ни хотелось). Но реализуют их немножко по-разному, что причиняет геморрой при совместном использовании. Касательно именно питона у нас есть свежее свидетельство из окопов от лидера небольшой команды разработчиков.
За этим прячется фундаментальная причина: чем сложнее объекты, тем больше у них разнообразия в деталях (ср. ос, которые как штампованные, против человеков, каждый из которых уникален).
Никакой дизайнер "богатой библиотеки" не может предусмотреть [>> Невообразимое] все особые случаи её применения. От попыток всё угадать -- тыщи параметров и настроек, неизбежная ненадёжность реализации -- и многоплановый геморрой при использовании.
В реальности нередко выгодней [Upd и даже нужно no matter what] отказаться от "богатой библиотеки" в пользу собственного относительно простого решения, точно сделанного под конкретный класс задач и полностью контролируемого (есть свидетельство того же лидера; но сам феномен известен давным-давно в контексте разных языков и отражён, например, в алгебраическом движке от Наблюдателя, не раз доказавшем эффективность такого подхода, см. пример в списке №3 и новый прорыв).
***
Тот факт, что Гвидо ван Россум является Dijkstra Fellow, -- оскорбление памяти Эдсгера Дейкстры, великого поборника дисциплины программирования. Причина награждения -- сугубо приматическая: они оба голландцы, а Голландия -- страна маленькая.
Слава Турбулентному, автору питона ни при какой погоде не светит тьюринг -- во всяком случае не за питон, а больше и не за что.
Upd Справедливости ради надо сказать, что у Гвидо, похоже, особых претензий никогда и не было -- пузырь раздулся резонансным образом на фоне фактического провала С++.