Личный кабинет

Хабаровская школа программистов

Как учить программированию
Виталий Потопахин ( Пользователь )
(s11kai @ 07.04.2007, 11:36) <{POST_SNAPBACK}>
Заметка из школьной газеты, так, для разрядки:

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


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

Второй путь это путь учителя. Нужно определение достаточно функциональное и достаточно правильное (а степень достаточности невысока). Так вот я так думаю, что Угринович, как и прочие исходят из именно учительской позиции. ПРавда с этой позиции мне кажется, что старое доброе "Алгоритм это такая последовательность команд выполнение которой в одинаковых условиях приводит к одинаковому результату" лучше. Вот эти "процессы преобразования объектов" звучит очень наукоемко и нудно. Кроме того, если так уж нужна наукоемкость, то может быть вернутся к строгой науке?!

И кроме того, я уверен, что вопрос определения алгоритма не очень существеннен. Я иногда обсуждаю с отдельными учениками проблему определения этого термина, но лишь с отдельными и только в том случае если они достигают хороших результатов и начинают кропать изящные не лишенные остроумия программы. Получается нонсен. Программы делают хорошие. А в терминологии не разбираются! Отсюда вопрос - А так ли нужны определения. Я полагаю, что надо только в двух случаях:

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

Второй - Мы формируем общую картину человеческого знания. Тогда нужно определение попроще. Можно и Угриновича.

Что же касается программы. То формального определения этому понятию нет. А понимание программы, как способа записи алгоритма вполне логично.
Михаил Кушнир ( Пользователь )
Если позволите, добавлю свои 5 центов, как говорят в стране массовых нобелевских лауреатов (многие из которых российского происхождения - к чести и грусти нашей).
Полностью согласен с тем, чтобы минимизировать терминологические экзерсисы. Я заметил, что новые термины создают гораздо более высокий психологический барьер, чем стоящее за ними содержание. Поэтому теперь 20 раз думаю прежде, чем их вводить.
Я предлагаю ввести такие определения
Алгоритм - это последовательность команд, предназначенная для конкретного исполнителя.
Правильный алгоритм позволяет исполнителю при одинаковых условиях всегда получать одинаковый требуемый результат. Обычно наиболее важно уточнить начальные условия.
Программа - это алгоритм, написанный для компьютера.

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

Алгоритм пишется в следующих условиях:
1) Постановщик задачи ДОСТОВЕРНО ЗНАЕТ, как решАть такие задачи
2) У него самого нет возможности (желания) решать эти задачи
3) У него есть исполнитель, который может
- выполнить в нужной последовательности необходимые для решения действия (технологическая способность)
- принять к исполнению эту последовательность (коммуникативная способность)

Однако, при обучении (и в предлагаемых определениях!!!) нет жесткой связи с исполнителем, но без исполнителя понятие алгоритма бессмысленно. Чаще всего на пп.1-2 внимания вообще не обращают.
По моим наблюдениям чаще всего знакомство с понятием "алгоритм" начинают (самый ответственный момент) с записи абсолютно бессмысленных и некорректных алгоритмов типа утреннего кипячения чайника.
Он бессмысленен, т.к. не выполняется п.3 - нет готового для работы исполнителя (мама и бабушка сами знают, как закипятить чайник).
Он некорректен, т.к. обычно перд началом составления этого лже-алгоритма не предъявляется доступная исполнителю система команд, если не считать таковой универсальную команду "хочу чай". Даже при попытке составить такую систему команд не удастся избежать таких, которые неисполнимы без возможностей ИИ - это уже размывает понятие.
Даже при очень удачной алгоритмической игре с движением ребенка-манипулятора по классу под четкие команды ребенка-процессора учитель часто прощает вольности интерпретации команд.
В результате у учащихся на старте не формируется базовых ценностей алгоритмического мышления.
Это компенсируется после значительного опыта создания реальных алгоритмов, но не помогает на этапе развития после первых занятий. Думаю, даже жестче - такие начальные уроки усложняют понимание темы.
К сожалению, лично проверить свою гипотезу мне не удалось - теперь у меня мало часов и они не в начальной фазе.
Сергей Галаган ( Пользователь )
(Потопахин Виталий @ 06.04.2007, 11:48) <{POST_SNAPBACK}>
Что касается рисования на информатике, то я тут больше соглашусь с Александром Ивановичем. В программировании уровень абстракции не ниже чем в математике, но математика у детей с первого класса и их к этой абстракции готовят очень медленно и то для многих понятия математики большая проблема. У нас же как с обрыва в омут. Графика помогает смягчить удар. Вроде бы те же циклы, те же присваивания, но результат видно визуально, это сильно помогает.

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


