OberonCore
https://forum.oberoncore.ru/

Семантический редактор
https://forum.oberoncore.ru/viewtopic.php?f=93&t=1542
Страница 1 из 34

Автор:  Сергей Прохоренко [ Понедельник, 27 Апрель, 2009 19:29 ]
Заголовок сообщения:  Семантический редактор

Модератор: Перенесено. Инициирующее сообщение: viewtopic.php?p=28624#p28624
Валерий Лаптев писал(а):
По поводу часто ненужного обобщения.
Задаю студенту диплом: Сделай мне структурный редактор для Pascalя


А что такое структурный редактор, если не секрет?

Автор:  Валерий Лаптев [ Вторник, 28 Апрель, 2009 11:04 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):
Валерий Лаптев писал(а):
По поводу часто ненужного обобщения.
Задаю студенту диплом: Сделай мне структурный редактор для Pascalя


А что такое структурный редактор, если не секрет?

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

Автор:  Сергей Прохоренко [ Вторник, 28 Апрель, 2009 19:17 ]
Заголовок сообщения:  Re: Теория двух типов ума

Валерий Лаптев писал(а):
Сергей Прохоренко писал(а):
Валерий Лаптев писал(а):
По поводу часто ненужного обобщения.
Задаю студенту диплом: Сделай мне структурный редактор для Pascalя


А что такое структурный редактор, если не секрет?

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


Это очень интересно :!: :!: :!: Это как раз то, что я много раз предлагал на форумах OberonCore (под именем "построитель кода") и раньше на Королевстве Дельфи и в блоге Евгения Зуева, даже в деталях. Кому-то понравилась идея, другие с порога отвергли. Но никто не взялся делать. Сейчас я обобщаю и перерабатываю свои материалы по этой теме, чтобы опубликовать на своем сайте. Я думаю, мне потребуется месяц или два. Если у Вас есть что-то по этому вопросу, мы могли бы это обсудить в новой ветке форума.

Автор:  Валерий Лаптев [ Среда, 29 Апрель, 2009 12:12 ]
Заголовок сообщения:  Re: Теория двух типов ума

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

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

Автор:  Сергей Прохоренко [ Среда, 29 Апрель, 2009 20:36 ]
Заголовок сообщения:  Re: Теория двух типов ума

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

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


Желаю Вам успеха! Мои материалы по этой теме будут на сайте http://sites.google.com/site/noflowchart максимум месяца через два - посмотрите. В моем понимании конструктор кода должен иметь соответствующие инструменты для автоматизации проектирования, кодирования и отладки на шести уровнях модели:
1. Библиотека модулей
2. Программа
3. Модуль
4. Раздел модуля
5. Блок нижнего уровня
6. Элемент

Автор:  Валерий Лаптев [ Четверг, 30 Апрель, 2009 13:36 ]
Заголовок сообщения:  Re: Теория двух типов ума

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

Цитата:
Желаю Вам успеха! Мои материалы по этой теме будут на сайте http://sites.google.com/site/noflowchart максимум месяца через два - посмотрите. В моем понимании конструктор кода должен иметь соответствующие инструменты для автоматизации проектирования, кодирования и отладки на шести уровнях модели:
1. Библиотека модулей
2. Программа
3. Модуль
4. Раздел модуля
5. Блок нижнего уровня
6. Элемент

Спасибо!
1. Что понимается под элементом и блоком нижнего уровня?
2. В моем понимании Программа - это гипертекст, в котором операторы import служат гиперссылками.
3. Библиотека модулей - см. ББ - тут уже все есть. Модуль - см. ББ, тоже все есть.
Непонятен смысл раздела модуля. Типа раздел определений, раздел реализации?

Автор:  Сергей Прохоренко [ Четверг, 30 Апрель, 2009 22:03 ]
Заголовок сообщения:  Re: Теория двух типов ума

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

Желаю Вам успеха! Мои материалы по этой теме будут на сайте http://sites.google.com/site/noflowchart максимум месяца через два - посмотрите. В моем понимании конструктор кода должен иметь соответствующие инструменты для автоматизации проектирования, кодирования и отладки на шести уровнях модели:
1. Библиотека модулей
2. Программа
3. Модуль
4. Раздел модуля
5. Блок нижнего уровня
6. Элемент

Спасибо!
1. Что понимается под элементом и блоком нижнего уровня?
2. В моем понимании Программа - это гипертекст, в котором операторы import служат гиперссылками.
3. Библиотека модулей - см. ББ - тут уже все есть. Модуль - см. ББ, тоже все есть.
Непонятен смысл раздела модуля. Типа раздел определений, раздел реализации?

