Улучшение учебника

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

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

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

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

Во-вторых, однообразие утомляет. Когда в десятый раз перечитываешь и редактируешь одну и ту же локацию, поневоле начинаешь сбиваться и делать ошибки. Для редактирования существующего кода нужно быть более внимательным, чтобы ничего не упустить и изменить только то что нужно и там где нужно. Это в свою очередь делает изучение более сложным. Если писать “с нуля”, один раз прочитал - понял - записал - выполнил. Легко и просто.

В-третьих, легче найти ошибку, когда весь код написан в пределах одного урока. Представь, если пример третьего урока не будет работать, потому что автор не заметил ошибку, допущенную при выполнении первого урока. Легко ли будет разобраться, человеку впервые попробовавшему QSP? А в одном уроке - можно пройтись по уроку, свериться с кодом. В крайнем случае, если непонятно, где ошибка, начать урок заново, создав новую игру.

2. Учебник излишне длинный. Стоит его сократить (не в ущерб полезной информации). Но при реализации первого пункта это может уже не понадобится.

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

В качестве одного из приёмов используются повторы: общее объяснение, за которым следует подробное. Также используются иллюстрации - немного различающиеся варианты каких-то общих решений. Каждый урок рассматривается с разных сторон для лучшего понимания и закрепления: что мы делаем, как делаем, что должно в итоге получиться, чему это нас научило. Все пошаговые указания даются подробно, чтобы исключить двусмысленную трактовку.

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

3. Учебник требует выполнять ВСЕ примеры, даже элементарные - помоему это неправильно, но примеры посложнее действительно полезно делать.

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

Что касается более сложных примеров. Во-первых, по моему твёрдому убеждению, для написания хорошей текстовой игры вовсе не требуется сложный код. Во-вторых, это противоречит цели учебника. Учебник даёт необходимый минимум знаний, даёт стартовую, отправную точку для написания первых игр. Главный приоритет - чтобы автор мог начать делать свои игры как можно быстрее, пока у него не пропал интерес. Если углубляться в сложные примеры, легко отбить охоту к изучению QSP. Энтузиазм - ресурс ограниченный, следует расходовать его разумно. Большая его часть должна уйти на самостоятельное создание игр, а не на штудирование учебника.

Для интересующихся более глубоким изучением QSP, можно создать продвинутый учебный курс. Но только отдельно. Объём учебника должен быть минимальным.

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

Во-первых, абстрактные примеры скучны. Скучный учебник тяжело читать. А мне хочется, чтобы учебник читался как можно легче.

Во-вторых, реальные игры понятнее и лучше запоминаются.

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

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

5. Учебник планируется встроить в справку, поэтому он будет ссылаться на другие статьи. Я считаю, что если полная статья проста и понятна, то можно сделать на неё ссылку и не переписывать в учебнике.

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

Более того, объяснение общих понятий разными способами(в справке и в учебнике) будет способствовать более полному пониманию предмета.

Пожалуй мне стоило пораньше зайти.
1)

Nex:

Во-первых, действия по созданию новой игры, сохранению её, тоже нужно отрабатывать.

Эти действия так примитивны, что их не нужно отрабатывать и они на самом деле на так уж и часты, что бы даже требовать их практического закрепления: создание новой игры, сохранение, создание локации - всё это можно отработать между делом не заостряя внимание.

Nex:

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

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

Nex:

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

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

2)
С самого начала этот пункт был плохо обоснован, т.к. учебник не то что бы кишит лишними повторами а просто местами сильно излишне затянут, ну и пункт 1 тут играет весьма важную роль - учитывая это, пока даже не вижу необходимости перечитывать учебник и искать “плохие” места - может в следующий раз.

3)
Я это упомянул тут в первом пункте: под лёгкими я имел в виду такие дейтсвия как создание нового проекта, сохранение и тому подобное. А сложное - всё остальное.

4)

Nex:

Во-первых, абстрактные примеры скучны. Скучный учебник тяжело читать. А мне хочется, чтобы учебник читался как можно легче.

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

Nex:

Про неизвестные операторы. Например, в четвёртом уроке упоминается функция INPUT. Даётся очень упрощённое описание её использования, она не рассматривается подробно. Это сделано потому, что целью урока является изучение переменных. Внимание должно быть сконцентрировано именно на переменных. Подробное изучение INPUT в рамках этого урока, или даже отдельный урок специально про INPUT только отвлекли бы автора, рассеяли его внимание.

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