Мало другого уровня программирования, а заложенное в программе всеже можно и нужно(если не исключительно в рекомендованной среде программирования) всем, только время... больше надо, два часа в старших - минимум.
Другой уровень олимпиады для всех.
По информатике и ИКТ, а не по исключительно программированию единственную официальную всероссийскую в предмете проводить. Не знают такой буржуины и ладно, неужто только международные олимпиады должны определять перечень официальных в России?

Касаемо анимаций и рисования, черчения на компьтере, то здесь не вижу противопоказаний ни в одном профиле, возможно только для желающих, но навык не повредит никому, решительно полезно.
Сергей Галаган ( Пользователь )
(МЭК @ 07.04.2007, 23:12) <{POST_SNAPBACK}>
хочу чай

В качестве первого алгоритма полезно разобрать инструкцию к практической работе, и польза, внимание к формальным обозначения и практическое применение незамедлительно, наглядно, и экономия времени.
Михаил Кушнир ( Пользователь )
(Galagan Sergei Igorevich @ 07.04.2007, 23:35) <{POST_SNAPBACK}>
В качестве первого алгоритма полезно разобрать инструкцию к практической работе

Боюсь, для четкого понимания понятия "алгоритм" инструкция для человека неудачна.
1) нет системы команд без уровня ИИ
2) нет последовательности действий, БЕЗДУМНОЕ выполнение которых приведет к требуемому результату -только описание условий, хотя иногда эти условия хронологически выстроены

Вот, при изучении языков ИИ некоторые инструкции могут оказаться удачной моделью
Виталий Потопахин ( Пользователь )
Согласен, что для школьного обучения понятие алгоритма важнее понятия программы. Я даже думаю, что без программирования на языках для которых существуют компиляторы можно было бы и обойтись если бы создать курс объясняющий технику алгоритмизации не на бытовом уровне. Согласен с МИхаилом Эдуардовичем и в том, что понятие алгоритма должно быть связано с исполнителем. Это необходимо для согласования со сторогой теорией на которую все же не вредно равняться. Для реализации курса алгоритмики все же нужен язык.

Я несколько лет назад задумался над этой проблемой (алгоритмика без программирования и язык для неё), и думаю до сих пор. Основные идеи у меня тут такие:

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

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

Для всех элементов введенного множества чисел делать
Тело цикла

Впрочем оборву здесь изложение идей, если кому интересно может посмотреть нашу коллекцию алгоритмов на www.lotos-khv.narod.ru, мы уже пользуемся таким мета - языком. Конечно он еще не устаканился, поэтому чтение алгоритмов может вызывать ощущение отсутствия стандарта.

Что - же касается алгоритмики. Уверен, что отправным пунктом должно стать понятие Исполнителя. А саму алгоритмику можно написать как многоуровневый предмет на каждом уровне которого понятие Исполнителя понимается все более строго.
s11kai ( Пользователь )
(Galagan Sergei Igorevich @ 08.04.2007, 05:30) <{POST_SNAPBACK}>
Касаемо анимаций и рисования, черчения на компьтере, то здесь не вижу противопоказаний ни в одном профиле, возможно только для желающих, но навык не повредит никому, решительно полезно.


В том то и дело, что современные технологии ушли на столько далеко, что понятия, которые были доступны еще вчера каждому, сегодня приобретают совершенно иной смысл. Например, анимацию, составленную учеником 8 класса в ppt и 11 классником - созданную во Flash, уже но поставить на одну ступень- судите сами:

Сейчас опубликую ролик и продолжу мысль
s11kai ( Пользователь )
Вот пример ролика (еще не оконченного) демонстрирующего или объясняющего сразу два понятия

http://somit.ru/flash_3/luna.htm

1 - почему Луна всегда смотрит на землю одной стороной
2 - геометрическое объяснение сходства колебательного движения с вращательным.

На первый взгляд это графика и чего тут ломать голову. Но взгляните на содержание двух маленьких фрагментов изнутри:

фрагмент 1:

var k=0
var ugol = 0;
var radiusY = 200;
var radiusX = 200;
this.createEmptyMovieClip("triangle", 0);
this.onEnterFrame = function() {
ugol += k;
rad = ugol*Math.PI/180;
luna._x = 400+radiusX*Math.cos(rad);
luna._y = 250+radiusY*Math.sin(rad);
with (triangle) {
clear();
lineStyle(4, 0xFF00FF, 100);
moveTo(400, 250);
lineTo(luna._x, luna._y);
lineTo(luna._x, 250);
lineTo(400, 250);
}
};

Скажите, та ли это графика, которую мы привыкли видеть и на сколько понятно ее содержимое?
Т.е. я хочу спросить, будет ли данная графика понятна простому – неподготовленному человеку?
Сможет ли он понять, что именно здесь нарисовано!

Скорее всего нет!

Но, программист, даже не знакомый с данным языком или средой поймет, что она означает (или, вернее, что делает данный код).