Под элементом понимается, в частности, переменная, для которой имеется таблица свойств. Возможны и другие варианты.
Под блоком понимается графический эквивалент управляющей конструкции языка (цикла, оператора switch и т.п.).
И в моем понимании программа, как ее видит программист на мониторе, - это гипертекст, в котором операторы import служат гиперссылками. Но только не единый кусок гипертекста, а несколько окон, соответствующих разным уровням представления модели. Для каждого уровня модели нужны специфические графические средства представления (раскрывающийся список, сетевая диаграмма (граф), таблица, вложенные блоки) и специфические средства манипулирования графическими объектами (конструкторы, инструменты). В то же время, программа сохраняется как XML-документ, с которым программист напрямую (в текстовом редакторе) работать не должен, чтобы не внести трудноуловимых ошибок.
Конечно, в ББ есть модули и библиотеки модулей, и это замечательно. Но только кроме куцых подсистем в ББ нет никаких (тем более, графических) средств манипулирования модулями. В Component Pascal IDE v2.0 Aug 2007 есть хотя бы механизм автоматической сборки зависимых модулей в компилируемую программу - см. http://cfbsoftware.com/cpide/cpide.htm Правда, мне компиляция не удалась.
Разделы модуля в Оберонах уже есть: раздел объявлений, раздел исполнения команд, начинающийся словом Begin. Но, очевидно, набор разделов должен быть переработан, чтобы соответствовать специфике графического конструктора кода. Набор разделов должен стать жестким графическим каркасом модуля.

Я писал на работе по памяти, поэтому получилось не очень понятно. Вот уровни модели более подробно:
Уровень 1 – «библиотека» (таблица модулей; средства создания, разделения, слияния и переименования модулей и ведения версий; средства доступа, поиска, справки и обучения)
Уровень 2 – «программа» (раскрывающийся список и сетевая диаграмма (граф) зависимостей модулей и элементов; средства выбора платформы и транслятора; точки и параметры запуска программы)
Уровень 3 – «модуль» (раскрывающийся список обязательных разделов; внутреннее XML-представление)
Уровень 4 – «раздел модуля» (вложенные блоки; последовательное или произвольное/параллельное исполнение команд; инструменты построителя блоков; конструктор GUI)
Уровень 5 – «блок нижнего уровня вложенности» (таблица элементов; инструменты построителя выражений)
Уровень 6 – «элемент» (таблица свойств)

Автор:  igor [ Пятница, 01 Май, 2009 09:03 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):
см. http://cfbsoftware.com/cpide/cpide.htm Правда, мне компиляция не удалась.
Там используется внешний по отношению к самой IDE компилятор GPCP. Его нужно скачать и установить отдельно, а в CPIDE прописать путь к компилятору GPCP. После этого всё компилируется. Да, чуть не забыл, .NET v2.0 тоже должен быть установлен. Он нужен для GPCP v1.3-NET.

Автор:  Валерий Лаптев [ Суббота, 02 Май, 2009 09:03 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):
Под элементом понимается, в частности, переменная, для которой имеется таблица свойств. Возможны и другие варианты.
Под блоком понимается графический эквивалент управляющей конструкции языка (цикла, оператора switch и т.п.).
И в моем понимании программа, как ее видит программист на мониторе, - это гипертекст, в котором операторы import служат гиперссылками. Но только не единый кусок гипертекста, а несколько окон, соответствующих разным уровням представления модели. Для каждого уровня модели нужны специфические графические средства представления (раскрывающийся список, сетевая диаграмма (граф), таблица, вложенные блоки) и специфические средства манипулирования графическими объектами (конструкторы, инструменты). В то же время, программа сохраняется как XML-документ, с которым программист напрямую (в текстовом редакторе) работать не должен, чтобы не внести трудноуловимых ошибок.
Конечно, в ББ есть модули и библиотеки модулей, и это замечательно. Но только кроме куцых подсистем в ББ нет никаких (тем более, графических) средств манипулирования модулями. В Component Pascal IDE v2.0 Aug 2007 есть хотя бы механизм автоматической сборки зависимых модулей в компилируемую программу - см. http://cfbsoftware.com/cpide/cpide.htm Правда, мне компиляция не удалась.
Разделы модуля в Оберонах уже есть: раздел объявлений, раздел исполнения команд, начинающийся словом Begin. Но, очевидно, набор разделов должен быть переработан, чтобы соответствовать специфике графического конструктора кода. Набор разделов должен стать жестким графическим каркасом модуля.