5)

Nex:

У справочного материала и учебника разные цели

Всё верно, если материал большой и сложный и из него можно(нужно) сделать упрощённую статью.
Но что в случаях когда информации мало - помоему в таких случаях лучше написать одну подробную и понятную статью, которая будет одновременно и учебником и справочником, как например условия, справочная статья по которым вынужнена быть настолько подробной, что вполне может быть учбениковой.

Эти действия так примитивны, что их не нужно отрабатывать

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

Вы считаете, что самые примитивные действия, несмотря что они являются для автора новыми, отрабатывать не стоит, я считаю иначе. Ваше мнение мне понятно.

они на самом деле на так уж и часты, что бы даже требовать их практического закрепления: создание новой игры, сохранение, создание локации - всё это можно отработать между делом не заостряя внимание

Невнимательная “отработка” чего бы то ни было, на мой взгляд, не закрепляет никаких навыков.

Не думаю что кому-то придётся много раз разбираться в коде…

Ваше мнение понятно.

А имеет ли он право забывать первый урок?

Конечно, имеет. И более того, скорее всего забудет. Но это не проблема, так как он всегда к нему сможет вернуться и восстановить забытое.

Код можно привести целиком для сверки.

Это предпочитаемый авторами многих учебников по программированию путь. Мне он не нравится: мало того, что текст статей “разбухает”, так ещё автору навязывается схема “скопируй вот это максимально точно”. Мне больше по душе, когда автор полагается на свои собственные силы, пишет код и разбирается со своими ошибками самостоятельно.

учебник … местами сильно излишне затянут

Ваше мнение понятно.

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

Я считаю точно так же. Только в отличие от вас, “абстрактный пример” я считаю “сложным”, а “конкретный пример” - “понятным”.

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

Не понял сути претензии. Конкретнее можно?

помоему в таких случаях лучше написать одну подробную и понятную статью

Ваше мнение понятно.

В целом, я конечно ни в коем случае не буду пытаться спорить или в чём-то вас переубеждать. В своём ответе я лишь старался пояснить, какими принципами руководствовался при разработке учебника, и почему он был сделан именно так, а не иначе. Надеюсь, теперь всё прояснилось.

Nex:

Вы считаете, что самые примитивные действия, несмотря что они являются для автора новыми

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

Baz:

А имеет ли он право забывать первый урок?

Nex:

Конечно, имеет. И более того, скорее всего забудет. Но это не проблема, так как он всегда к нему сможет вернуться и восстановить забытое.

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

Nex:

Не понял сути претензии. Конкретнее можно?

Приведённый вами пример кажется подходит - в четвёртом уроке в коде встречается функция INPUT и в пояснении сообщаестя что это функция ввода, но описание понятии “функция” и более подробная статья о функции INPUT должны быть позже. Тоесть читатель увидит плохо понятную и неразьянённую функцию и ничего не сможет сделать - он должен пропустить это и читать дальше, ожидая когда всё станет ясно, главы через две. Гораздо удобнее было бы присвоить статичное имя без ввода и не пытать читателя недомолвками с отсылкой в будущее. Как раз это вы и называете конкретным примером, против чего я и выступаю - я говорю что пример должен простым и описывать только то что уже известно.

Nex:

В целом, я конечно ни в коем случае не буду пытаться спорить или в чём-то вас переубеждать. В своём ответе я лишь старался пояснить, какими принципами руководствовался при разработке учебника, и почему он был сделан именно так, а не иначе. Надеюсь, теперь всё прояснилось.

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

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

Именно так и сделано в учебнике. Этот принцип даже выведен в предисловие.

читатель увидит плохо понятную и неразьянённую функцию и ничего не сможет сделать … не пытать читателя недомолвками … пример должен простым и описывать только то что уже известно.

INPUT не стоит отдельной статьи. В рамках её употребления в конкретном примере, её смысл разъясняется. Для подробного изучения любой отдельной функции или оператора автор должен не полагаться на то, что ему всё тут же разжуют в учебнике, а самостоятельно лезть в справку.

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

Тут мне надо бы спросить “и что дальше?”, но не хочу давить и не буду спрашивать.

Baz,
дальше - делать игры!