Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Alik, Вы писали:

A>>Мозиллы
A>>Но форум действительно удобнее. Несмотря на то, что дерево время от времени отображается кривовато
WH>Он имел в виду FAQ по RSDN@Home aka Janus!

Автор: Andre
Дата: 14.06.04

(правда FAQ слегка устарел)
WH>Программа мегарулез Я в веб вылезаю только за статьями или для того чтобы помодераровать.

Да, я понял. Суть-то вопроса была в том, какой вариант предпочтительней: приватный или публичный. Решили выбрать публичный.

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

Здравствуйте, Alik, Вы писали:

VD>>Рекомендовать можно только Рихтера. Но он наверно окажется тяжеловатым для детей.

A>Ну так и подмывало в предыдущем письме попросить не рекомендовать Рихтера
A>Спасибо за совет, но я практически уверен, что для детей он неподъемен.

С другой стороны, а почему бы не попробовать. Не с самого начало конечно... А вдруг пройдет?!

Здравствуйте, Larm, Вы писали:

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

Думаю, что все. Интересность зависит не от того что излагают, а от того как и под каким соусом излагают.

L>Вот это да, это правильно. В общем. идеи здравые, но не забываем, что учим детей. Приведенная ниже программа ориентирована на изначально заинтересованных подростков, а задача школы состоит именно в том, чтобы заинтересовать изначально не интересующихся. ИМХО так.

Знчит нужно разбавлять ее аналогиями из жизни. Интересными задачами. Байками в конце концов.

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

Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Alik, Вы писали:

A>>Доброе время суток.

D>Пока VladD2 и Andre разрабатывают более систематизированную программу , я хочу задать вопрос к методистам.

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

D>В связи с этим такой вопрос: каким образом можно восполнить это пробел? Как можно научить детей работать в команде? Как стимулировать профессиональное общение и обмен своим опытом, своими наработками? Каким образом оценивать вклад каждого члена команды? И при этом, что бы это было не в ущерб развитию способности мыслить самостоятельно. Когда нужно приучать детей работать в команде (и нужно ли это вообще)?

D>Может кто-то это уже практиковал? Поделитесь опытом и своими результатами.

Развитию навыков работы в команде в современных (продвинутых) учебных заведениях служат проведение мат и инф боев, регат, брейн-рингов, ICM-турниров, групповых проектов. Более сложно обстоит дело с оцениванием вклада каждого. Здесь все поступают скореее интуитивно или же все получают одинаковые оценки. Некоторые пытаются оценить вклад каждого путем опроса самой команды. Некоторые проводят дополнительное собеседование с каждым. Но все это пока мало эффективно или очень громоздко.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Alik, Вы писали:

A>>В основу была положена такая логика изложения:

A>>- Начать с примера простой программы, например, на сложение двух чисел.

VD>Хорошая мысль. Но первым пунктом у вас история не имеющая никакого отношения к делу, но запудривающая мозги молодым не опытным ученикам.

Спасибо за похвалу мысли второго пункта. А целью первого пункта является повторение и обобщение имеющихся знаний. Напомню, что к началу изучения ученики усвоили:
1) понятие алгоритма, исполнителя, команды;
2) виды алгоритмов;
3) основы алгоритмизации и программирования с использованием Паскаля.
Они достаточно много программировали на паскале, создавали, редактировали, исполняли, тестировали и др.

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

VD>Дык. Керниган прекрасно показал как нужно начинать. Показать примеры реальных программ очень верная идея. Но их можно а) показать не вдаваясь в подробности вроде форм и кнопок, б) вообще показать в консоли.

При всем у важении к Кернигану, он не преподавал в школе.
Первые пограммы у нас подразумеваются именно консольные. Никаких формочек там не присутствует. Если вы еще раз посмотрите программу преподавания, то увидите, что формочки появляются только в 7м пункте. Конечно, можно было бы и дальше продолжать без формочек, но причины их "столь раннего" появления были уже изложены нами раньше.

VD>Например:
VD>using System;
VD>

VD>class Sample
VD>{
VD>    static void Main()
VD>    {
VD>        Console.WriteLine(3 + 5 - 20 / 2);
VD>    }
VD>}
VD>

VD>Просто и несет реальную пользу. Сразу видно, что калькулятор отдыхает.

Тут мы с вами полностью согласны. Впрочем, так мы и написали:

Начать с примера простой программы, например, на сложение двух чисел

2. Первые программы на языке программирования С#. Понятие консольного приложения.

