OberonCore

Вы неправильно понимаете термин "критическое".

Допустим. А как правильно?

Возможно, Вы правы в той части, что рефлексия не обязательно связана с критикой, а может ограничиваться самонаблюдением. В то время как критика (как правило) предполагает сопоставление с неким образцом (иногда абстрактным; например с основными принципами логики).
Вместе с тем, исключительно внешняя направленность критики вызывает сомнение.
Ассоциация "критический-рефлективный" возникла у меня по двум причинам.
1. По исторической. Весной 2006г. Федор Васильевич читал у нас в Зеленограде (в МИЭТ) лекцию, где (если память меня не подводит -- "врет как очевидец" ) использовал-таки для второго уровня слово "критический".
2. Я пытался (тут, правда, получился "первый блин" ) выразить мысль, что одной из основ самостоятельного мышления является сочетание критики и рефлексии (самокритика).

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

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

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

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

П.С.

Вот такая вот бредятина.

Да, это, видимо, именно то, что подразумевается в "теории двух уровнетипов ума" для второго типа.

Недавно имел интересный разговор.

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

говорю ему - могу тебя научить программированию, а к олимпиадам я не готовлю.

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

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

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

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

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

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

Проект учебника по КП

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

Часть 1. Неформальное введение

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

Цель - введение в язык, недостаточное для систематического знания, но достаточное для хорошего представления и написания простеньких программ.

Каждая глава данной части снабжается заданиями двух типов:

1) Дан пример надо пояснить его действие.
2) Простенькая программа

Содержание:

Глава 1. Первая задача.

Решается достаточно содержательная, но не сложная задача. Разбор и запись алгоритма ведется на псевдокоде. Содержание задачи таково, что для её решения необходимы операции ввода/вывод, циклы, условные конструкции. После того, как получена запись алгоритма поясняется почему это не является строгим решением, это можно сделать, показав например неоднозначности записи. Это можно оформить, как рассуждение о различии между псевдокодом и языком программирования. Запись задачи должна быть такова, чтобы переход от пседокода к программе получился почти точным переводом. Из структур данных в первой задаче достаточно типа INTEGER. Псевдокод в этой части будет использоваться регулярно. Во второй части псевдокода уже не будет.

Глава 2. Структура программы

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

Глава 3. Основные конструкции

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

Глава 3. простые типы данных.

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

Глава 4. Массивы и записи.

Краткая характеристика и примеры использования.

Глава 5. Файлы

Понятие о файле данных и пример.

Глава 6. Хороший пример.

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

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

Часть 2. Систематическое изложение

В соответствии с названием цель – системное знание. Задания к главам делятся на теоретические и практические. Задания первой части только практические. От первой части отличаются конечно уровнем сложности.


Глава 1. Синтаксис и семантика языка программирования

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

Глава 2. Структуры данных и операции

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

Глава 3. Конструкции языка

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

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

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

Глава 4. Указатели и связные списки

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

Глава 5. Структура модуля.

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

Глава 6. Языковые характеристики в применении к КП: гибкость, надежность, читаемость, возможно другие, хотя и этих качеств будет вполне достаточно.

Глава 7. Хороший пример.

Достаточно большой пример способный показать достоинства языка.

По-моему, вполне нормально.

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

Согласен с Ильей, процедуры с передачей 1-3 параметров по значению надо давать довольно рано. Причем поначалу можно ограничиться пояснением на интуитивном уровне, не затрагивая формальностей. Дело в том, что в КП-версиях черепашки у многих команд есть параметры и детки (8-9 кл) их достаточно быстро и совершенно нормально привыкают использовать и постепенно понимать. Думаю, не будет проблем и с меньшим возрастом. Без возможности декомпозиции алгоритма на процедуры - скучно и неправильно. Успешно попробовавши "запроцедуривание" и почуяв, где можно сэкономить на тупой работе и показать свою крутизну, детки быстро входят во вкус и сами начинают активно "процедурить". Да и организация даже простых диалогов с парой командных кнопок без пары процедур никак не обойдется. Так что бояться рано вводить процедуры не стОит.

