Получил ещё одну отличную книгу. Поскольку название ветки в данном случае информативное -
понятно, какую.

Ну что ж, посмотрим, какие здесь банальности - вне специфического эйффелевского изложения, только то, что существенно для меня как "предметника":
Вложение:
Ну, прежде всего, можно сказать, что книга в целом м.б. трактована как "система вводных курсов" в определении Info21 для АиСД-Оберон. Правда, с позиции автора - которая отличается от Виртовой. Можно даже рассматривать её как "паттерн проектирования" такой системы. Хотя мне на сегодня концепция "книг ядра" Потопахина кажется более интересной и обещающей. А что-то учесть всегда можно.
Первое, что важно - рассматривается "индустрия чистых идей" (примерно в том же ключе, как определяет программирование Илья - математика, отображённая на "материальное средство", т.е. исполнителя). А не "чисто индустрия идей, канкретно" - как имеет место в "мэйнстриме"

. Это поддержано и приложениями, анализирующими прогязыки.
Правда, автор не порывает с "избыточной сложностью", объясняя это тем, что придётся в большинстве случаев программировать на "модных" языках. И старается "равноудалиться" от полностью формального и "чисто наивного" подходов к первоначальному ИТ-обучению. Вероятно, специалистам в М-И-Я судить, не превращается ли это в "служение и Богу, и мамоне". Мне же подход к постепенному введению формального анализа программ через контракты кажется возможным.
Прежде всего потому, что контракты рассматриваются как база для математизации качественного описания задачи. А затем - для информатизации математического. Т.е. через них постепенно устрожается язык представления предметки.
Языковой аспект хорош и связью с ЕЯ. И проведением линии на спецификацию (контрактную) как источник содержания программы. Только недавно сказал:
...
Язык с жёсткой грамматикой необходим в информатизации, где мы должны снять неопределённость предметки (шире - живой жизни вообще). А язык со свободным построением предложений - для непосредственного отражения живой жизни (т.е. на качественном уровне).
...
- и пожалуйста, то же самое можно видеть в "формальном описателе предисловий" на с. 20...

Конечно, специалистам судить, получается ли через контракты доказательность для объектной парадигмы.
Знание автором русской культуры ощущается в тексте.

Так, сказанное о педагогических подходах на с. 37 имеет непосредственный аналог в известном анекдоте про то, чем отличается командир от замполита...

