Рецензия на книги А. В. Столярова

Наследование приводит к сильной связности в итоге.

Как раз наоборот. Наследование используется для борьбы с связанностью. «Extend, not modify» в S.O.L.I.D. концепции.

Это не так. См. «проблема хрупкого базового класса».

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

Принцип открытости/закрытости (Open/Closed Principle) — это часть SOLID, которая как раз связана с наследованием. Правильное использование наследования — это способ преодолеть связанность и создать такую структуру программы, части которой можно чинить или изменять изолированно.

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

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

Наследование не помогает бороться со связностью, а наоборот порождает её. И не надо ссылаться на ООП, сами авторы открещиваются от наследования и говорят что их просто неправильно поняли. :)

https://en.wikipedia.org/wiki/Fragile_base_class

vs

https://ru.wikipedia.org/wiki/Хрупкий_базовый_класс#:~:text=Проблема%20хрупко...

разница в языкосферах

вопрос в уровнях абстракций и их протечках

расширяемые АТД(абс тип дан) годный инструмент управления сложностью проблемной области

проблема в том что людь не могущие в алгебру лепят свои графы наследований с закономерным дефектом между рулём и сиденьем

Да нет никакой разницы. Это известная проблема.

ну нет и нет

спектр ваще из 2

Выражайтесь яснее.

куда уж

учебные материалы придется переписывать каждые пару лет, чтобы программы посложнее Hello world запускались без ошибок.

Неправда. У меня очень большой проект на питоне, и питон обновляется вместе с арчом. И даже с учетом того, что я использую местами всякие трюки и дерганье «приватных» атрибутов, мне лишь пару раз приходилось вносить мелкие изменения в код за 8 лет. Крупные изменения были только когда asyncio обновили, кажется, изменив поведение create_task(). Последний релиз был вообще без изменений.

И это, повторюсь, сложный боевой код с кучей тонкостей.

А учебные упражнения будут связаны в основном с алгоритмами и стандартной библиотекой, причем без залезания в ее дебри (как я, которому надо было сделать xmlrpc по unix-сокету). Так что вы вообще не дойдете до активно развивающихся частей и учебные пособия трогать не придется. Будем честными, до asyncio вы тоже не дойдете. А если дойдете - то далеко не в первый год, и там студенту уже будет пора самому читать документацию к языкам и быть самостоятельным.

Меня реально задрало, что вот надыбаешь какой пример чего-то на питоне и чем он старше, тем больше приколов

Скорее всего ты ищешь примеры в какой-то узкой области. С учебными это никак не связано.

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

Правильное использование наследования это как правильное использование goto.

Правильное использование goto тривиально: выход из 2-х и более вложенных циклов.

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

Тут я с вами соглашаюсь. Вот по этому классов и наследования нет в Golang.

Наследование не помогает бороться со связностью, а наоборот порождает её.

Формально да. По сути нет. Связность (coupling) это когда один объект «знает» о способе функционирования другого объекта. Страница 37: Coupling Between Objects (CBO); POODR (c) Sandi Metz.

Наследование помогает достичь Single Responsibility, бороться с Multiple Responsibility, что может трактоваться как максимальная степень Strongly Coupling. Multiple Responsibility — это Strongly Coupling. Все связано в одном месте.

Дело не в связности (coupling) как таковой, а в её степени: loosely/strongly coupled. Хотя в разговорной речи связность часто понимается в негативном ключе как strongly coupled code.

Листал POODR, гуглил лекции, не хочется стирать. По существу, все верно, но можно начать придираться к терминологии: где Single Responsibility, а где Open/Closed Principle.

Связность (сoupling) и связи (connections) это разные термины, сильно созвучные в русском языке.

Вот мое объяснение, принципа Open/Close в SOLID, и то как он помогает избежать cвязность (coupling) через наследование.

• «Связность» (coupling) — это не возможность вносить изменения в одну часть программы, не задев другую. Связность порождает хрупкость (fragile): начали менять формат хранения данных с XML на JSON — поломалось подключение к базе данных. Части системы не изолированы друг от друга.