Да и рекурсию без них не объяснить.

Принципиально согласен о более раннем введении процедур с параметрами. Должен сказать, что в моем базовом курсе старого паскаля процедуры вводятся почти сразу. Здесь я временно остановился на таком варианте, была вроде мысль. Но мысль кажется не вполне состоятельна. И насчет рекурсии Trurl прав, кстати в черновых набросках о рекурсии пока вообще ни слова. А есть и дополнительное соображение. если я хочу (а я таки хочу) приучать мыслить структурно, то наверное о процедурах, как инструменте структурирования программы надо говорить пораньше. Но тут проблема - структурное программирование достаточно серьезная концепция, так что видимо подход к нему в первой интуитивной части и во второй системной будет разным и соответственно введение процедур все равно будет разным если не по времени, то по методике.

Наверное, подходы и правда будут разными.
Но вряд ли стоит так беспокоиться.
Мне кажется (может, это и наивная точка зрения), что структурное программирование совершенно естественно выросло из блочной структуры Алгола (т.е. даже немного запоздало). Оставалось только выкинуть goto (на основании теоремы Боэма-Джакопини, кажется).
А цель блочной структуры, как и модульности, -- реализация принципа "разделяй и властвуй" (локальные переменные и т.п.). Ну и рекурсия, конечно, о чем сказал Трурль (все-таки Алгол создавался математиками).
Вопрос: надо ли ограничиваться на первых порах только перечислением языковых конструкций или стоит разъяснять их смысл? (Например, зачем нужен цикл REPEAT UNTIL, ведь уже есть цикл WHILE. Вирт, кстати, дает такое объяснение.)
И еще. Будут ли разъясняться в неформальной части (или дальше) базовые приемы программирования (поэтапное уточнение деталей, сокрытие информации и т.п.)?

Кстати, недавно узнал, что теор. обоснование структурного программирования было сделано уже в 60-м В.М. Глушковым, просто не было замечено:

http://computer-museum.ru/galglory/27.htm

А блочную структуру программ тоже впервые ввёл Ляпунов в 50-х...
Как же интересно, что всегда в разных частях света мысли текут хоть и по несколько разным руслам, но в параллельных направлениях...

Ну так серьёзные проблемы всемирно известны (обычно), соответственно, ими могут заниматься параллельно в разных местах.

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

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

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

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

В своем курсе я по кр. мере про это говорю -- да и кучу примеров в раздаточном материале студентам приходится читать.

Что еще можно придумать? "что делает эта процедура?"

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

Если учитывать, что человек в своей кратковременной памяти может держать 6-8 объектов, то метод раскрутки (натыкаемся на процедуру - исследуем её код, если там есть процедуры - исследуем и их) не сможет дать быстрого результата. Если в цикле есть две такие процедуры, то мы забываем назначение первой после раскутки второй.

Есть ли способ узнать, что делается в цикле, не анализируя его? Иногда да, если можно вычленить инвариант. Также, расположение процедуры внутри определённого модуля (назначение которого известно) может дать ответ на вопрос о её назначении без подробного анализа. Что-нибудь ещё в этом духе.

Или подобным вещам не должны обучать?

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

Далее о чтении и писании. Я не хочу разделять эти вещи. Безусловно надо учить читать и тратить на это не меньше времени, чем на писание. Писание это делание, а чтение это понимание. Понимание более важно.

И еще одно важное уточнение. Я на самом деле разделяю учебники на два типа. НА учебники программирования и учебники языка. То что я изложил это концепция учебника языка. Это легче. Но вообще-то я думаю о учебнике программирования. А лично для меня программирование существует в двух ипостасях:
1) Программирование это метод мышления.
2) Программирование это раздел прикладной математики.

Так что я полагаю, что исходная концепция сильно изменится.