OberonCore

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

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

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

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

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

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

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

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

"Просто редактор" - да, можно рассматривать в аспекте целевого назначения сам по себе, без "операторской триады" (пользователь-сервисник-администратор). В аспекте эргономики, ессно, любую сколь-нибудь сложную ТС не следует отрывать от человека-участника её полного ЖЦ - для чего и инжпсихология - но это уже часть функционального назначения, и мы сейчас, конечно, не об этом.
Такую же систему, которая "работает с семантикой и прагматикой" - т.е. интеллекто-имитирующую - уже нужно брать во взаимосвязи с человеком - как социотехническую (кстати, таковы же и банк, и <промышленное> предприятие типичные). Там тоже будут "противоположные интересы" - в виде неопределённости человеческого опыта в "предметке". Которая при отчуждении и передаче в семредактор выразится, допустим, в конфликтующих правилах базы знаний (и/или определениях одной предметной сущности).
Определённая концепция построения такого редактора ("вводящая в человеческие рамки" по Мичи и Джонстону) - да, при грамотном воплощении сделает его как подсистему прозрачней и обозримей для человека-оператора. Но говорить о "гораздой простоте" такого редактора самого по себе - как изделия программной инженерии - я бы не стал... Кстати, то же относится и к простоте его как продукта - не так-то просто реализовать удобные и гарантоспособные механизмы, скажем, для поддержки разрешения тех же конфликтов "отчуждённой неопределённости"...

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

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

И как следствие - чтобы редактор был, нужен всё-таки импер-инфор-язык (скажем, Оберон - или язык структурного редактора) - и его реализация (скажем, ББ - или прототип того же редактора). Другое дело - что если этот язык понимать в реализации как один из возможных "предметных" - можно редактор сделать постепенно "мультипредметным". И одновременно использовать его "предметные" возможности на пользу программирования - причём и самого редактора (о чём и говорилось в этом посте).

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

Пока что мы видим в группе Валерия - см. в этом посте - продумывание концепции деления "по языкам". Это равно необходимо - и взаимосвязано с делением по общности/формам знаний, формализуемых в редакторе. Для графит-метода у меня представление вырисовывается - отсюда и сказанное в этом посте. Но здесь многое будет по-другому - и из-за предполагаемой текстобазированности документов, и из-за "замаха" на имитацию интеллекта в предметных областях (и работу со всеми проектными языками внутри самого редактора - фактически подмену редактирующих функций любых СА[ПР] в соответствующей "предметке")... И тут надо уже учитывать и сказанное в этом посте (по п.2 - п.1 уже, как я вижу, предполагается).

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

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

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

А в чем по-вашему разница между моделью программы для интерпретатора и моделью программы для структурного редактора? Мне кажется, что первое есть просто основная часть второго. См. рисунок:

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

Интеграция - это да... Но я-то говорил именно о наведении связей по данным.

А это не интеграция?..

Когда с готовыми системами (и, возможно, сторонней разработки) - то в моём понимании скорее стык (иногда говорят о наложении - когда "что-то поверх чего-то").

Поверьте... на слово... обмен данными (связи по данным) - это один из вариантов интеграции.

Ну, если специально не упираться, как в последних фразах, то вполне полезно.

Однако ж есть разные ипостаси чисел: счётность и протяжённость... а ещё и векторность в перспективе

На мой взгляд, отличный пример визуализации в мультфильме "38 попугаев" - как раз всё, что нужно, легко и в игровой форме даётся! Если бы ТАК в школе учили!

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

Кстати, когда для создания приложения нужно на столь "передовые рубежи информатики" выдвигаться - IMHO, надо основываться на адекватно развитой теории интеллекта (и языка). Фёдор Васильевич здесь дал оценку одной из возможных теорий в сопоставлении с его собственной. Я же попробую более общую вещь сформулировать. Теория интенсификации рассматривает интеллект как "чёрный ящик", который из неких соображений, установленных методами "нормальной науки", можно "грамотно проектировать" подбором формы внешних воздействий данными. Главное соображение, как уже говорил где-то - гипотеза Уорфа. Лучше всего изложено в этой лекции Тер-Минасовой - она там практически с этого начинает (только не называя её так).
А теория, адекватная вызову "отчуждения над-синтаксического", должна, полагаю, иметь в основе "белый ящик" - т.е. модель механизмов мышления. И теория умотипов - попытка такую модель дать.
И можно видеть два "но" к существующему (и оформленному фактически теорией интенсификации в опубликованной версии) положению дел. Во-первых, в той же лекции опять же говорится о справедливости утверждения, обратного уорфову - т.е. что и мышление формирует язык. В некотором смысле весь Оберонкоре - утверждение необходимости нестихийности этого формирования в информатике. Во-вторых, есть ещё гипотеза "двойного кодирования" (Р. Солсо, кажется) - что мозг пользуется и вербальным, и невербальным представлением. В силу такого же понимания, наверное, и замечания автора теории о "драконолюбах".
И теория умотипов свои "но" добавляет - своё понимание высказывал здесь.
Отсюда не только то, что говорил в этом посте - но и необходимость так строить редактор, чтобы развивать способы определения предметных языков. И со многими вещами вообще подождать - пока вид "белого ящика" не определится вполне...

В принципе вопрос терминологический... так что почему бы не поверить?..

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

Всё зависит от того... что мы понимаем под числами? Если простой аналог количественной меры, то, возможно, Ваше утверждение справедливо. И то надо как-то доказать, что число 4 является частью числа 7... (отрицательные числа какой частью являются, например)...

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

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

Более интересно то, что эти самые системообразующие критерии не всегда возможно выделить.
То есть не всегда возможно сказать, что вот это есть часть, и часть чего именно...

А, ну вот, и Вы про то же

Всё опять-таки сводится к моделированию: система координат, проекция...
Так, имеем простую координатную ось (числовую).
И проециуем на неё количественную характеристику "размер". Или, скажем, "объём". Или "масса". Ну и т.п., со всеми соответствующими выводами и следствиями.
А сами числа мерить отрезками, конечно, неверно...