A>>- После этого изучить синтаксис языка (он все же несколько отличатся от паскаля, хотя многие вещи заново "учить" не надо: так, например, нет необходимости тратить много времени на if,

VD>А у вас на него 4 часа отводится! Вот это и странно.

На if дейстивтельно можно потратить меньше времени (2 часа). На for — никак нельзя. Все таки, несмотря на то, что саму идею цикла они уже освоили, for в С# сильно отличается от своего паскального брата. Поэтому надо не просто показать, а выработать умения его использования.

A>> т.к. из паскаля школьники прекрасно понимают, что это такое и достаточно показать небольшие отличия;

VD>Это какие же? Замену begin/end на {/}? Сдается мне, это они поймут за минуту.

Про begin/end не согласен. Кроме того отличий гораздо больше. Не забывайте, что это не тренинг программистов, и не университетский курс. Это школа, где каждое новое знание надо повторять и закреплять примерами.

VD>Я вообще не понимаю зачем изучать два языка. Шарп полностью воспроизводит функционал паскаля. Только намного более стойным образом. Да и дельфи лэнг. тоже ООП-язык. Уж если вы отказываетесь от паскаля, то можно было бы упростить детям жизнь.

На сегодняшний день ситуация сложилась так, что ученики, которые будут изучать C#, уже изучили паскаль. Они начали его изучать в 7-м классе.
В дальнейшем, если опыт будет успешным, можно будет рассматривать полный переход на С#.

A>>- Дальше, на основе уже имеющегося материала можно перейти к основам ООП. Это самый сложный момент: как вводить понятие класса, его структуры и т.п.

VD>Дык нужно вводить не понятие класса, а понятие типа. А класса как одного из его разновидностей. Это тесболее актуально для Шарпа. В Шарпе была предпринята удачная попытка унифицировать работы с типами.

Напоминаю, что понятие типа у них уже есть из паскаля. Кроме того, в п.2 это понятие закрепляется на примерах простых типов int & double.
Затем понятие класса также вводится как тип. Известный прием "от частного к общему" очень эффективен в школе. Т.е. они имеют представление по сути о примитивных типах, потом получают представление о классах. Тут мы говорим, что класс — это тоже тип, только пользовательский и что с ним можно работать так же, как и с простым типом, например объяавить переменную этого типа. Тут можно плавно перейти к понятию экземпляра типа.

A>> Памятуя один из основных принципов педагогики — принцип наглядности — наша идея заключается в том, чтобы вводить понятие класса на формах, компонентах и др. объектах, которые можно визуализировать:

A>>* Сначала рассматриваются форма и 1-2 компонента, и поясняется, что с каждым из них связаны переменные некоторого типа. У формы и компонентов есть свойства, которые можно задавать (изменять) при помощи процедур. Так вводятся понятие события и метода.

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

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

A>>* И только теперь, когда есть визуальная опора понимания и усвоения, вводится понятие класса как типа, примеры классов (Form, TextBox, Button, Label), экземпляров класса (с ними, оказывается, уже работали: изменяли их свойства и др.) команда создания экземпляра.

VD>А теперь попробуйте встать на место бедного учиника... Он рельно не понимает, что такое класс, тип и т.п. Но ему показывают какую-то слжную кракозябру с тысячей свойств и методов... Откуда они? А ведь о наследовании мы будем говорить только в п. 23.

На этом этапе и вводится понятие классов, методов и т.п. (как вводится — см. выше). Иллюстрацией вполне могут служить визуальные компоненты.
И при чем тут наследование? Никто о нем еще не говорит.

A>>* Здесь же уместно поговорить о конструкторе, как методе, который может задать начальные значения свойствам экземпляра класса (и это тоже уже имело визуальную поддержку)

VD>Тогда форма очень плохой пример. Ее конструктору параметры обычно не передаются, а ее инициализация ведется в отдельном методе (из-за особенностей дизайнера) вызываемом из констуктора.

Конструктор дается не на примере формы, а на примере своих классов.

A>>* Дальше пояснения продолжаются на примерах нескольких стандартных классов Microsoft.NET Framework.

VD>А не лучше ли пойти по классическому пути и создать какие-нибудь аналоги объектов из жизни? Ну, машины, животные... И главное! Сделать это на на 23 уроке. А на 3-5.

К сожалению, классического пути преподавания ООП в школе не существует. Быть может мы именно его сейчас и разрабатываем
По нашему мнению сложность надо наращивать постепенно. Если дать с первых же уроков понятие класса, наследования, инстанциирования и пр., можно просто отпугнуть детей. И тогда их будет очень сложно учить дальше. А ведь они еще даже не успели заинтересоваться предметом. Еще сложнее будет, если сразу огорошить их терминами абстракция, инкапсуляция и полиморфизм. Тут мы их потеряем навсегда.

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

A>>- В дальнейшем изучение методологии ООП продолжается параллельно с изучением компонентов, которые уместно использовать в тех или иных задачах.

VD>Опять зря. Компоненты сущьность особая. Не нужно их мешать пока люди не освоили понятие классов и типов.

В чем заключается их особенность? Они служат прекрасной иллюстрацией классов.

VD>В общем, попробую дать более развернутый ответ в посте рядом. Но уж за полноту извените. Все же это не моя прямая задача. К тому же я имел опыт обучения только более-менее взрослых людей и в двольно компактных коллективах (до 15 человек, обычно 10). Но все же. Шарп и дотнет я знаю довольно хорошо.

Спасибо. Мы уже прочитали тот пост и сейчас напишем ответ.

Здравствуйте, VladD2, Вы писали:

Прежде всего большое спасибо за проделанную работу. Мы действительно ценим вашу помощь.

VD>Здравствуйте, Alik, Вы писали:

VD>Первое что нужно учесть — это то, что план нужно строить с обязательным учетом начальных знаний учеников. Если они уже изучили Паскаль, то многое из этого плана можно выкинуть. Я буду изсходить из того, что они прогуляли все уроки по Паскалю или умудрились пообщаяться с нинавистниками Вирта. Ну, и отдельно буду давать примечания что можно опустить.

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

VD>Итак. Для начала нужно определить глобальный план.

VD>1. Нужно объяснить людям что такое алгоритм и вообще пояснить какие задачи можно решать с помощью программ.
VD>2. Нужно дать понятие процедурного программирования и структурного подхода.
VD>3. Нужно объяснить что такое типы и описать идеии ООП.
VD>4. Нужно продемонстрировать что такое библиотека, модульный подход и компонет.
VD>5. Рассказ о библиотеках и обучение использования самых часто используемых.
VD>6. В заключении нужно провести ликбез о том как нужно добывать знания и дать понятия культуры программирования.

С учетом написанного выше, первые 2 пункта в нашем случае можно пропустить.
Безусловно, если бы мы учили "с чистого листа", то начинать надо было бы именно с алгоритмов; после этого можно было бы изучать процедурное программирование на базе С# (используя статические методы, но не признаваясь, что где-то там есть объекты).

К пункту 4. Мы согласны, что полезно проиллюстрировать работу с библиотеками. Однако модульный подход — это довольно большая нетривиальная тема и сомнительно, что она по силам школьникам, да еще с учетом ограниченного времени.

Мы безусловно благодарны за пункт 6. Этот элемент мы упустили в программе и обязательно его добавим.

[skipped]

VD>3. Нужно объяснить что такое типы и описать идеии ООП.

VD>

Собственно почти цель всего курса. Причем важно дать понятие именно типа, а не класса.

VD>3.1. Заостряем внимание на целом числе и строке, как на самых часто используемых представителях типов. Вспоминаем что в примерах мы как раз использовали их.
VD>1 час.
VD>3.2. Объясняем, понятие типа и экземляра типа. Это очень важный момент, по этому ни времени, ни красок тут жалеть нельзя. Любые аналогии будут кстати. Например, легковые автомобили и Мерседас, Жигули, ... Объясняем ученикам, что любой экземляр обладает типом.
VD>2-4 часа.
VD>3.3. Крассификация типов:
VD>

VD>    * Встроенные.
VD>        * Числовые.
VD>        * Строковые.
VD>    * Массивы.
VD>    * Классы.
VD>    * Структуры.
VD>    * Делегаты.
VD>

VD>даем краткое описание того что представляет из себя каждый из пунктов, чем они отличаются и где применяются.
VD>~8 часов.

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

VD>3.4. Даем понятие влью-типов и ссылочных типов.
VD> 3.4.1. Объясняем, что такое хип и сборка мусора.
VD> 3.4.2. Объясняем что такое стек.
VD> 3.4.3. Обясняем, что вэлью типы могут храниться в хипе тлько будучи помещенные в массивы или экземпляры других типов, а ссылочные всегда хранятся в хипе.

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

VD> 3.4.4. Объячняем что такое боксинг.

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

VD>4 часа.
VD>3.5. Объясняем что такое абстракция.
VD>1 час.

Мы вообще против того, чтобы вводить формальныое понятие "абстракция". Безусловно это слово использоваться будет, т.к. оно понятно на интуитивном уровне. Но не дальше.

VD>3.6. Объясняем что такое наследование и как оно позволяет создавать абстракции.
VD>2-4 часа.

Наследование с нашей точки зрения давать рано, потому что в предыдущих темах не было сформировано понятия методов класса.

VD>3.7. Объясняем что такое инкамсуляция и как она помогает абстрагироваться от реализации.
VD>1 час.

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

VD>3.7. Объясняем что такое полиморфизм и опять же говорим об абстрагиировани.
VD>2-4 часа.

Для того, чтобы объяснить полиморфизм, надо дать понятия перегрузки методов, переопределения методов, виртуальных методов, абстракных классов. Мы думаем, что ни за 2, ни за 4, ни даже за 10 часов такие понятия школьники усвоить не смогут.

VD>

Короче, тут очень важно объяснить что без абстрагирования нельзя решать сложные задачи. И что все идеи ООП в основном нацелены на то самое упрощение решения конкретных проблем.

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

VD>В качестве примера было бы здорово сконструироват прокграмму позволяющую моделитьвать атомабили или животных. Напрмер, при помощи наследования и полиморфизма заменять двагатели делая из жигуленка гоночны болид.
VD>Если на это нужно больше времени, то не нужно скупитсья.

Было бы здорово, если бы ты описал, что должна делать эта программа. Т.е. несколько вариантов использования (use cases) с точки зрения пользователя.

VD>4. Нужно продемонстрировать что такое библиотека, модульный подход и компонет.

VD>

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

VD>4.1. Объяснить зачем нужно повторно испоьзовать код.
VD>1 час.
VD>4.2. Объчнить что такое модуль и библиотека. Пояснить, что в дотнет их роль играют сборки.
VD>2-4 часа.

На это действительно можно потратить время, если оно останется.

VD>4.3. Обяснить что такое динамическая загрузка и зачем она нужна.
VD>2 часа.

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

VD>4.4. Расказать что такое рефлекшон. Дать примеры его использования (динамическая загрузка экземпляров типов, динамический вызов метода, вывод информации о типе).
VD>4-8 часов.

Для этого у ученика еще слишком мало знаний: у него не сформированы понятия переменная класса, свойство класса. Кроме того, сама идея рефлекшина ломает представление про ООП, которое мы только еле-еле сформировали.
С нашей точки зрения эту тему стоит пропустить.

VD>4.5. Плавно подвести к тому, что эти вещи дают нам возможность работать с отчуждаемым кодом визуально, просто и комфортно. Поснить, что визвальность не связана с постоением ГУИ хотя построение гуи обычно основано на компонетном подходе. Сделать приложение со стандартыными компонентами, напрмер, с таймером.
VD>1 час.

За один час можно будет объяснить понятие "отчуждаемый код", но никак не больше . И вообще на наш взгляд ученикам это рассказывать не имеет смысла из-за сложности

VD>5. Рассказ о библиотеках и обучение использования самых часто используемых.

VD>5.1. Рассказать о FCL. Сказать, что количество уже готового кода огромно и нужно научиться эффективно его использовать.
VD>1-2 часа.

Это можно сделать за 5 минут. Если речь идет об обучении каким-то конкретным часто испольщуемым классам, то 1-2 часа крайне мало.

VD>5.2. Дать введение в коллекции. Достаточно остановиться на ArrayList и HashTable. Прикрасным примером к данному разделу будет подсчет слов в файле.
VD>4 часа.

Не слишком ли поздно? Впрочем, на эти две коллекции достаточно потратить и 2 часа.

VD>5.3. Рассказать о WinFors. Дать примеры программ.
VD>8 часов.

Здесь, конечно, стоило немного подробнее. Не совсем понятно, как рассказать, что именно рассказывать, на что тратиить 8 часов. Это может быть и мало, и много.

VD>5.4. Расказать про GDI+. Это кстати, всего лишь библиотека, а не графические возможности Шарпа. Шарп язык универсальный. Он может и без GDI+ обойтись.
VD>2 часа.

Опять же стоило бы расписать подробнее. Что рассказывать, что показывать (или не показывать). Впрочем, за 2 часа можно только показать, и то очень мало. Что уж говорить о практическом задании...

VD>5.5. Рассказать об ASP.NET. Создать пример простенького веб-сайта.
VD>2 часа.

За 2 часа? Т.е. учитель создает, а ученики смотрят?
Опять же, что рассказать, какие элементы должны быть на сайте. Следует учитывать, что незнакомых елементов быть не должно.

VD>5.6. Рассказать о БД и о ADO.NET (в общем о библиотеке доступа к данным).
VD>2 часа.

Но у учеников же еще нет понятие про базы данных вообще.

VD>6. В заключении нужно провести ликбез о том как нужно добывать знания и дать понятия культуры программирования.

VD>6.1. Объяснить что все дополнительные данные можно узнать из таких источников как:
VD>

VD>    * MSDN.
VD>    * Книги и журналы (не забыть упомянуть наш RSDN Magazine :) ).
VD>    * Рассказать о форумах и программистских сайтах 
VD>      (Опять таки не забыть про RSDN :)) ).
VD>