Я писал на работе по памяти, поэтому получилось не очень понятно. Вот уровни модели более подробно:
Уровень 1 – «библиотека» (таблица модулей; средства создания, разделения, слияния и переименования модулей и ведения версий; средства доступа, поиска, справки и обучения)
Уровень 2 – «программа» (раскрывающийся список и сетевая диаграмма (граф) зависимостей модулей и элементов; средства выбора платформы и транслятора; точки и параметры запуска программы)
Уровень 3 – «модуль» (раскрывающийся список обязательных разделов; внутреннее XML-представление)
Уровень 4 – «раздел модуля» (вложенные блоки; последовательное или произвольное/параллельное исполнение команд; инструменты построителя блоков; конструктор GUI)
Уровень 5 – «блок нижнего уровня вложенности» (таблица элементов; инструменты построителя выражений)
Уровень 6 – «элемент» (таблица свойств)

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

Автор:  Сергей Прохоренко [ Суббота, 02 Май, 2009 18:27 ]
Заголовок сообщения:  Re: Теория двух типов ума

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


:D Рад, что есть единомышленники. К сожалению, на этом форуме процентов 80 участников думают, что программист должен работать с текстом (оценка 80% грубая, никаких опросов не было). Единственное, в чем они отклоняются от своего догмата - это любовь к "Дракону", навеянная теплыми воспоминаниями о космической программе "Буран", военно-промышленном комплексе и былом могуществе державы. :roll:
Но "Дракон", конечно, совсем не то, прошлый век. :(
Да, и еще они с гордостью называют гипертекст красивым словом "активный объект", то есть ощущают необходимость гиперссылок в коде программы.

Мне кажется, что уровни выше модуля нужны и для обучения - по следующим причинам:
1. Имеет смысл обучать сразу правильной технологии работы:
1.1 Проектирование модели сверху вниз с разбиением на модули по функционалу, используемым ресурсам и степени зависимости от той или иной платформы
1.2 Помодульная отладка с локализацией ошибок
1.3 Работа с библиотеками, поиск и использование готовых компонентов вместо изобретения велосипеда
1.4 Создание и оформление компонентов для многократного использования в других проектах и на продажу

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

2. Обучаемому может быть тяжело без поддержки верхних уровней модели системой программирования:
2.1 По мере обучения кавардак из собственных модулей может стать существенной помехой, как и отсутствие удобных средств работы с библиотеками
2.2 Сборка программы из модулей (собственных или библиотечных), зависимых друг от друга по цепочке, может стать довольно сложной задачей
2.3 Целостность программы может быть легко нарушена, если в одни модули вносятся исправления (даже переименования!) без учета других, а средства автоматического поддержания целостности отсутствуют

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

Автор:  Пётр Кушнир [ Суббота, 02 Май, 2009 20:40 ]
Заголовок сообщения:  Re: Семантический редактор

А широкий ли класс задач сможет покрыть такого типа редактор? Не получится ли в итоге, что выгоднее использовать утилитарные генераторы шаблонного кода из псевдо-языка, или ДРАКОН-схем(сопоставляем элемент схемы с куском кода и вуаля)? Насколько трудно будет использовать в таком редакторе сторонние готовые компоненты? И ещё, как мне показалось из всего вышесказанного в плане описания редактора, присутствует паразитное смешивание мыслей "за концепт" и "за реализацию". Например, обсуждаются сущности и тут же про формат XML. :( По себе знаю, что после реализации таких задумок получается винегрет(ну, конечно, это только моё мнение).
Сергей Прохоренко писал(а):
К сожалению, на этом форуме процентов 80 участников думают
Следует понимать, что это плохо? :)
Сергей Прохоренко писал(а):
гипертекст красивым словом "активный объект"
Извините, я знаком с другим значением понятия "активный объект". Не поясните своё значение?
Сергей Прохоренко писал(а):
Мне кажется, что уровни выше модуля нужны и для обучения - по следующим причинам
В случае ББ - модуль несёт определённый смысл, как единица распространения. Насколько я знаю, "над" модулями условно обозначены подсистемы. Да, были мысли по поводу обустройства над подсистемами уровня "проект", который, чисто утилитарно, помог бы отслеживать проблемные места, связанные с отсутствием в среде контроля над модулями. Опять же, это всё предназначено для облегчения жизни, но никак не для обязательного использования.
Сергей Прохоренко писал(а):
Мне кажется, что уровни выше модуля нужны и для обучения - по следующим причинам:
Есть подсистемы. Выше модуля в среде ББ есть подсистемы. Всё, что в списке мне кажется высосаным из пальца. Не вижу, как введение ещё одной сущности поможет избежать вело-кода :) или поможет не устроить из модулей бардак. Все описаные "проблемы" от головы, а не от "неуправляемых" модулей.