• Механизм наследования позволяет изолировать новый слой абстракции. Новый слой абстракции изолирован от предыдущего. Отнаследовали записывать в базу данных, в наследнике XML меняете на JSON, JSON на YAML, YAML на TOML — подключение к базе данных не поломается. Также вы меняете тип сервера в базовом классе, это никак не влияет на формат хранения. Произошло разделение (decoupling): формат хранения отделен от подключения. Связность (coupling) уменшилась.

Убрать связность (coupling) не значит убрать связи (connections); убрать связность значит добавить возможность изменять одну часть программы, не затрагивая другую. Хотя части зависят друг от друга и имеют иерархию.

• GORUCO 2009 - SOLID Object-Oriented Design by Sandi Metz
• RubyConf 2009 - SOLID Ruby by: Jim Weirich

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

Мои мысли на этот счет тоже не из воздуха взяты. Позволь объяснить. Я считаю, что обучение инженера очень похоже на формирование плода в утробе матери. Чтобы получился человек, зародыш проходит все стадии предшествующей эволюции - сначала это червячок, потом головастик, рыбка, ящерка и только потом получается млекопитающее. Инженер в своей отрасли тоже должен начинать с основ и проследить всю историю развития - как зародилась идея условного аппарата тяжелее воздуха, как сначала пытались копировать птиц, как пришли к идее самолета, и какие ошибки при этом совершали. Именно так итеративно и только так имеет смысл вводить человека в профессию, в любую профессию если это не тупой механический труд. И мне кажется, что именно такой подход и применяют везде в мире. Никто не дает первокурснику чертежи боинга и никто не начинает сразу с трехкоординатного станка с ЧПУ.

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

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

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

А вот фиг. Не работает это так. Молодой человек Иванов Вася, прочитав Марка Лутца, посмотрев ютуб и порешав задачек идет устраиваться джуниором. Там ему задали вопросы про цикл фор и дали тестовое задание на физ-баз, каковое он блистательно решил. И вот Вася с новым ноутбуком первый день в команде, готовый писать циклы фор и манипулировать списками. И тут у Васи рвется шаблон, потому что помимо циклов и списков есть еще какой-то гит, какие-то пулл-реквесты, какой-то дженкинс, какой-то линукс и какие-то базы данных и со всем этим добром ему надо коммуницировать. Да что там линукс, выйдите на улицу и спросите у рандомного прохожего, знает ли он, что такое XML и JSON. Вот и Вася не знал, и еще кучу всякой терминологии, которой опытные айтишники используют не задумываясь. И Васе будет вообще не до аллокации памяти на куче, следующие несколько лет ему предстоит забивать себе голову разнообразным тулингом, а так же всяким менеджерским дерьмом - скрамами и спринтами, которые ничего общего не имеют ни с циклом фор ни с Васеными романтическими представлениями о работе разработчика.

Два-три года спустя Вася почувствовав себя мидлом меняет работу. Вася уже не такой наивный юнош, он заматерел и может даже запрос на SQL написать. В глазах друзей Вася обосраться хакер, к нему идут за советом и он агитирует всех переходить на линукс, называет виндоуз мастдаем и хочет изучить хаскель как-нибудь потом, когда время будет. Программирование для Васи превращается в рутину, оно теряет ореол загадочности, становясь просто кормушкой. Вася больше не мальчик, он взрослый дяденька со взрослыми проблемами - у него ипотека, кредит, ребенок, детский сад, пудель, больная теща, похмелье. И Вася больше не хочет учиться. У него самая большая из всех друзей зарплата, он хорошо справляется со своей работой, он на хорошем счету у менеджера. Вася даже не знает, что у него есть существенные пробелы в знаниях, вернее он догадывается, но ему и так норм, а вечером лучше пивка хряпнуть, чем книгу нудную читать. Через три года Вася выгорел и спился и пошел в манагеры.

Точно подмечено.

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

Точно.

Попрограммировав на Си, уже рулады о том какой плохой Go эффекта не возымеют.

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

Точно.

И Вася больше не может учиться. Восемь часов циклов for в день, и общение с менеджерами забирает все силы.

