LINUX.ORG.RU
ФорумTalks

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

 , ,


1

3

Столяров (@Croco) трудился в университете, как полагается, вел несколько курсов лекций. Все преподаватели ведут несколько смежных курсов, но в отличие от большинства, Столяров выкладывал свои методички в публичный доступ. В 2016 году за деньги с донатов он взял материал этих курсов, расширил его беседами с лекций и практик и все это опубликовал. В итоге получился обыкновенный курс программирования любого, подчеркиваю, любого профильного вуза страны.

Что важно, этот курс стал бесплатно доступен любому желающему в два клика, без необходимости проходить бюрократический фильтр и платить цену автомобиля за доступ к информации. Благодаря работе Столярова любой заинтересованный человек получает качественно отредактированный конспект лекций МГУ по программированию с пояснениями. По содержанию это +/- 1999 или 2000 год.

Абсолютно ничего нового, революционного, свежего Столяров не написал. К моменту публикации (2016 год) по темам, затронутым Столяровым, было опубликовано десятки книг, которые пережили множество изданий. Например, книги по TCP/IP от издательства O’Reilly к тому времени издавались уже 20 лет и имели по 7-8 улучшенных и дополненных изданий.

Мало того, что Столяров опубликовал прописные истины администрирования и программирования, он еще их щедро разбавил философией лаборанта из 90-х. То есть технические книги стали содержать в себе конспекты типовых разговоров второкурсников за бутылкой водки. Что, конечно, добавило живости в чтиво, но дурно влияет на 17-летних подростков, которые пьяный трёп обслуживающего персонала воспринимают за жизненную философию и руководство к действию.

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

Но как разработчик, как автор, он не сделал ничего нового. И сам по себе является карикатурным образом админа 90-х, про которых писали юмористические рассказы в Fido. Попытка доказать всему честному люду, какой он великий инженер, через постройку велосипеда, развалившегося на первой кочке, — это типичный пример творчества тех лет. Рассказов про Винипуха и боды и записок Жены программиста.

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

Вывод: Столяров — это классический, можно сказать, эталонный системный администратор из 90-х. Человек, который отказался развиваться, отринул курсы повышения квалификации и навсегда остался в сладком возрасте 20 лет в рамках того давно ушедшего социума, его стереотипов и правил.

Книги Столярова — это книги 90-х, хотя они написаны через четверть века, в конце 2010-х. Это памятник эпохи начала массовой компьютеризации в России. Это надо понимать при работе с ними. Читая работы Столярова, надо давать «поправку на ветер», и всё будет хорошо.

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

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

Ответ на: комментарий от sabacs

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

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

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

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

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

lbvf50txt
() автор топика
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от lbvf50txt

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

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

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

sabacs
()
Ответ на: комментарий от lbvf50txt

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

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

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

qulinxao3 ★★
()
Последнее исправление: qulinxao3 (всего исправлений: 1)
Ответ на: комментарий от praseodim

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

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

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

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

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

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от sabacs

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

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

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

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

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

Наследование помогает бороться с Single Responsibility, что может трактваться как максимальная степерь Strongly Сoupling. Формально вы правы.

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


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

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

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

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

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

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

lbvf50txt
() автор топика
Последнее исправление: lbvf50txt (всего исправлений: 3)

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

lbvf50txt
() автор топика
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)