OberonCore

А разве таких нет в школьной сборке в количестве четырех штук?

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

Да в общем то наверное они пишут лучше. Возможно у них там в целом система более отлаженная.
А ниже моему лучшему оппоненту Сергею Прохоренко. О выборе аудитории.

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

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

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

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

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

То есть все-таки не только старшеклассники.
Но все-таки старшеклассники в центре внимания.

Про средние классы (5-7) у меня не сложилось впечатление по книге, что они попадают в целевую аудиторию.
Про младшекурсников как целевую аудиторию можно говорить, полагаю, только в том смысле, что многие из них не получили в школе, того, что должны были -- в идеале -- там получить.

В идеале моя целевая группа 8-10 классы. Но встречаются родители маньяки, которые уверены, что их чадо имеет талант к программированию и тогда я беру более мелких. 3 классник если честно был только один 5 классники, уже встречаются как некая закономерность, 6-7 классники еще чаще, но это уже очевидные вундеркинды для которых возраст не фактор. Студенты младших курсов от старшекласников по крайней мере в нашем городе отличаются не принципиально. Возможно в других городах, где сильные ВУЗы ситуация иная. Старшие курсы это уже нонсенс, это уже проблема их учебного процесса в ВУЗе и эти приходят с меркантильными целями, слегка подковаться для зачета и долго не задерживаются, да я уже пожалуй давно таких и не брал. Правда у меня есть старшие студенты, которые просто не бросают заниматься у меня. Но это отдельная песня и отдельный курс с иными методическими идеями. Отмечу только, что здесь опять таки возраст не решающий момент. Иногда эта отдельная песня начинается уже со школьниками. Сейчас например у меня есть мальчишка 9 классник с которым я сошел с накатанных рельсов. Там я своими книгами уже не пользуюсь. Вообще мой курс состоит из трех уровней, я сейчас хочу охватить первые два. Третий уровень в системном курсе просто не нуждается.

Школьная сборка - это НЕ КНИЖКА. Это практически в любой системе есть такие примеры. Но нужно именно в книжке для начинающих...

Программная инженерия - важнейшая весчь...
К сожалению, мне не удалось пока найти книжку, в которой бы программирование для начинающих было бы подано с позиций программной инженерии.
А схема подачи относительно проста:
1. Цель. Зачем писать программу? Или, может быть, просто формулировка задачи.
2. Требования к будущей программе - этого никто не пишет для простых программ. А НАДО. Мы в лабах пытаемся формулировать явным образом.
3. Проект - если прога объемом 100 строк и более. Либо она разбивается на функции. Опять в совершенно явной формуклировке и с объяснениями, почему именно такие функции.
4. Соответственно программа - разработка.
5. Тестирование!!! Это - один из важнейших вопросов, с которым начинающие ну НИКАК не знакомятся... А ведь это - важнейший навык программиста! Я вот сейчас первачкам пытаюсь внедрить самостоятельность в разработке тестов. А то они в школе привыкают, что учитель проверит. А должны - САМИ!
6. Рефакторинг. Процесс улучшения кода без изменения функциональности. И тут мечтаю, чтобы были описана простая систему управления версиями и простейшие приемы работы с ней. Этого же тоже нигде практически не пишут. А надо. Здесь же - приемы и навыки профилирования. Хотя бы простейшие приемы измерения времени выполнения.
Конечно, схема - это схема. Но она, по крайней мере, дает ориентир, чего надо

Доводы ясны, но я бы не торопился с тестированием и вообще отладкой.

(Предв. пояснение: У меня форма аудиторной работы - на проекторе. Вызываем кого-нибудь на полпары - и он работает. Иногда по неск. человек над одним примером. Лаб у нас в СПО нет отдельных, т.е. преподаватель ведёт тот же. Смысла и возможности рассаживать 30 чел. по компам и бегать я не вижу, а часы дороги - поэтому задания даю на дом, пусть дома возятся)

Так вот, примеры уже давно идут в несколько модулей - и достаточно ёмкие. Например, сейчас - сервер передачи файлов на основе Comm и Actions.

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

Я думаю, что раннее введение тестов и "контроля качества" будет противоречием к выработке вот этих навыков "уверенного полёта с гарантированным качеством". Должно быть вбито чёткое ощущение и умение выдавать безошибочные модули такого размера - 500-1000 строк.

Да? А Вы их видели? Упомянутые четыре примера.

Согласен с Валерием - вот с этим уточнением. И в таком понимании инженерия, конечно, должна идти "красной нитью" - на сквозном примере.
Относительно оформления таких примеров - возможно, нужно говорить об удобном распределении их содержания между книгой и ББ-документом. "Локальная СУБД" в этом смысле для меня ориентир - процесс разработки можно прочесть "отдельно от машины", а результаты сохранены на машинном носителе. А вот когда говорим о разработке собственно интерактивного документа (изложение MVC, формирование системы связанных документов) - можно давать полную инструкцию в его формуляр-образце, а в книге - только общие соображения (если брать форму, заданную моей Задачей 1.1.1 отсюда - визуализация в OpenOffice - то это раздел Описание предметной области).

P.S. Об инженерии размышлял здесь - в связи как раз с представлением постановки задачи. Как "предметник", конечно - но именно ему взаимодействовать с разработчиком для фрмулирования требований и рассмотрения решения. О сути взаимодействия поразмышлял здесь, а как можно писать и оценивать - тут.

Это любопытно. Потому что в алгоритмизации, скажем, есть методики - хотя бы описанный здесь и на связанной странице комплекс Ляховича (адаптированный). И вот в этой методике - прежде всего в п. 4 - как раз видим, что сначала надо найти произвольный алгоритм. И интересен каждый подход к такому поиску.

В качестве примера, чего хотелось бы видеть в книжке для начинающих по ББ+КП, можно привести вот эту первую лекцию на Интуите.
http://www.intuit.ru/department/pl/prcmsvs2010/1/
И это - еще до первого примера в самой среде.

Мне пришла в голову идея модифицировать рельсовые синтаксические диаграммы:

• те элементы диаграммы, которые отражают элементы кода, располагающиеся горизонтально на одной строке, должны изображаться в одну горизонтальную линию (как это и сейчас делается)
• те элементы диаграммы, которые отражают элементы кода, располагающиеся обычно друг под другом (например, ,IF ELSIF ELSE END), должны изображаться друг под другом

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

Это не так, как на рисунках в п. 5.2.3 здесь?

Ага... для любого изделия сначала надо описать, как подготовить/начать/завершить его использование...

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

Измерения - это как у Ерёмина в п. 3.6.2? Или что-то ещё другое?

Насчёт управления версиями - это да. Тем более, что пока реализация этого внутри РДП-среды только планируется (в частности, как я понял, Вами в проекте "Семантический редактор"). Неавтоматизированная же методика была выработана ещё для МФЗ семейства IDEF (см. о "цикле IDEF-папок" в стандартах, вложенных в это сообщение) - быть может, её и принять за основу?

Кстати, по-своему для школьников рекурсию объясняют "Роботландцы" - см. выдержку из Дуванова и др., вложенную в это сообщение. Интересно, что показывается и возможность выполнить "отложенную" (т.е. сохранившуюся в состоянии каждой копии процедуры) команду (блок) при возврате из рекурсии.

P.S. Откладывание основано на определённой маршрутной структуре алгоритма с рекурсией. И показывать это удобно графически (дракон-схемами)... как, впрочем, и любые формальные структуры.

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