ОТСЮДА И ВОЗНИКАЕТ НОВЫЙ ВОПРОС, почему же это нельзя назвать программой?

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

Операторы графики - ясно, что это розовый треугольник, демонстрирующий изменения проекции на ось Х, но не статический - нарисованный, а динамический, выполняемый исполнителем по строгому соответствию с алгоритмом и перестраиваемый им в зависимости от времени!!!

Попробуй внеси спонтанные изменения - и все, работать не будет!
s11kai ( Пользователь )
фрагмент 2:

on (press, keyPress "<Space>") {
if (k == 0) {
k = 1;
} else {
k = 0;
}
}

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

Да, я не могу научить ребенка писать самостоятельно обработчик событий, но не будем забывать, что у меня всего 64 часа.
С учетом того, что мне еще предстоит научить его работать с офисным пакетом, познакомить с возможностями WWW, дать понятие БД, сканировать и обрабатывать графику, затем использовать ее в ppt,не говоря уже о истории развития компьютера ,назначении отдельных его частей, инсталяции и архивации и т.д.


(Михаил Густокашин @ 06.04.2007, 04:00) <{POST_SNAPBACK}>
в разработке визуализации физического процесса участвует много людей. физик (вообще, их наверно несколько, я не специалист) придумывает модель процесса, математик упрощает формулы, специалист по алгоритмам (прикладной математик, видимо) придумывает структуры данных и т.п., системный программист разрабатывает эффективную программу, специалист по компьютерной графике реализует визуализацию (тут уже полно разных пакетов и данные можно сунуть в какой-то готовый).
это нормальный процесс разработки программы, моделирующей какую-либо физическую систему с наглядной визуализацией и другими данными о системе (таблицы, графики и пр.).
естественно, какие-то роли совмещаются, где-то что-то сдвигается в сторону, какие-то этапы выкидываются (что часто плачевно сказывается на результате).
если дети пишут визуализатор по конкретным полученным данным, то это программирование, хотя и довольно бестолковое, т.к. универсальных визуализаторов много, а специализированный дети вряд-ли напишут хорошо.
если дети рисуют флешку или гифку - то это не программирование ни разу.


Отюда и мой последний вопрос:

Скажите, пожалуйста, если ребенок один проделал всю работу, которую перечислил Михаил Сергеевич Густокашин и "нарисовал" , используя при этом в качестве инструментария не карандаш, а то же самое, что и программист, причем суть данного "творения" способен понять также только программист,

ПОЧЕМУ ЭТО - "НЕ ПРОГРАММИРОВАНИЕ НИ РАЗУ "

и мне не понятно,

в чем здесь проссматривается "ПЛАЧЕАВНОСТЬ РЕЗУЛЬТАТА"?

Может быть все дело в том, что иногда, мы позволяем себе судить то, о чем не имеем понятия, например, о возможностях Flash или, скажем, о современной, программируемой, а не "РИСОВАННОЙ ГРАФИКЕ"
И честное слово, я ни кого не желал и не желаю обидеть, я просто хочу понять, чего я не учитываю или не понимаю!

(Потопахин Виталий @ 06.04.2007, 17:48) <{POST_SNAPBACK}>
В программировании уровень абстракции не ниже чем в математике, но математика у детей с первого класса и их к этой абстракции готовят очень медленно и то для многих понятия математики большая проблема. У нас же как с обрыва в омут. Графика помогает смягчить удар. Вроде бы те же циклы, те же присваивания, но результат видно визуально, это сильно помогает.


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



Спасибо!
Виталий Потопахин ( Пользователь )
Вы Александр Иванович не стоите у истоков, а развиваете параллельную технологию. Я бы так сказал. Дело в том, что программирование это не формальный термин и каждый волен понимать его как угодно. В настоящее время под программированием понимают и разработку баз данных и программирование графики тиа flash-action. Кстати в нашу первую встречу я не признал за флэш право на наш термин, но честно признался, что флэш мне незнаком. А человек я в общем-то добросовестный и с той поры потратил некоторое время на изучение флэш, так вот мое мнение укрепилось. Дело в том, что мое параллельное понимание программирования это программирование как раздел прикладной математики, продукт которой предполагает построение формальной модели прежде всего. Тут я с Густокашиным полностью солидарен. Программируемая графика на флэш-акшион в это понимание не попадает. Но вы вполне можете называть свои работы программированием в каком-то своем смысле. Дело только в том, что наш смысл более общепринят в среде специалистов, даже тех кто базы делает.

Несколько небольшим замечаний.

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

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

Кстати у нас в Хабаровске есть человек который считает, что я не занимаюсь программированием. Дело в том, что кроме прикладного программирования есть еще системное. Оно занимает в моем процесс менее 10%, а этот мой знакомый полагает, что чистое программирование это только системное, а язык достойный изучения это язык ассемблера

footer logo © Образ–Центр, 2019. 12+