Автор:  Илья Ермаков [ Суббота, 02 Май, 2009 21:45 ]
Заголовок сообщения:  Re: Семантический редактор

Пётр Кушнир писал(а):
И ещё, как мне показалось из всего вышесказанного в плане описания редактора, присутствует паразитное смешивание мыслей "за концепт" и "за реализацию". Например, обсуждаются сущности и тут же про формат XML.

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

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

Автор:  Илья Ермаков [ Суббота, 02 Май, 2009 21:58 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):
2. Обучаемому может быть тяжело без поддержки верхних уровней модели системой программирования:
2.1 По мере обучения кавардак из собственных модулей может стать существенной помехой, как и отсутствие удобных средств работы с библиотеками
2.2 Сборка программы из модулей (собственных или библиотечных), зависимых друг от друга по цепочке, может стать довольно сложной задачей
2.3 Целостность программы может быть легко нарушена, если в одни модули вносятся исправления (даже переименования!) без учета других, а средства автоматического поддержания целостности отсутствуют

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


Тут бы можно посмотреть на модель выделения "однородных наборов" Горбунова-Посадова: http://www.keldysh.ru/softness/gorbunov/public.htm (вот конкретная статья - http://www.osp.ru/os/2000/10/178257/)
Пока ничего более конкретного на эту тему я не видел.

Автор:  Сергей Прохоренко [ Воскресенье, 03 Май, 2009 17:39 ]
Заголовок сообщения:  Re: Теория двух типов ума

Илья Ермаков писал(а):
вот конкретная статья - http://www.osp.ru/os/2000/10/178257/


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

Вложения:
.png
.png [ 6.87 КБ | Просмотров: 26950 ]

Автор:  Валерий Лаптев [ Понедельник, 04 Май, 2009 08:57 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):

