Ответ на »сообщение 3087« (AK)
___________________________

Ответ на »сообщение 3085« (Руслан Богатырев)
Так вот - эксперименты показывают, что при обучении программированию наиболее эффективный путь с точки зрения качества и затраченного времени - использование графических средств (причем от бумажных _схем_ до компьютерных алгоритмов), а от них переход к текстовому представлению. Причем, свободное решение задачи в любом из этих видов и свободный контексный переход между разными видами является одним из важнейших критериев освоения программирования.

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

Ответ на »сообщение 3097« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 3084« (Илья Ермаков)
___________________________
Хоть горшком назовите. В моем представлении это графика, а не текст. Но если Вы ратуете за ТАКОЙ текст, то я тоже только "за".
В моем представлении текст - то, что не картинка.
А графика в тексте тоже может использоваться: цветной текст с разным оформлением - уже простая графика.

Ответ на »сообщение 3087« (AK)
___________________________
Уж извините, но смотрю на проблему представления алгоритма с колокольни первичного обучения программированию школьников. Так вот - эксперименты показывают, что при обучении программированию наиболее эффективный путь с точки зрения качества и затраченного времени - использование графических средств (причем от бумажных _схем_ до компьютерных алгоритмов), а от них переход к текстовому представлению.

Опять таки сначала нужно определить цель. Кого и чему хотим научить.

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

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

Ответ на »сообщение 3081« (Geo)
___________________________
Но уже сейчас многие типовые решения настолько проработаны, что достаточно сложные конструкции получаются вообще без написания кода (визарды, схемы состояний, диаграммы связей и т.п.). И почему не может быть дальнейшего движения на этом пути, когда манипулирование переменными и написание обработчиков событий отомрет примерно так же, как сейчас отмирает работа с регистрами процессора и управление стеком?
При переходе к ЯВУ и структурному программированию мы наложили на программиста множество ограничений. Но было доказано, что оставленный ему набор приемов обеспечивает ПОЛНОТУ, т.е. не сужает класс решаемых задач.
Да, допускаю, что для решения каких-то специфических задач могут и в этом случае потребоваться нынешние языки программирования.
Значит новые навароты полноты не обеспечивают...
Они могут быть полезны, но не вместо, а вместе с ЯВУ.

Это то, что касается специального представления для конкретных типов задач.

Что касается "программирования общего назначения", то сравнения и присваивания никто не пытался представить графически - достается только операторным скобкам :)
На мой взгляд отступов вполне достаточно для наглядности.
Подсветка синтаксиса помогает.
Ну еще соединить операторные скобки линиями полезно.
Все это текст (скажем: "текст с элементами графического оформления").
Причем все это можно сделать автоматически - не нравится оформление чужого текста, одним нажатием кнопки приведем к привычному виду.

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

Так что если вы и разрабатываете процессные описания пользуясь только табличным представлением, то я не знаю: то ли вами восхищаться, то ли жалеть ;-)
Естественно, восхищаться! :-P
Если серьезно, то дело в том, что для значительного класса задач по управлению дискретными технологическими системами, было выделено инвариантное ядро, для которого были разработаны структуры данных и алгоритмы решений. Таким образом, создание конкретной системы управления сводилось к заполнению БД стандартной структуры и написанию некоторого количества "обработчиков событий".
Рисовать каждый раз одну и ту же схему нет никакого смысла :)
 

Ответ на »сообщение 3095« (Сергей Прохоренко)
___________________________

Если до конца следовать Вашей логике, то первичны машинные коды.

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

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

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

Имеет. Вернитесь к моему »сообщение 3090« и ответьте на прямо поставленный вопрос. Ответ сразу покажет что к чему.

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

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

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

Следующий шаг вперед - представление программы в форме комбинации графики и текста, обеспечиваемой средствами системы программирования.

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

Ответ на »сообщение 3084« (Илья Ермаков)
___________________________

Ответ на »сообщение 3081« (Geo)
___________________________

Так что если вы и разрабатываете процессные описания пользуясь только табличным представлением, то я не знаю: то ли вами восхищаться, то ли жалеть ;-)
Таблица - это удобный и ёмкий способ представления, между прочим.
Попробуйте забавы ради нарисовать орграф импорта для нескольких десятков модулей, расслоив их на уровни.
В Блэкбоксе такой инструмент есть - Info->Show dependencies.
Жуткая мешанина линий, в которой трудно разобраться.
Совершенно иной расклад - разместить модули по уровням в таблице.
Табличку сделать интерактивной - по щелчку на ячейке подсвечиваются зоны прямого и косвенного импорта.
Очень удобно и наглядно. У нас такой инструмент есть, скоро опубликуем.

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

Хоть горшком назовите. В моем представлении это графика, а не текст. Но если Вы ратуете за ТАКОЙ текст, то я тоже только "за".

Ответ на »сообщение 3077« (Сергей Прохоренко)
___________________________


+1 ;-)
Согласен практически по всем пунктам, за исключением, может быть, непринципиальных деталей. Типа, "Эта комбинация должна автоматически преобразовываться в исходный текст программы". Теоретически нет необходимости в промежуточном этапе в виде текста программы на ЯВУ, комбинация графики и текста (и, может быть, чего-то еще) может сразу переводиться в набор машинных команд.



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

Ответ на »сообщение 3080« (Руслан Богатырев)
___________________________

Ответ на »сообщение 3077« (Сергей Прохоренко)
___________________________

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

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

Остаются формальные текст и не-текст. А теперь попробуйте объяснить, что такое формальный не-текст (комбинация текста, графики, возможно -- звука). Видимо, это какой-то набор правил... (раз формальный). Эти правила представляются формальным языком (текстовым). Или как-то иначе? Так что первично?

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

Ответ на »сообщение 3091« (Geo)
___________________________

Руслан, Вы, прямо-таки, инквизитор: так и выкручиваете руки ;-) Ответ: не всегда.

Я уже понял, что в душе Вы со мной уже согласны. :)

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

Впрочем, я попутно сформулировал принцип, которого намерен твердо придерживаться в отношении проекта ОС "Роса" (первичность текста, наличие текстового языка для каждого графического).

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

Для каждого формального "графического" языка (языков спецификаций, языков моделирования) у нас ВСЕГДА будет соответствующий текстовый эквивалент. Мы изучаем самые разные варианты на сей счет -- и помощь в этом деле со стороны была бы нелишней. ДРАКОН(ы) -- лишь один из изучаемых вариантов. Впрочем, история его создания (подноготная, так сказать) весьма интересна:  http://www.transhumanism-russia.ru/content/view/331/116

Ответ на »сообщение 3092« (panda)
___________________________
Прокололся я ;-) Просто никак не получается воспринимать MS Access как СУБД. Рассматриваю как составную часть MS Office неравне с MS Word и MS Excel. То есть забываю, что движок отделим от оболочки. А в оболочке как-то ни разу не писал запросы DDL. И метаданные не просматривал в виде текста. Нужды такой не было.