VD>постараться научить их правильно формулировать вопросы для форумов и составлять запросы в поиске МСДН-а.

VD>2-4 часа.

С этим мы безусловно согласны. И про RSDN не забудем!

VD>6.2. Обяснить важность соблюдения правли хорошего тона в программирвоании и стиля кодирования.
VD>2 часа.

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

VD>Ну, и в конце дать возможность создать собственные, интересные им программы.

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

В заключение, хотим высказать несколько общих замечаний и рассуждений.
1. Мы ведем речь о школьном курсе изучения основ языка программирования C#. Если ты вспомнишь школьный учебник по любому предмету, то после каждого параграфа идут вопросы, задачи и упражнения. Именно в ответах на эти вопросы и решении этих задач или упражнений есть суть усвоения учениками изучаемого материала. До сегодняшнего дня я не видел ни одного такого учебника ни по какому языку программирования. Наша цель — попытаться создать его.
2. Исходя из п.1, школьникам мало показать, надо еще и научить сразу же реализовывать это своими руками (и головой). Только тогда ученик может быть заинтересован в обычении, когда он сам видит его результат. Он стимулирует его к дальнейшей работе. Поэтому на практическую часть курса всегда уходит болше времени, чем на теоретическую часть. Не хочется сводить обучение к тому, что учитель все прекрасно и толково рассказал, а в результате ученик ничего не умеет сделать самостоятельно.
3. Всегда возникает дилемма: в рамках имеющихся часов изучить меньше материала, но детальнее и с выработкой умений его применения, или больше материала, но обзорно. Для студентов и профессиональных программистов, наверное, больше подходит второй вариант, а для школьников безусловно первый.
4. Поэтому мы и не согласны с включением в программу некоторых вопросов, безусловно очень важных и с точки зрения языка, и с точки зрения практического программирования, но трудных для понимания школьниками. Если мы нашим курсом научим их чему то и заинтересуем, они начнут читать дальше сами или их это научат в институте или другой вариант.