Переход за рамки фреймворка, который рано или поздно происходит, выбивает программиста без академической базы из седла.

Поэтому, при всех минусах и оговорках многократно мной озвученных, я хорошо отношусь к Столярову. Его книги, ой как, не лишние в начале становления.

P.S. Есть два полюса: только «фреймворк» или только «Столяров». И то, и другое, как любая крайность, плохо. Оптимально комбинировать современные технологии и академическую базу.

Казалось бы при чем тут питон. А при том, что у питона слишком много магии под капотом. Эта магия скрыта и её нельзя увидеть и пощупать, можно только использовать даже не зная, что это магия.

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

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

Дальше, когда студенты научатся переносить свои мысли в код, можно начинать углублять знания питона. Здесь вся подкапотная магия пойдет только на пользу, потому что на примере питоновских типов и структур можно объяснять проектирование и решение задач на высоком уровне. И вот где-то в этом моменте надо изучать уже си, причем в связке с питоном, где будет очень удобно проводить параллели между этими языками и показывать, как всё работает на низком уровне.

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

Так что да, питон - лучший выбор для обучения программированию.

Мне интересно, почему ставится вопрос «или/или». На самом деле, было бы лучше изучать и Python, и C. В чем, собственно, проблема изучать сразу два языка?

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

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

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

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

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

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

Питон достаточно высокоуровневый, чтобы учить на нем принципы проектирования софта, не закопавшись в детали.

вот лутЦА не трож!

его книга(а у него одна книга как опубликовал в 96 так и уточняет - текущее уточнение ~4к страниц) Programming Python - именно и был «2 текст»(первый это доки) и предназначен для людей могущих(уже в программирование) оно было как раз для прикладного ( как последующий Чан; Самерфилд и прочая прочая)

эт просто изучаем питон(не Метиза но Лутца) - которое вот такое вот удленнённое предисловие к основному жиру(оно и вывалилось в отдельные тома из приложение Е первого programming python) - оно скорее не для новичков в программировании а новичков в питоне которым охота питон со всеми закаулками

Лутц крут и он не для обучения программированию (забавно что библиография только в первом издании )

но какова его роль в обучении программированию в данном случае, если практически всему тому же самому можно научить и на Си, раз уж студент всё равно его учит?

Например, для изучения «Алгоритмов и Структур Данных» Python — это реализация псевдокода.

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

что бы не закатывать солнце вручную

питон он клей - если нужны спиды то import чужое если спиды домотканные то import своёСишное

эмулировать приоритетную очередь проще в пупоне

как и вообще всякую aplщину import numpy as np и вперде

см Курячего

пользуемся через открытый интерфейс в питоне

а реализация если нуна(ну вот нуна) на Ся

классическое Элойский/Морлокский тандем

если накуривать студентов то plan9 али чё из современного - общераспространённые юникса на большую часть из «тут так принято» это пту

Вообще, я не вижу никакой проблемы в изучении Python как первого языка, С как первого языка, JavaScript как первого языка, Java, C#, Perl, Ruby, Go, Groovy, Kotlin, Dart, Swift и так далее. Или в изучении нескольких языков сразу.

Споры о том, какой первый язык выбрать — это просто приятные беседы. Было бы желание. Любой современный язык подойдет, есть литература, курсы, сайты с задачами. Не принципиально.

первый язык это асм даже учебный - именно туда сюда наборы битов представление об указателе команд и стеке возвратов(и даже аргументов) желательно тоже через указател стеков регистр

нуль одно двух трёх адрессные команды

а потом да любой «hhl»

представление( не столько знание сколько вот есть команды они меняют состояние памяти и проца(что бы состояние проца не значило)) оно фундаментально

зы/ всякая асинхронщина конкурентность паралельность прикручивается через сочетание распределэнности по пространству(сети) и многоядерпоточности как развития модели императивного проца

если у людей нет представления о битах и законах де Моргана - ну не всем нужно быть образованными

Не нужен никому план9, он за пределами академа нигде не встречается. Я бы взял линуксы и тройку Free/Open/NetBSD для понимания разницы.