Программирование это искусство взаимодействия. Взаимодействия программы с с ее окружением и взаимодействие программиста с его окружением. У этого взаимодействия сложилась определенная культура которую описывает данная книга.
Что касается аналогий и центральной идеи, то я категорически против такого подхода. Он удобен для автора, но опасен тем что провоцирует заметать под ковер вещи, не укладывающиеся в рамки исходной идеи. Программирование, как и любая другая практическая дисциплина, само по себе huge mess его нельзя утоптать в рамки одной стройной концепции.
Также я категорически против исторического подхода к изложению. Это вносит в голову студента путаницу и невозможность ответить на вопрос: а что из этого актуально прямо сейчас. Примерно как если начинать курс "Компьютерные сети" с рассказа о модели OSI. В результате студент искренне уверен что OSI это физически существующая величина, или, в лучшем случае стандарт, а вовсе не искусственная абстракция.
Поскольку книга для программистов, подход к изложению должен быть инженерно-программистский: постановка задачи - решение.
Есть конкретные каналы передачи информации от пользователя к программе и от программы к пользователю. Как сделать интерфейс в зависимости от того какую информацию в какую сторону нужно передавать? Какими свойствами этот интерфейс должен обладать? Что делать если какой-то из каналов информации недоступен?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
branchandroot
Re: You need a main logical thread
Date: 2015-01-27 05:56 pm (UTC)Программирование это искусство взаимодействия. Взаимодействия программы с с ее окружением и взаимодействие программиста с его окружением. У этого взаимодействия сложилась определенная культура которую описывает данная книга.
Что касается аналогий и центральной идеи, то я категорически против такого подхода. Он удобен для автора, но опасен тем что провоцирует заметать под ковер вещи, не укладывающиеся в рамки исходной идеи. Программирование, как и любая другая практическая дисциплина, само по себе huge mess его нельзя утоптать в рамки одной стройной концепции.
Также я категорически против исторического подхода к изложению. Это вносит в голову студента путаницу и невозможность ответить на вопрос: а что из этого актуально прямо сейчас. Примерно как если начинать курс "Компьютерные сети" с рассказа о модели OSI. В результате студент искренне уверен что OSI это физически существующая величина, или, в лучшем случае стандарт, а вовсе не искусственная абстракция.
Поскольку книга для программистов, подход к изложению должен быть инженерно-программистский: постановка задачи - решение.
Есть конкретные каналы передачи информации от пользователя к программе и от программы к пользователю. Как сделать интерфейс в зависимости от того какую информацию в какую сторону нужно передавать? Какими свойствами этот интерфейс должен обладать? Что делать если какой-то из каналов информации недоступен?