Здравствуйте, Alik, Вы писали:

A>1) понятие алгоритма, исполнителя, команды;

А это что такое?

A>2) виды алгоритмов;
A>3) основы алгоритмизации и программирования с использованием Паскаля.
A>Они достаточно много программировали на паскале, создавали, редактировали, исполняли, тестировали и др.

Здорово. Тогда можно после простеших программ почти сразу перейти к ООП. На демонстрацию разницы в операторах я бы положил не боле двух часов.

A>При всем у важении к Кернигану, он не преподавал в школе.

А черт его знает. Но я учился по его книге с полного нуля. И вроде как выучился. Правла я сам этого хотел.

A>Первые пограммы у нас подразумеваются именно консольные. Никаких формочек там не присутствует. Если вы еще раз посмотрите программу преподавания, то увидите, что формочки появляются только в 7м пункте. Конечно, можно было бы и дальше продолжать без формочек, но причины их "столь раннего" появления были уже изложены нами раньше.

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

VD>>А у вас на него 4 часа отводится! Вот это и странно.

A>На if дейстивтельно можно потратить меньше времени (2 часа).

10 минут будет в самый раз. Не думаю, что нужно долго объяснять, что вместо begin нужно ставить {.

A> На for — никак нельзя. Все таки, несмотря на то, что саму идею цикла они уже освоили, for в С# сильно отличается от своего паскального брата. Поэтому надо не просто показать, а выработать умения его использования.

Ну, час. Нельзя же такой примитивщене посвящать 4 и более часов? Детям будет просто скучно. Что там объяснять?

for состоит из четырех частей:
1. Инициализация. В ней можно объявить переменные некоторого типа или выполнить некоторое действие, например, проинициализировать уже имеющуюся переменную.
2. Условие продолжения цикла. Булево выражение проверяемое перед каждой итерацией. Если оно возвращает true цикл должен сделать еще одну итерацию. Если false прекратить выполнение и перейти к следущей инструкции.
3. Итератор. Инструкция выполянемая после каждой итерации цикла. Обычно в ней приращивают или уменьшают переменную-итератор.
4. Инструкци выполняемая при каждой итерации цикла. Может быть как отдельной инструкцией, так и блоком инструкций.

Собственно все. Дале остается дать пру примеров и двигаться дальше.

VD>>Это какие же? Замену begin/end на {/}? Сдается мне, это они поймут за минуту.

A>Про begin/end не согласен. Кроме того отличий гораздо больше. Не забывайте, что это не тренинг программистов, и не университетский курс. Это школа, где каждое новое знание надо повторять и закреплять примерами.

Какие оличия еще есть в if-е? Мне прям самому стало интересно.

A>В дальнейшем, если опыт будет успешным, можно будет рассматривать полный переход на С#.

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

A>Напоминаю, что понятие типа у них уже есть из паскаля. Кроме того, в п.2 это понятие закрепляется на примерах простых типов int & double.

Это не совсем то. В Шарпе типу уделено очень большое внимаение. И преподавать нужно именно теорию типа. Не забывайте что в шарпе и int, и double и любой другой тип являются проивзодными от object и лекто приводятся к нему.

A>Затем понятие класса также вводится как тип. Известный прием "от частного к общему" очень эффективен в школе.

А понятие абстракции им дается перед этим? Другими словами объясняется зачем нужен этот самый класс?

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

Ну, а как насчет структур и делегатов?

A>Да, должны быть именно иллюстрацией. Формочки — это и есть идеальная иллюстрация для школьника, а не абстракные животные, конкретный случай которых — это собаки и кошки.

Еще раз напомню, что вы проталкиваете формочки раньше чем объясните базовые принципы ООП. Так что иллюстрацией они тут быть не могут. Хотя бы совместите эти вещи. Нельзя бежать впереди паравоза.

A> Про животных можно рассказать в кабинете в качестве одного из устных примеров, но на компьютере надо показывать именно формочки.

Да все равно на чем показывать. Главное, чтобы показывать на простых примерах и вовремя. Окна коенчено тоже неплохая иллюстрация.

A>На этом этапе и вводится понятие классов, методов и т.п. (как вводится — см. выше).

Так вот и поменяйте местами урок 7 и 23. Сначало объясните людям "что", а потом продемонстрируйте "как". Иначе каша в голове гарантирована. Причем дети не знаю что кашу создали им вы, и будут думать, что это они ущербны.

A> Иллюстрацией вполне могут служить визуальные компоненты.
A>И при чем тут наследование? Никто о нем еще не говорит.

Притом что это единственное объяснение откуда взялись тысячи метдов. Да и что еще можно иллюстрировать окнами?

A>Конструктор дается не на примере формы, а на примере своих классов.

Напомню твои слова "Здесь же уместно поговорить о конструкторе". Я так понял, что "Здесь же" отностися именно к формам.

VD>>А не лучше ли пойти по классическому пути и создать какие-нибудь аналоги объектов из жизни? Ну, машины, животные... И главное! Сделать это на на 23 уроке. А на 3-5.

A>К сожалению, классического пути преподавания ООП в школе не существует. Быть может мы именно его сейчас и разрабатываем

Сдается мне, что на западе он давно пройден.

A>По нашему мнению сложность надо наращивать постепенно. Если дать с первых же уроков понятие класса, наследования,

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

A>инстанциирования

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

A>и пр., можно просто отпугнуть детей. И тогда их будет очень сложно учить дальше.

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

A> А ведь они еще даже не успели заинтересоваться предметом.

Это изучив то Паскаль?

A> Еще сложнее будет, если сразу огорошить их терминами абстракция, инкапсуляция и полиморфизм. Тут мы их потеряем навсегда.

Эти термины и нужно им изучить. Я в вашей программе вообще их незаметил. Огорошивать ими не нужно. Нужно ввести понятие и объяснять на примерах столько сколько будет нужно.

A>В качестве примера можно привести обучение школьных преподавателей на курсах по С#. Их как раз учили по той самой классической программе.

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

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

Незнаю. То ли я не те слова подбираю, то ли еще что, но ты меня не понимашь. Я указываю на непоследовательность и отсутсвие важнейших понятий. А ты мне каждый раз о легкости изучения. Ваша задача совместить эти вещи. Никто не заставляет делать занудные лекции. Но изложение, тем не менее, должно быть последовательным, полным и непротиворечивым. Это же основы логики! Кстати, а ее детям у вас преподают?

VD>>Опять зря. Компоненты сущьность особая. Не нужно их мешать пока люди не освоили понятие классов и типов.

A>В чем заключается их особенность?

В том, что они компоненты. Сущности предназначенные для динамической загрузки и интерактивного взаимодействия с ними. Это отдельная идеология собирания ПО из готовых блоков. Как говорится "бзе гвоздей".

A> Они служат прекрасной иллюстрацией классов.

Плохой они иллюстрацией служат. Они сами по себе должны объясняться.

A>Спасибо. Мы уже прочитали тот пост и сейчас напишем ответ.

ОК.

Здравствуйте, Alik, Вы писали:

A>К пункту 4. Мы согласны, что полезно проиллюстрировать работу с библиотеками. Однако модульный подход — это довольно большая нетривиальная тема и сомнительно, что она по силам школьникам, да еще с учетом ограниченного времени.

Это концептуальная основа Шарпа. Ни в коем случае не опускйте ее.

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

Значит дайте 16, 24, 32... В общем, столько сколько нужно. Это очень важный аспект.

VD>>3.4. Даем понятие влью-типов и ссылочных типов.
VD>> 3.4.1. Объясняем, что такое хип и сборка мусора.
VD>> 3.4.2. Объясняем что такое стек.
VD>> 3.4.3. Обясняем, что вэлью типы могут храниться в хипе тлько будучи помещенные в массивы или экземпляры других типов, а ссылочные всегда хранятся в хипе.

A>Об этом можно рассказать обзорно. Скорее всего в голове оно не останется, т.к. практического применения не найдет и проиллюстрировать крайне сложно.

Практическое применение — это полиморфизм. Вы датете практический пример на самом первом уроке:

Console.WriteLine(1 + 2);

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

VD>> 3.4.4. Объячняем что такое боксинг.

A>Здесь очень трудно объяснить, что такое боксинг, т.к. не понятно, зачем он нужен.

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

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

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

A>Мы вообще против того, чтобы вводить формальныое понятие "абстракция". Безусловно это слово использоваться будет, т.к. оно понятно на интуитивном уровне. Но не дальше.

Мне кажется это грубешая ошибка. Без понимания того что такое абстракция и без четкого понимания ее значимости ни о каком ООП говорить нельзя. Да и не только об ООП.

A>Наследование с нашей точки зрения давать рано, потому что в предыдущих темах не было сформировано понятия методов класса.

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

A>Для того, чтобы хотя бы обзорно дать понятние инкапсуляции (а подробнее ученикам усвоить не под силу), надо сформировать понятие интерфейса и прав доступа к членам класса. В предыдущих пунктах об этом не упоминалось.

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

Все, и интерфейс, и интерфесы (как часть языка), и модификаторы доступа, все это долно быть дано как раз в этих двух уроках. И это очень важно. И очень важно чтобы дети связывали все это с терминами наследования, полиморфизма и инкапсуляции. Это столпы ООП. Если вы не дадите их, то лучше вообще не мучить детей. Так как время оти проведут зря.

A>Для того, чтобы объяснить полиморфизм, надо дать понятия перегрузки методов,

перегрузки не надо. Вернее надо, но к полиморфизуму это отношение не имеет.

A> переопределения методов, виртуальных методов, абстракных классов.

А так же интерфейсов...

A> Мы думаем, что ни за 2, ни за 4, ни даже за 10 часов такие понятия школьники усвоить не смогут.

Значит пусть усваивают за 20. Это в конце концов цель вашего курса. Какое ООП без базовых знаний?

VD>>[q]Короче, тут очень важно объяснить что без абстрагирования нельзя решать сложные задачи. И что все идеи ООП в основном нацелены на то самое упрощение решения конкретных проблем.

A>Как раз без абстрагирования можно решать задачи.

Внимательнее почти то что я написал. Сложные задачи.

A> Это, конечно, ключевой момент ООП, но его пока можно обойти стороной.

Ни в коем случае! Вы можете им не дать пол языка, но это понятие обязаны. Или вы сделаете из детей потенциальных коллек.

A> Позже, когда школьник столкнется с этим понятием, он вспомнит, что сталкивался с ним и раньше, просто не называл еготак. Этот прием в педагогике называтеся пропедевтика и применяется сплошь и рядом при изучении практически всех школьных предметов.

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

A>Было бы здорово, если бы ты описал, что должна делать эта программа. Т.е. несколько вариантов использования (use cases) с точки зрения пользователя.

Да какя будет программа в общем-то не важно. Важена сама иллюстрация. Возможно таких программ будет множетсво (на каждй урок). Я все же шел по верхам.

A>На это действительно можно потратить время, если оно останется.

Так не трате много времени на ерунду вроде if-ов, которые они и так знают. А потратьте на то что нужно. Хотя если вы хотите экономить на принципах ООП, то зря. Лучше уж отказаться от библиотек. Организация модульности и компонентности — это всео лишь технологические решпния. Они могут измениться, а вот если вы толково обясните детям понятия инкасуляции, наследования и полиморфизма, то они вам по гроб будут благодарны.

A>Мы считаем, что практически невозможно объяснить за 2 часа школьнику, что такое динамическая загрузка. И уж тем более зачем она нужна.

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

Assembly assembly = Assembly.LoadFrom("путь\имя сборки");
IНекийИнтерфейс некийИнтерфейс = (IНекийИнтерфейс)assembly.CreateInstace("имя типа");
некийИнтерфейс.НекийМетод();

А уж рассказ про компоненты без этго будет подбен шаманской сказке.

VD>>4.4. Расказать что такое рефлекшон. Дать примеры его использования (динамическая загрузка экземпляров типов, динамический вызов метода, вывод информации о типе).
VD>>4-8 часов.

A>Для этого у ученика еще слишком мало знаний: у него не сформированы понятия переменная класса, свойство класса. Кроме того, сама идея рефлекшина ломает представление про ООП, которое мы только еле-еле сформировали.

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

A>С нашей точки зрения эту тему стоит пропустить.

Возможно. Но если есть время, то лучше хотя бы поверхносно коснуться.

A>За один час можно будет объяснить понятие "отчуждаемый код", но никак не больше . И вообще на наш взгляд ученикам это рассказывать не имеет смысла из-за сложности

Знчит коректируйте часы. Сложности тут никакой нет. Иначе нет вообще смысла показывать им компоненты. Ваше мнение о том, что компонет — это иллюстрация класса в корне неверно.

VD>>5.1. Рассказать о FCL. Сказать, что количество уже готового кода огромно и нужно научиться эффективно его использовать.
VD>>1-2 часа.

A>Это можно сделать за 5 минут.

Странные у вас оценки времени. На ФЦЛ можно убить и 100 часов.

A> Если речь идет об обучении каким-то конкретным часто испольщуемым классам, то 1-2 часа крайне мало.

Нужно учить не конкретным классам, умению изучать новые классы и применять их на практике. Если времени мало, значит увеличивать его.

VD>>5.2. Дать введение в коллекции. Достаточно остановиться на ArrayList и HashTable. Прикрасным примером к данному разделу будет подсчет слов в файле.
VD>>4 часа.

A>Не слишком ли поздно?

Нет. В самый раз. Это как раз и будет иллюстрацией использования классов из ФЦЛ.

A> Впрочем, на эти две коллекции достаточно потратить и 2 часа.

Ошибаетесь. Как минимум хэш-таблица заслуживает своих 2 часов. И потом вам нужно учит не конкретной реализации (она кстати, уже новая есть, во втором фрэймворке введены List<T> и Dictionary<K, V>, т.е. дженерик-классы.

VD>>5.3. Рассказать о WinFors. Дать примеры программ.
VD>>8 часов.

A>Здесь, конечно, стоило немного подробнее. Не совсем понятно, как рассказать, что именно рассказывать, на что тратиить 8 часов. Это может быть и мало, и много.

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

VD>>5.4. Расказать про GDI+. Это кстати, всего лишь библиотека, а не графические возможности Шарпа. Шарп язык универсальный. Он может и без GDI+ обойтись.
VD>>2 часа.

A>Опять же стоило бы расписать подробнее. Что рассказывать, что показывать (или не показывать).

Ну, значит можно по позже сесть и попытаться расписать примерный план по библиотекам.

A>Впрочем, за 2 часа можно только показать, и то очень мало. Что уж говорить о практическом задании...

Время прикидочно. Я уже говорил, но повторюсь. Основное время я бы потратил на базовые понятия ООП. Они намного важнее. А уж что останется пускать на библиотеки. В конце концов знание конкретных реализаций совсем не важно в перспективе.

VD>>5.5. Рассказать об ASP.NET. Создать пример простенького веб-сайта.
VD>>2 часа.

A>За 2 часа?

Можно и за 10 минут. Ты меня не слушаешь и отрицаешь необходимость очевидных вещей. А именно они дадут возможность быстро познакомить детей с технологией. Изучить конечно ее им не удастся. Но это будет хороший быстрый старт и применение полученных знаний на практике.

Создать простенькое веб-приложение не сложнее чем форму. Особенно если исползовать второй фрэймворк (а именно его лучши и использовать, так как иначе вы будет учить детей устаревшей информации).

A> Т.е. учитель создает, а ученики смотрят?

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

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

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

VD>>5.6. Рассказать о БД и о ADO.NET (в общем о библиотеке доступа к данным).
VD>>2 часа.

A>Но у учеников же еще нет понятие про базы данных вообще.

Нда. Логично. Ну тогда или отказаться вообще, или уделить этому вопросу болше времени.

A>С этим мы безусловно согласны. И про RSDN не забудем!

Ну, хоть в чем-то мы сошлись.

A>Для нас сомнительно, что ученики смогут это сделать. Большинство вопросов изучалось обзорно. Ни один материал не был отработан...

Можете не сомневаться как минимум один точно напишит. А вообще чем болше практики тем лучше. Вы как раз должны стараться чтобы после курса ученик мог уметь программировать.

A>1. Мы ведем речь о школьном курсе изучения основ языка программирования C#.

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

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

Очень странно. Еще раз отсылаю к Кернигану и Ричи. У них язык изучался именно на примерах. Они просто реализовывали функции стандартной библиотеки С. Я вот до сих пор помню, хотя читал его много лет назад.

A> Наша цель — попытаться создать его.

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

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

A>2. Исходя из п.1, школьникам мало показать, надо еще и научить сразу же реализовывать это своими руками (и головой). Только тогда ученик может быть заинтересован в обычении, когда он сам видит его результат.

Согласен что это полезно. Но... та же алгебра оказвается вообще не нужной 90% учеников, но тем неменее ее учат и веселого в этом не много.

A> Он стимулирует его к дальнейшей работе. Поэтому на практическую часть курса всегда уходит болше времени, чем на теоретическую часть.

А их не должно быть. Совмещайте! Дали теории... сделали программку ее применающую. Тут все просто.

A> Не хочется сводить обучение к тому, что учитель все прекрасно и толково рассказал, а в результате ученик ничего не умеет сделать самостоятельно.

Дык, вот пусть и изучают на практике.

A>3. Всегда возникает дилемма: в рамках имеющихся часов изучить меньше материала, но детальнее и с выработкой умений его применения, или больше материала, но обзорно. Для студентов и профессиональных программистов, наверное, больше подходит второй вариант, а для школьников безусловно первый.

Для всех лучше первый варинт. Вам же нужно просто правильно раставить акценты. ООП приоритет, а остальное по возможности.

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

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

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

Здравствуйте, VladD2, Вы писали:

VD>Это в корне не верный подход. А мучиться потом с его плодами рийдется нам. Уже как кость в глотке торчат бедари научившиеся писать операторы и возить мышкой контролы, но нифига не помнимающие в принципах ООП и проектирования.

2Alik как ты думаешь почему распространено мнение что не дельфих пишут только ламеры? Хотя это не так.
Это происходит именно по тому что подавляющие большинство дельфи "программистов" только и умеют кдать на форму кнопки и писать операторы.

ЗЫ "бедари" я конечно понимаю что это очепятка но термин классный получился.

Здравствуйте, Alik, Вы писали:

A>Доброе время суток.

A>В качестве эксперимента она предложила некоторым "продвинутым" школам перейти с изучения паскаля (Delphi) на С#. Переход этот, размеется, подразумевает и смену парадигмы с процедурной на объектно-ориентированную.

Программирование в Delphi вовсе не процедурно-ориентированное, кстати.

Здравствуйте, Alik, Вы писали:

A>Доброе время суток.

лучше это в юмор%)

Здравствуйте, gribunin, Вы писали:

G>Программирование в Delphi вовсе не процедурно-ориентированное, кстати.

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VladD2, Вы писали:

VD>>Это в корне не верный подход. А мучиться потом с его плодами рийдется нам. Уже как кость в глотке торчат бедари научившиеся писать операторы и возить мышкой контролы, но нифига не помнимающие в принципах ООП и проектирования.
WH>
WH>2Alik как ты думаешь почему распространено мнение что не дельфих пишут только ламеры? Хотя это не так.
WH>Это происходит именно по тому что подавляющие большинство дельфи "программистов" только и умеют кдать на форму кнопки и писать операторы.

У меня, к сожалению, нет статистики, но я лично знаю двух "дельфистов" очень высокой квалификации, которые создали систему документооборота и перевели на нее ГлавКиевАрхитектуру. Было это лет 5 назад. Насколько я знаю, система до сих пор там в работе.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, gribunin, Вы писали:

G>>Программирование в Delphi вовсе не процедурно-ориентированное, кстати.

VD>Думаю, что они преподают детям Паскль используя Дельфи в качестве среды и компилятора.

Ты ошибаешься. Процедурную часть паскаля преподают с использованием TP7.0, хотя и делфи тоже можно использовать. Но для изучения основ алгоритмизации этого вполне достаточно.

Здравствуйте, VladD2,

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

Здравствуйте, Alik, Вы писали:

WH>>2Alik как ты думаешь почему распространено мнение что не дельфих пишут только ламеры? Хотя это не так.
WH>>Это происходит именно по тому что подавляющие большинство дельфи "программистов" только и умеют кдать на форму кнопки и писать операторы.

A>У меня, к сожалению, нет статистики, но я лично знаю двух "дельфистов" очень высокой квалификации, которые создали систему документооборота и перевели на нее ГлавКиевАрхитектуру. Было это лет 5 назад. Насколько я знаю, система до сих пор там в работе.
Видимо ты не заметил выделеного. У меня друг тоже дельфист при том очень высокой квалификации. Я же говорил про большинство которое и создает репутацию.

Вобще я это к тому чтобы из ваших учеников не получились "кнопка, форма шлепатели" которые мнят себя программистами.

Здравствуйте, VladD2, Вы писали:
...
VD>3.4. Даем понятие влью-типов и ссылочных типов.
VD> 3.4.1. Объясняем, что такое хип и сборка мусора.
VD> 3.4.2. Объясняем что такое стек.
VD> 3.4.3. Обясняем, что вэлью типы могут храниться в хипе тлько будучи помещенные в массивы или экземпляры других типов, а ссылочные всегда хранятся в хипе.
VD> 3.4.4. Объячняем что такое боксинг.
...
VD>4.3. Обяснить что такое динамическая загрузка и зачем она нужна.
VD>2 часа.
VD>4.4. Расказать что такое рефлекшон. Дать примеры его использования (динамическая загрузка экземпляров типов, динамический вызов метода, вывод информации о типе).
VD>4-8 часов.

А тебе не кажется что это немного не школьная программа. Скорее институтская.

VD>5. Рассказ о библиотеках и обучение использования самых часто используемых.

VD>5.1. Рассказать о FCL. Сказать, что количество уже готового кода огромно и нужно научиться эффективно его использовать.
VD>1-2 часа.
VD>5.2. Дать введение в коллекции. Достаточно остановиться на ArrayList и HashTable. Прикрасным примером к данному разделу будет подсчет слов в файле.
VD>4 часа.

Мне кажется такие вещи, равно как и одно- двухсвязные списки школьники должны сами уметь реализовывать. А про ArrayList можно потом рассказать, когда они его сами уже напишут.

...
VD>5.6. Рассказать о БД и о ADO.NET (в общем о библиотеке доступа к данным).
VD>2 часа.

Вот это по-моему точно рановато.

Здравствуйте, Alik, Вы писали:

A>Ты наверное не обратил внимание на начало письма. Эти школьники УЖЕ потратили достаточное время на алгоритмы. Кроме того (об этом я не писал, но раз интересно...), у них еще впереди целый год (11-й класс) на программирование некоторых мат-методов. Так что даже альтернативы такой не стоит: "алгоритмы или язык программирования".

Извините, я наверное что-то пропустил

A>И чем это лучше, чем использовать все тот же процедурный паскаль? Отсутствие типизации я считаю недостатком, а не достоинством (не надо начинать holy war, я говорю про данный конкретный случай).

Я с вами и спорить не собираюсь. К сожалению, я знаю студентов, которые не понимают, что в int нельзя запихать 100000000000000000. Не говорю уж о преобразованиях, например: int a = "10";

N>>А если говорить о том, чтобы они сразу получали практические знания — это вряд ли можно уложить в 100 часов для среднестатического школьника, у которого голова забита совершенно другими вещами.
A>А на чем основывается это утверждение?

На собственном школьном опыте. Чтобы изучить С (не C++, тогда он еще не был общераспространенным), мне понадобился месяц непрерывного изучения (часа по 4-5 в день, может больше), притом, что у меня был опыт бейсика и ассемблера. Бейсик изучил быстро — за пару недель научился писать уже кое-какие программы, однако на изучение всех подробностей понадобилось тоже около месяца. Про ассемблер не говорю — это сегодняшним школьникам точно не надо
И это все при том, что у меня очень хорошие способности к языкам (программирования в частности), голова не была забита вещами, о которых думает теперешнее поколение (бабы, бабки, покурить/выпить).
Так что я не верю, что в 100 часов можно уложить изучение такого сложного высокоуровневого языка со статической типизацией (я не говорю про runtime возможности, в частности, reflection; аттрибутное программирование и т.п.) как C# (в этом отношении по грамматике тот же C++ проще). Но, в сущности, если рассмотреть только подмножество C# (на уровне написания прикладных программ наподобие калькулятора и блокнота), то это реально (однако тогда стоит внести поправки в программу).

A>Компания MS придумала еще один шаг в процессе популяризации .Net
A>В качестве эксперимента она предложила некоторым "продвинутым" школам перейти с изучения паскаля (Delphi) на С#. Переход этот, размеется, подразумевает и смену парадигмы с процедурной на объектно-ориентированную.

С моей точки зрения, программа эта интересна исключительно MS. Ничего нового школьникам не даёт.
1. Абсолютно без разницы, на чем учить школьников — на Delphi, Java или C#. В первом приближении эти вещи довольно похожи. Декларация перехода с Delphi на C# — исключительно попытка пиара.
2. На мой взгляд, если уж и думать о замене Делфи на что-то другое, то этим чем-то другим могла бы оказаться Java. Причин несколько, главные:
(1) это мэйнстрим
(2) плохому Java не научит
(3) на порядок большая защищенность инвестиций. За время жизни java успел родиться и умереть VB, а java живёт себе и хорошеет.
(4) наличие бесплатных средств разработки, включая очень неплохие (Eclipse, JBuilder Foundation и др.)
3. Тот факт что я их не знаю, еще не означает, что нет других достойных кандидатов из серии Питона и т. п.

Здравствуйте, rockandroll, Вы писали:

R>А тебе не кажется что это немного не школьная программа. Скорее институтская.

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

R>Мне кажется такие вещи, равно как и одно- двухсвязные списки школьники должны сами уметь реализовывать. А про ArrayList можно потом рассказать, когда они его сами уже напишут.

Ну, вот чтобы школьники были осведомлены им и нужно расскзать, что ArrayList — это динамический массив указателеф на объекты, а не связанный список.

VD>>5.6. Рассказать о БД и о ADO.NET (в общем о библиотеке доступа к данным).
VD>>2 часа.

R>Вот это по-моему точно рановато.

Значит ежика вычеркивем (с)