:D Рад, что есть единомышленники. К сожалению, на этом форуме процентов 80 участников думают, что программист должен работать с текстом (оценка 80% грубая, никаких опросов не было). Единственное, в чем они отклоняются от своего догмата - это любовь к "Дракону", навеянная теплыми воспоминаниями о космической программе "Буран", военно-промышленном комплексе и былом могуществе державы. :roll:
Но "Дракон", конечно, совсем не то, прошлый век. :(
Да, и еще они с гордостью называют гипертекст красивым словом "активный объект", то есть ощущают необходимость гиперссылок в коде программы.

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

Сергей Прохоренко писал(а):
Мне кажется, что уровни выше модуля нужны и для обучения - по следующим причинам:
1. Имеет смысл обучать сразу правильной технологии работы:
1.1 Проектирование модели сверху вниз с разбиением на модули по функционалу, используемым ресурсам и степени зависимости от той или иной платформы
1.2 Помодульная отладка с локализацией ошибок
1.3 Работа с библиотеками, поиск и использование готовых компонентов вместо изобретения велосипеда
1.4 Создание и оформление компонентов для многократного использования в других проектах и на продажу

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

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

Сергей Прохоренко писал(а):
2. Обучаемому может быть тяжело без поддержки верхних уровней модели системой программирования:
2.1 По мере обучения кавардак из собственных модулей может стать существенной помехой, как и отсутствие удобных средств работы с библиотеками
2.2 Сборка программы из модулей (собственных или библиотечных), зависимых друг от друга по цепочке, может стать довольно сложной задачей
2.3 Целостность программы может быть легко нарушена, если в одни модули вносятся исправления (даже переименования!) без учета других, а средства автоматического поддержания целостности отсутствуют

С этим я тоже согласен. Просто мы тут озабочены автоматизацией самого начального обучения программированию первокурсников. Для начала достаточно иметь одномодульные проги.
Но помимо редактора обучающая среда еще много чего должна содержать. Хотя бы интеллектуальную систему оценивания выполненной работы.

Автор:  Валерий Лаптев [ Понедельник, 04 Май, 2009 08:59 ]
Заголовок сообщения:  Re: Теория двух типов ума

Илья Ермаков писал(а):
Тут бы можно посмотреть на модель выделения "однородных наборов" Горбунова-Посадова: http://www.keldysh.ru/softness/gorbunov/public.htm (вот конкретная статья - http://www.osp.ru/os/2000/10/178257/)
Пока ничего более конкретного на эту тему я не видел.

У Горбунова-Посадова книжка есть.

Автор:  Valery Solovey [ Понедельник, 04 Май, 2009 11:26 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):
Мне кажется, что уровни выше модуля нужны и для обучения - по следующим причинам:
1. Имеет смысл обучать сразу правильной технологии работы:
Ну и кто Вам сказал, что она правильная?
Сергей Прохоренко писал(а):
1.3 Работа с библиотеками, поиск и использование готовых компонентов вместо изобретения велосипеда
Какая такая работа? Опять же, по "изобретению велосипеда", только уровнем выше. То есть, Вы ни от чего не избавились, но предложили понизить квалификацию программистов. Уж это-то точно неправильная технология.
Сергей Прохоренко писал(а):
2. Обучаемому может быть тяжело без поддержки верхних уровней модели системой программирования:
"Тяжело в учении - легко в бою". "Тяжело" бывает по-разному. Где гарантии, что Ваша идея не загубит будущее поколение программистов?
Сергей Прохоренко писал(а):
2.1 По мере обучения кавардак из собственных модулей может стать существенной помехой, как и отсутствие удобных средств работы с библиотеками
2.2 Сборка программы из модулей (собственных или библиотечных), зависимых друг от друга по цепочке, может стать довольно сложной задачей
2.3 Целостность программы может быть легко нарушена, если в одни модули вносятся исправления (даже переименования!) без учета других, а средства автоматического поддержания целостности отсутствуют
Это просто счастье! Вы даже не представляете, как я мечтаю о том времени, когда появятся эти "проблемы"! После этого моя жизнь стала бы гораздо спокойнее и определённее. Тот инструмент, который Вы описываете, полезен, если его правильно использовать. Но это сделать сложнее, чем писать программы исключительно через goto в блокноте. Правильно использовать - значит не забывать о его второстепенности.

goto я упомянул не зря. Этот инструмент при неправильном использовании точно также как и goto издевается над структурностью. Я имею возможность наблюдать, как работает десяток моих коллег: для них этот инструмент почти важнее программы, которую они в нём редактируют. И это создаёт мне такие проблемы, что описанные Вами "проблемы" - это просто песня.

Автор:  Valery Solovey [ Понедельник, 04 Май, 2009 11:28 ]
Заголовок сообщения:  Re: Семантический редактор

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

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

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

Автор:  Илья Ермаков [ Понедельник, 04 Май, 2009 17:31 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):
Неплохая статья. В чем-то совпадает с моим представлением.


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

Автор:  Сергей Прохоренко [ Пятница, 29 Май, 2009 20:43 ]
Заголовок сообщения:  Re: Теория двух типов ума

Сергей Прохоренко писал(а):

Мои материалы по этой теме будут на сайте http://sites.google.com/site/noflowchart максимум месяца через два - посмотрите.


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

Вот структурные редакторы, которые мне попались в интернете:
SymADE http://symade.tigris.org
SOP http://www.symade.com
СОКРАТ (отечественный проект закрыт, результаты якобы используются, но конкретики в интернете нет)
Цитата:
http://www.feedback.ru/yurix/articles/pottosin.htm :
Инструменты структурного конструирования включают структурный редактор, анализаторы статических свойств (наличия неиспользуемых объектов, информационных зависимостей в программе и пр.) и интерпретатора незавершенных программ, обнаруживающего свойства исполнения.
Теперешняя версия системы СОКРАТ разработана для языка Модула-2. однако большинство инструментов системы языково-независимо и ориентировано на класс языков со статическим контролем типов --- Модула-2, Оберон, Ада, С++. Определенная проработка погружения других входных языков ведется: на класс таких языков ориентирован внутренний язык и ряд процессоров обработки программ, структурный редактор является языково-настраиваемым и т.п.

MPS http://www.jetbrains.com/mps
IP http://www.intentsoft.com

:?: Кто-нибудь имел с ними дело? Позволяют ли они отказаться от текстового представления программы? Легко ли их приспособить для программирования на Обероне?

:?: Вопрос Валерию Лаптеву: соответствуют ли эти системы Вашему представлению о том, каким должен быть семантический редактор?

Страница 1 из 34 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/