Любопытно и замечание А. Перлиса на с. 40. Перекликается как с гипотезой Уорфа, так и с теорией умотипов (в аспекте, обсуждавшемся
здесь, прежде всего).
Мощная среда разработки как инструмент и объект освоения - тоже существенно. В этом смысле ББ, конечно, вряд ли уступает - там вместо классов процедуры с докусами. Вот объяснение их употребления по ходу книги - то, что нужно делать, как здесь.
В отношении общего педагогического подхода автора. Возможно, следует учесть выводы методологов о том, что освоение деятельности протекает иначе, чем через задание этой деятельности как содержания обучения. См. /Педагогика и логика, Щедровицкий, Гл. VI/.
Важен и выбор предметки для освоения. То, что у Мейера предложено управление движением, перекликается со сказанным в своё время здесь:
Во-вторых, есть и чисто практические точки соприкосновения, не замыкающиеся на мышлении отдельных личностей. С одной стороны, профессионализация движения требует более эффективной диспетчеризации - и здесь важны как математические методы, так и автоинфорсимы хотя бы для поддержки интуитивной организации движения - но системы гарантоспособные, т.е. созданные по тем технологиям, которые поддерживаются и на данной конференции.
Отметим, что прежде всего такая система должна дистанционно предлагать пользователям данные о наличных ресурсах движения (занятости парковок, проезжих частей между предполагаемыми пунктами следования, вариантах маршрутов и ориентировочном времени их прохождения, включая общественный транспорт - как маршрутный, так и легковое/грузовое такси). Дело в том, что централизованно можно организовывать движение лишь маршрутного транспорта - остальной можно только ограничивать. По сути речь идёт о формировании рынка ресурсов инфраструктуры движения в части, нераспределённой маршрутному транспорту - а для грамотного поведения на любом рынке его участникам нужна именно информация.
С другой стороны - участники профессионального движения (включая заказчиков транспортных услуг) в массе своей должны с младых ногтей привыкнуть рассматривать своё движение "из пункта А в пункт Б" по густонаселённым/плотнозастроенным территориям как "совместно протекающий взаимодействующий процесс" с инициируемыми другими такими же участниками. И планировать такие перемещения в условиях ограниченных пространственных ресурсов, а не требовать "луну с неба". И вот в этом должна помочь информатика - уже в школе предлагая моделировать движение и оптимизировать его по времени. Дисциплина нужна не только в програмировании - и не только в нём её нужно воспитывать В общем-то разновидность того же самого "моделирования как второй грамотности"... и параллельно вместо экстремизации предлагает стиль, основанный на кооперации...
Считаю, именно такая вещь д.б. предложена в рамках ББ.
Кстати, и проведение границы между "любителями" и "профессионалами" также перекликается с этим: Можно вспомнить опыт профессионалов других предметок - так, мастеровые цеха (в наших терминах - "саморегулируемые организации по видам деятельности" )) в прежние времена сами аттестовали участников своей деятельности, причём категорируя - скажем, портновские могли выдавать свидетельства обычные и "портной без права шить пиджаки"...
Как видно, автор взаимодействовал с нашими профессионалами в гарантоспособном программировании - Тереховым, Шалыто. Что неудивительно, учитывая общность понимания. Вместе с тем текущая позиция "автоматчиков" в отношении парадигм программирования (которую можно считать манифестированной в /
Поликарпова, Шалыто, 2010/) близка скорее не объектному, а компонентному подходу.
Вместе с тем, "
Программирование, задача конструирования новых программ или улучшения существующих,..." (с. 22) наводит на мысль о рефакторинге.
О соотношении программ и систем уже говорилось на форуме. Поэтому
"... мы называем наши машины программами или системами." (с. 51) не кажется корректным. Система - это программа, существующая (в виде кода) на исполнителе, не так ли? В этом смысле тезис Вирта (расширенный) как раз плодотворен.
Также по терминам "информация" и "данные" - Мейер проводит подход Фридланда, но непоследовательно (ср. соотв. пункт с /
Фридланд, 2005/).
Из математики важно также не упустить того, что лишь намечено высказыванием: "
Для математика сложение - вещь более тонкая, чем для счетовода." (с. 23). Конечно, я опять в первую очередь о
Математике-2...
Потому что "
Когда фирма "Аэробус" пригласит вас написать управляющее ПО для их следующего лайнера, учиться будет слишком поздно." (с. 27) не только тому, как правильно разработать ПО - но и как математически учесть влияние "наших машин (информатических - прежде всего дискретных, конечно

)" на корректность математического решения, положенного в основу программной части информатической системы.
Что сам "Аэробус" и продемонстрировал на примерах, описанных в /Петров, 2008, §23/.
Виден определённый когнитивный стиль в оформлении (примеров прежде всего). Удачны также материально-информатические аналогии для объяснения объектов в Гл.2. Наверное, возможны такие же для компонентной парадигмы.
Итог. Можно сказать, что Мейер сделал комплексную формализацию своего подхода к ИТ и её преподаванию. Чего до конца не стал делать Вирт (в силу, очевидно, важных соображений). Но вполне могут сделать его последователи. Возможно, уже сделали за рубежом для Оберона. Но важно это реализовать на отечественной почве. И в этом смысле работа и планы Виталия Валерьевича значимы. К книге стоит относиться спокойно - как к образцу отчуждения знаний. И источнику идей по формализации методологии, базирующейся на КП/ББ.
Правильно также поддерживать книгу веб-ресурсом. Надеюсь, для "книг КП/ББ-ядра" это также будет реализовано... Скажем, как вики в ОберонКоре. Формат ветки или форума хотя и возможен, но имеет ограничения.